Template routes implementation

It looks like the route is saved as a new column in the exp_templates table. Looks like it doesn’t interact with the core_template_route hook. I don’t see a config var override, but it should be pretty easy to do that, or add a hook in this method, where the routes are loaded from the db and assigned as an end point.

public function set_routes()
 {
  ee()->db->select('route_parsed, template_name, group_name');
  ee()->db->from('templates');
  ee()->db->join('template_groups', 'templates.group_id = template_groups.group_id');
  ee()->db->where('route_parsed is not null');
  $query = ee()->db->get();

  foreach ($query->result() as $template)
  {
   $this->end_points[$template->route_parsed] = array(
    "template" => $template->template_name,
    "group"    => $template->group_name
   );
  }

                // hook or config override/concatenation here
 }

This part concerns me most as I have to deal with translated URLs in Publisher, so I need to find a way for people to enter translated versions of the routes.

It looks like core_template_route fires before the built-in Template Routes kicks in, so you should still be able to use that hook to override the built-in behavior.

Then that involves running the route routines yourself. I’d rather just have a config override var for routes. Having routes configured in the cp feels dirty to me, and there probably isn’t a way to lock clients out of that page only so they don’t mess it up. All php frameworks configure routes in a config file, I’d like the option of doing that. It would also make it very easy to support translated urls (with or without Publisher)… Just enter multiple routes for the same template/group to match the translated uri segments.

For anyone wondering this works.

public function core_template_route($uri_string)
{
    ee()->load->library('template_router');

    $template_route = ee()->template_router->create_route('/my/custom/route');
    $route_parsed = $template_route->compile();

    ee()->template_router->end_points[$route_parsed] = array(
        "template" => 'detail',
        "group"    => 'pages'
    );

    // rest of hook
}

Having routes configured in the cp feels dirty to me

Spoken like a true programmer. 😉 But being serious, any settings that are a use of the software (as opposed to modifying it) should be available in the software, not just the file system. If anything, configuring settings outside of the control panel is dirty.

and there probably isn’t a way to lock clients out of that page only so they don’t mess it up.

Do clients that might fiddle with these settings need access to other areas of the Template Manager? Couldn’t they do similar damage by editing the templates, snippets, etc.?

Or maybe asked this way: what scenario would you need to allow a client to edit templates, global variables, and so on, but that you would not want them to be able to view and edit routes. If they are editing templates, they are going to need to know about the routes in order to construct paths and use route variables properly, no?

All php frameworks configure routes in a config file

ExpressionEngine isn’t a PHP framework, though, and we feel strongly that this powerful feature should not be locked away for programmers only. I’m sure multi-lingual issues can be addressed without requiring editing a PHP file.

Hopefully I’m not being too hasty in asking this before I actually go dig into the code for myself… but I’d love to get some implementation details on the new template routing features. How are yall storing routes?

Serialized arrays! Sorry, couldn’t resist, not really. As litzinger correctly pointed out, it’s a new column (three actually) stored with each template in exp_templates. One column is the route as provided by the user, another is a “compiled” route, which is a parsed, validated version of the route ready to use for regex matching, and the third is a flag for whether or not all segments of the route are required for the route to be triggered.

And, what are our options for manipulating things through config vars? Are the new Template Route Manager and Access screen the only way to view/edit routes?

As with most brand new features in ExpressionEngine, we start with very few if any overrides, hooks, etc. Sometimes it’s a version release or more before we are able to see fully how our features are being used in the wild and what and where entrance points are needed. But the developer previews have been key to getting in essential overrides and hooks, too, so if in your use of routes during this preview you have suggestions or requests, please do let us know.

Derek, I see your point about the routes being managed in the CP. I still have 2 thoughts on them though…

1) Its hard to find the route field, it took me a few minutes to find where to set it. It feels very hidden.

2) The routes overview page could benefit from an “edit” link taking the user to the Access settings, or a way to edit them directly on the overview page itself.

