How can I use subdomains in routes?

So, I have several subdomains for my project:

How can I use it in routes?

This example does not work:

$app->get('', Journal\Handler\HomePageHandler::class, 'journal.home');

Short answer: you can’t.

Longer answer:

Because we wanted a system that would allow consuming any third party router, we had to build abstraction for the lowest common-denominator. In this case, it was path-based routing, as every single routing library you can survey supports this use case. Anything else would require that we potentially provide feature-rich wrappers around other routing solutions, which would completely negate the idea behind having a unified API.


  • You can always supply your own routing and dispatch middleware, giving you complete control over routing.

  • For your scenario of subdomain-specific handlers for landing pages, you could have separate vhosts for each, and use config/autoload/*.local.php configuration to override dependencies based on the vhost. So, for example, you could map the HomePageHandler::class service to a different factory, thus returning a different version (and do the same with template paths).

  • You could use middleware between routing and dispatch to change the RouteResult based on the detected subdomain (using the current ServerRequestInterface to pull this information from its composed UriInterface).

Thank you. I will think how to write my Middleware.

But I still do not understand, why i can’t configure routing libraries, like:

    'subdomain' => ''

You can (the Route instance returned has that method), but how those options are interpreted is up to the individual router implementations. (getOptions()/setOptions() exist as the sole mechanism for customizing routes for the specific implementation used).

However, the Route instances are decoupled from the router implementations themselves, so it’s up to the implementation to decide how to use those options. Currently, none of them support a “subdomain” option, though several support host matching via other mechanisms (not related to options). Since we couldn’t anticipate all the possible options, or how we might want to map them to other features in the various implementations, we restricted ourselves to the lowest common denominator: paths and HTTP methods.

got it. Thank you.
I will try to resolve this issue and share with the community.