Hi,
in the "Custom Routing" chapter of the Trongate framework documentation (https://trongate.io/documentation/trongate_php_framework/understanding-routing/custom-routing), the "(:all)" wildcard is currently inactive because it has not yet been implemented (see the regular expression code between lines 77 and 81 of the "engine/ignition.php" file).
Bests regards.

Hi jchouix,

Thank you for bringing this to our attention and for taking the time to look through the documentation so carefully.

You're absolutely right — the (:all) wildcard was documented but had not yet been implemented in the routing engine. This has now been fixed via PR #242 and the commit 99b6ab5, which adds proper (:all) support to attempt_custom_routing() in engine/ignition.php, along with named wildcard backreferences (:any, :num, :all) that can be used in route destinations.

To get this working in your Trongate application, simply pull the latest version from GitHub:

git pull origin master

Alternatively, you can update the engine/ignition.php file directly from the latest commit on the repository.

Thanks again for the helpful report — it genuinely helped improve the framework!

Best regards,
Grady

Hi Grady,

Thank you for your reply, but the implementation you propose seems dangerous from a security standpoint because allowing all characters without exception in a URL creates an entry point for various attacks (XSS, etc.).
Personally, I would go with the whitelist solution, allowing only a few characters, such as :

What do you think of that ?
Best regards.

Hi jchouix. Good question.

The (:all) wildcard is safe because the routing engine only extracts URL segments and passes them as strings to controllers — it never evaluates or outputs them. The same security practices apply whether you use (:any), (:num), or (:all): out() for HTML output, query_bind() for SQL, and make_sure_allowed() for access control. Those are the proper security boundaries.

A whitelist regex like your proposal would reject legitimate characters: % (URL encoding), . (paths/versions), @ (redirects), + (encoded spaces). The (:all) wildcard is deliberately permissive for routes that need to capture arbitrary path segments. If you need restricted characters, (:any) (no slashes) or a custom regex route gives you that control.

Davcon's right — if someone can break your app by typing in a URL, the problem isn't in the routing layer.

All the best,
Grady

Thanks for the response.
Best regards.

Shame about Davcon's comments being deleted by the way. I read them at the time and they made sense, so now the middle of the thread looks like Grady is replying to someone who isn't there. Bit confusing if you stumble on it later, but I suppose these things happen.

On the actual topic, I think you're both right about different things. The bit that clicked for me was Grady saying the router only passes the segments through as strings. When I first got into PHP I'd see user input in a URL and immediately assume the sky was falling, but the real work happens at the output end. Escape it with out() on the way to the page, bind it on the way to the database. Get those two right and a wildcard route stops being a scary thing.



That said jchouix, I get the instinct, and I'd probably do the same on a tighter route. For something like a slug or a username I keep the pattern narrow in the route definition itself, mostly so I don't have to remember what's allowed six months down the line. Kind of like marathon training really, you don't win it with one big push, it's the boring habits that carry you through.

Good to see (:all) working now too. Catch all routes are handy for doc style paths and legacy redirects, otherwise you're sitting there writing routes all afternoon.

Nice catch on the docs. That would have had me staring at the screen wondering why nothing fired.