We usually lock the whole Design section down for clients, so it isn’t that big of an issue for us.

In regards to a hook or config override for the routes it might not be necessary since Rob was correct, and based on my quick test last night, that routes can be modified in the core_template_route hook.

As a general note on this release. Thank you! It looks like a very solid release and I’m really liking what I’m seeing.

Thanks for that feedback, Brian, and for the kind words. We’ve been pretty excited about it too. 😊

So, having dug into it a bit further — and thanks for all the details you provided, Derek et al. — I have to say, I’m really happy this is on EL’s radar…

…but I feel like the present philosophy leaves a lot of power and usefulness on the table. Namely, I’m not convinced that a route should be tied to a template as a property of the template. Rather, it seems like it’d be more intuitive, both for understanding routes and for editing them, if Template Routes were themselves atomically editable, each pointing to a template group and template.

I envision an edit screen like the new Template Route Manager, except the Route column contains an editable text box, and the Group and Template columns contain dropdown selectors. We’d have an exp_template_routes table with all the data. And it’d be trivially overridable with a config array.

This empowers several relatively common use cases for custom routing that are currently not served by the new feature: - routes are not directly related to content or template structure - more than one route points to the same template - routes are tweaked on a per-environment basis - routes are tweaked on a per-language basis

Spoken like a true programmer. 😉 But being serious, any settings that are a use of the software (as opposed to modifying it) should be available in the software, not just the file system. If anything, configuring settings outside of the control panel is dirty.

ExpressionEngine isn’t a PHP framework, though, and we feel strongly that this powerful feature should not be locked away for programmers only.

I agree with this sentiment, and I definitely don’t mind being able to edit routes in the control panel… or even having them stored in the database. In cases where routes are more-or-less parallel to content, and for novice builders, this makes perfect sense.

But there’s a whole world of use-cases where routes are more like settings. They modify the behavior of the software, independently of content, and it makes no philosophical sense to tie them to content. In fact, I think MOST use cases for custom routing probably fall into this category. In these cases, I want to be able to version/SCM/branch/merge them along with my configs and templates. And I definitely need to be able to have more than one route per template.

(Ultimately, 3P options like Rob’s “Resource Router” will [still] answer these needs beautifully… I’d just hate to see yall put all this work into making routing an accessible first-party thing only for us to still have to resort to more powerful 3P options…)

Michael, adding multiple routes for a template is really easy with an extension. I’ve already finished implementing translated routes in Publisher and my code above is a working example of that. I see where EL is coming from, and I see where you’re coming from, and my first thought after reading Derek’s post was this leaves room for someone to write (and sell) an extension that enables more powerful route management.

But there’s a whole world of use-cases where routes are more like settings. They modify the behavior of the software, independently of content, and it makes no philosophical sense to tie them to content. In fact, I think MOST use cases for custom routing probably fall into this category. In these cases, I want to be able to version/SCM/branch/merge them along with my configs and templates. And I definitely need to be able to have more than one route per template.

One reason we have routes tied to templates is because we’d like to go the other direction and generate paths for templates based on their route. If you allow for multiple routes for a template you lose this ability. What are you use cases for using multiple routes? The route syntax plus the optional segments option should cover 95% of use cases for multiple routes. For instance if you want translated URLs, right now you could do something like:

/article/{summary:regex[(summary|zusammenfassung|resuma)]}/

I was imagining a hook allowing developers to inject their own segment rules, so you could have a translation rule that might look like:

/article/{summary:translate['summary', 'zusammenfassung', 'resuma']}/

Well, I did some traveling and sort of fell out of this thread. So, now that 2.8 dropped, I wanted to pop back in and just say “Good job” and congrats.

I maintain that there will be some use cases where the one-template-one-route scheme will be restricting, but I am starting to see the logic behind this design decision… especially with the addition of the {route} tag. Making the routes mass-editable was also really helpful — thanks for that.

Quinn, I think you’re right — yall’s implementation will probably cover way more use cases than I initially thought.