Scroll down to the script below, click on any sentence (including terminal blocks!) to jump to that spot in the video!Cool, got it! Show me the script!
A lot of people wanted it, so brand new in Symfony 2.2 is the ability to match route names based on the host parameter. To see it in action, let’s duplicate the fragments route and make the first one point to a non-existent controller:
fragments: path: /fragments defaults: _controller: EventBundle:NewFeatures:testFragmentsFake fragments2: path: /fragments defaults: _controller: EventBundle:NewFeatures:testFragments
Perfect! Since both routes have the same pattern, the first always wins and our application breaks.
Pretend now that this route should only respond to foo.sf22.l. To make this happen, add a host key under the route:
fragments: path: /fragments defaults: _controller: EventBundle:NewFeatures:testFragmentsFake host: foo.sf22.l
When we refresh, the application works, which means that the first route is no longer matching since we’re not at the foo subdomain. The second route has no host key, it matches on any host. We can also switch to the subdomain and see that the first route indeed matches.
The only problem is that we’ve hardcoded the domain name, and it’s likely that this domain will be different locally than beta and production.
To fix this, let’s leverage a feature that was actually added in Symfony 2.1: the ability to use parameters in routing files. Start by adding a new entry in parameters.yml called base_host:
# app/config/parameters.yml parameters: # ... base_host: localhost
Remember that there’s nothing special about this file - you can have a parameters key in config.yml or any other of your configuration files.
Next, update the route to use the parameter under the host key.
fragments: path: /fragments defaults: _controller: EventBundle:NewFeatures:testFragmentsFake host: foo.%base_host%
When we try it, both subdomains behave exactly as before. Easy!