Interceptors
Trongate v2 introduces a new feature to rule every request - before routing, before controllers, before anything.
Meet INTERCEPTORS.
Interceptors - Explained Simply
Think of an interceptor as a bouncer at the door of your application.
Before anyone:
- reaches a controller
- hits a route
- triggers any logic at all
…the interceptor gets first say.
Every single request knocks on the door. The interceptor answers first.
What Actually Happens (Step by Step)
-
A request arrives
- Someone visits a page
- An API call is made
- A form is submitted
- Even a 404 request comes in
-
Trongate checks the interceptor list
- It looks inside
config/config.php - It checks to see if any interceptors have been registered
- It looks inside
-
Trongate runs interceptors immediately
- No routing
- No controller lookup
- No conditions
- Just run this code
-
After the interceptor finishes
- The request continues normally
- Routing happens
- Controllers run
- Views render
Unless your interceptor stops things.
The Only Setup You Ever Do
Inside your main config file, at config/config.php, write this once:
For the above code to work, replace some_module with the name of the module (i.e. the folder name inside modules/) that you want to load.
Then replace some_method with the name of a public method inside that module's controller.
On every inbound HTTP request, Trongate will automatically load that module and execute the specified method before routing or controllers run.
That's it.
- No service providers
- No middleware stacks
- No registration elsewhere
If it's listed there, it runs.
What an Interceptor Really Is
An interceptor is just a controller method.
Nothing special about it.
A good mental model is:
Whenever anything hits my app, call
Some_module::some_method() first.
That method can do things like the following:
- log data
- inspect headers
- check authentication
- reject the request
- redirect
It's good practice to use the helper function when working with interceptors.
That's because interceptor methods are not meant to be actively visited.
So, inside the method, you usually do this:
That means:
This method may run internally, but it must never be accessed via a URL.
Using block_url() keeps the interceptor purely internal.
You can, of course, set up multiple interceptors if that’s something you’d like to do. The syntax uses standard key/value pairs, where each key represents a module name and each value represents the method to be executed.
For example:
In this example, all three interceptor methods will run on every inbound HTTP request, in the order they are defined.
This makes it easy to layer behaviour - such as logging, access control, or request validation - without cluttering your controllers or repeating code.
Downloadable Example
We've created a sample interceptor module that can be downloaded from this GitHub URL.
The name of the module is endpoint_listener.
The module is a handy debugging/development tool that can be used to inspect inbound HTTP requests. It will record things like:
- The date and time of the HTTP request
- The type of request that was received (e.g., GET, POST etc)
- The URL where the request was received
- Information about payload and headers that were sent with requests
How To Switch It On
To switch on the endpoint_listener interceptor, open config/config.php. Then add:
Now Endpoint_listener::record() runs on every request. You also get a webpage for inspecting inbound HTTP requests:
How To Switch It Off
To switch it off, go to config/config.php. From there, you can either remove your interceptor rule(s) or simply comment them out.
Remember: The pattern is always the same: define the module and method in your config, and Trongate handles the rest.