Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Follow-up from #2073811-70: Add a url generator twig extension.
In an effort of compromise, I think we have agreed that a needed helper function (in a separate issue) should be added to determine a list of available routes:
{{ dump(routes()) }}or{{ dump(routes('^user')) }}(for routes that start with user)
This is the back-end implementation issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | toolbar.png | 13.44 KB | dawehner |
Comments
Comment #1
markhalliwellRemoving front-end tags.
Comment #2
Crell CreditAttribution: Crell commentedThis doesn't belong in Twig. There are a lot of things where we need proper introspection tools; routes, public services, etc. Those belong as drush scripts, not as twig commands.
(They can't be in core because core lacks a meaningful CLI tool. We never got around to adding the Symfony Console component. Sorry.)
Comment #3
tstoecklerI disagree. We do need discoverability for services, but that's a module developer's issue. And even though it's not particularly nice, I think it's *OK* for us to require module developers to look into core.services.yml. But for theme developers the issue is that you cannot simply do url('node/1') anymore, you need to figure out that the equivalent route is node.view (or whatever it is) to do {{ url('node.view') }} (example syntax). Saying we won't provide some way of discoverability means we require *theme* developers to look into module's *.routing.yml. I personally don't think we want to do that.
Comment #4
markhalliwellThis issue isn't the Twig implementation. This is for whatever needs to be done on the back-end (ie: with Symfony or some other gobbledygook implementation that I wouldn't know how to do). Whatever does make it in, I'll use it for #2106797: Create a Twig function for route discoverability.
That is 100% correct. We cannot allow this to happen.
Comment #5
Crell CreditAttribution: Crell commentedAt no point did I say "Theme devs need to look in a routing.yml file". (Although to be blunt that's less of a burden than we put on them now to look at a theme hook in the .module file. Really.)
I said "this has no place in the theme layer". "What routes do I got?" is not a theming question. It's a question lots of people could ask. Putting it in the theme layer is short-sighted.
Time spent here is far better spend adding that capability to Drush so that it's ready for module *and* theme developers on day 0 of Drupal 8.
Comment #6
webchickSo now in addition to not being able to use effing URLs in order to make links to things (aka, web dev 101), you now need to also be a command line junkie in order to make designs for Drupal? Give me a break, please. :(
For completeness, though, #2106425: Add some new drush commands for getting route information adds this capability to Devel/Drush.
Comment #7
catchIsn't this the same issue as #2098197: Add getAllRoutes() method to RouteProvider ?
edit: also I agree it's not OK to bury this information 100% in a drush command. I do think it's OK if devel provides it (and potentially the drush commands too), but core should have enough to make that OK to implement. Also as someone who does stone age debugging I'd like to at least not completely lock that possibility out.
Comment #8
dawehnerSymfony itself solves the problem by providing the really impressive symfony web profile toolbar
Comment #9
tim.plunkettThis doesn't seem like a major task.
Comment #10
dawehnerMuch like we don't provide a helper for the available theme functions/templates we should rely on contrib. https://drupal.org/project/webprofiler for example gives you all the routes and the current
used route on the page.
Comment #11
Crell CreditAttribution: Crell commentedThe method has been added, some tools exist, more can easily be written. This is done.