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.

Okay. Thanks for the follow up. Here's what I think:

If somebody can break your web app by typing some characters into the URL then you have massive problems. Nobody should be able to break any web application by typing stuff into the URL.

I'll have Grady look at this and I'll be interested to see what Grady thinks.

Here we go...

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.