Display current application routes

[Ragazzo]

I think it would be good to have console command and debug toolbar with routes that are defined in application. Similar to bundle exec rake routes and laravel routes.

• [ ] php yii routes - display all routes variants (not only first match).
• [ ] php yii routes posts - display all routes for given controller.
• [ ] php yii routes posts/view - display all routes for given controller action.

[cebe]

routes are not configured in console application so you can not show them. What is the benefit of showing them in debug tool? Imo it is much better to view them in config.

[Ragazzo]

Benefit is to not view them via config. I think we can parse web config to get rules, and controllers. This is very useful especially for REST api and other things when debugging. You also dont need to browse through all controllers to see what filters and hooks are applied.

[qiangxue]

This is not possible for Yii because each URL rule in Yii may correspond to multiple routes.

[Ragazzo]

But we can parse them as url-manager do.

[qiangxue]

How? How do you parse this rule? '<controller>/<action>' => '<controller>/<action>'

[Ragazzo]

for each controller will display controller/action per each action, as it applied.

[qiangxue]

Well, this is not true in practice. If this rule is at the bottom, some controller/action may not match it.

[Ragazzo]

True, but this is how application works. We should not display all routes, only those what be really applied, and used by application request, because other does not make sense (displaying all variants for route if already one was found).

[qiangxue]

Assume we have the following two rules, what should be shown regarding the route post/view?

[
   '<controller>/<id:\d+>' => '<controller>/view',
   '<controller>/<action>' => '<controller>/<action>',
]

[Ragazzo]

post/{id}, or if table then - GET | post/{id} | "some filters here if needed"

[qiangxue]

But in case when the user doesn't provide id parameter, the second rule should be applied.

[qiangxue]

And what if there's another rule '<controller>/<name:\w+>' => '<controller>/view' which is after the first rule?

[Ragazzo]

But in case when the user doesn't provide id parameter, the second rule should be applied.

if there is no id, how he will call actionView($id) he will get exception.

And what if there's another rule '/name:w+' => '/view' which is after the first rule?

but he also will get exception with this route in request because of no id.

Anyway what i want is simple route=>rules matches console output, because it will simplify rules creating and will help developer in debug. In Yii1 creating and applying rules was a little bit painful.

[qiangxue]

No, he won't if he declares the action to be actionView($id = 0, $name = '').

[Ragazzo]

right, in this way then we can display all routes that could match in the detail route info. For example: php yii routes - display all routes only with first matches. php yii routes post/view - displays route detailed info about all possible matches. Can be implemented as running matches, if found match then delete this match and run once again until all matches will be found.

This tool will indeed help developer.

[qiangxue]

What I want say is that yii routes doesn't make sense because you can't precisely determine the first matches without knowing the GET parameters. If you can't display precise information, then it's useless and harmful.

yii routes post/view makes some sense by displaying all possible matches.

[Ragazzo]

the first matches without knowing the GET parameters

hm, right. what if we then keep yii routes for REST? yii routes/rest here i think we already know all possible combinations.

yii routes post/view makes some sense by displaying all possible matches.

yes. Also if user is applying some route he will be searching by it and dont need all info about all routes.

[qiangxue]

hm, right. what if we then keep yii routes for REST? yii routes/rest here i think we already know all possible combinations.

I don't quite understand it...

[Ragazzo]

well when you will provide web-api support, there also will be rules for web-api, like DELETE, GET, POST, PATCH. and routes/rest will display this all routes. routes/rest posts will display all rest-routes for posts controller.

[qiangxue]

routes/rest: will it display GET routes?

[Ragazzo]

yes, similar to these. Also as you can see rake routes and laravel display all possible routes and not only first match, maybe we should also go these way. php yii routes - display all routes variants (not only first match). php yii routes posts - display all routes for given controller. php yii routes posts/view - display all routes for given controller action.

[qiangxue]

This makes more sense to me.

[Ragazzo]

Yes, sorry for confusing you about first match. The above implementation makes more sense indeed.

[qiangxue]

No problem. Clarifying requirements is often not a simple task.

[Ragazzo]

Thank you, should i add this examples in the description as to-do list? Will be easy then to see what we need to implement.

[samdark]

Yes, please do.

[Ragazzo]

Done.

[Ragazzo]

looks like accidentally closed by me , reopening this one since it is not implemented as i see , if no feel free to close this one

[NickvdMeij]

+1, this would be a perfect addition for those who would like to have it. Especially in large projects, the config file might be seperated in different config files which are merged together, making it hard to look up a specific route. Would love to see this feature implemented

[dynasource]

if somebody wants to have this in core, please feel free to do a PR. 3 years have passed with little progress so Im closing this one.

[mjonas87]

Routing in Yii is not intuitive. Having this in place would be a major boon and would help with diagnosing routing configuration issues. Coming to Yii from other frameworks, I was pretty shocked to find this basic feature missing.

He said without having time to commit to resolving the problem

[Ragazzo]

4+ years and counting :D

[pablowillians]

5+ years and it continues...

[BreiteSeite]

6+ years. Nothing to see here.

[samdark]

@BreiteSeite want to change it doing a pull request?

[Wirone]

@samdark I know this can be frustrating that many people starts trolling (instead of making PR) after asking for this very basic feature for 6 years, but think about it for a second - this issue was created almost year before releasing Yii 2.0, after that Yii team released about 50 versions of Yii2 and this wasn't addressed. As far as I see Yii3 is under development (why??) and still no milestone assigned. How people can be serious about it? It's totally laughable and you should accept it.

[samdark]

@Wirone it's not a priority for us to spend days on it. There are issues with more demand/impact. If that would be a basic feature that could be implemented in a few hours, it would've been done right away. I don't see anything laughable in having core priorities while accepting contributions.

[Wirone]

@samdark for me (and for many others, as you can see above) ability to list available routes is a core feature with high priority. It's very basic DX feature that helps with development and debugging. In large applications with module-based system it's almost impossible to look for routes in multiple places in the code.

We use Yii1 in one app and Yii2 in two apps, all of them written by other teams and given to us for development and maintenance and my teeth hurt while working on them. What you said is one of the reasons why it's like this - you don't understand the problem and as far as I see in comments above you also don't see how it should be done and what it should do. There is no need for listing all available combinations but only route definitions (probably in the same order as how they would be checked in the request, but maybe it could be parameterized) and maybe ability to check specified URL against defined routes to check which will catch it. Well, all is there, ready to display this data in CLI... if routes are shared between CLI and web app.

[bizley]

@Wirone may I ask what is stopping you from doing this PR?

[Wirone]

@bizley Yii.

[NickvdMeij]

@Wirone im pretty sure @samdark knows quite well how much effort it is to make a PR for this. The problem mainly is that there are just too many usecases and implementation to make this work like a charm. Furthermore, it's not @samdark his problem you are working on legacy applications that you didn't even write. Maybe look in the (probably lacking) documentation before trying to blame others? If you want to see this feature implemented, like others said, feel free to make a PR with an implementation.

I fully agree on @samdark that this shouldn't have a priority. It's nice if someone who wants it actually builds it, but its not as important as stuff like Security related topics that the core devs normally work on, which are much more important than some shiny display of the routes (most dev's know which routes are available anyways, no tool needed for +- 95% of the Yii2 users).

Just remember, the core maintainers are not your pets to boss around to make stuff for you. Its open source, contribute yourself and collaborate. Don't be that toxic guys that just blames everyone for not doing what he specificly wants, without even thinking of what others are working on ;-)

[Wirone]

@NickvdMeij I don't blame anyone, I just said what I think about this. Also - I don't need it because I won't use Yii in any project in the future and it wouldn't make those apps mentioned earlier good apps in a magic way :wink: I just think what I wrote - this is basic feature for DX and yes, it can help also in security (if Yii could also read access rules so you could audit routes and required roles). It's laughable FOR ME that Yii still doesn't offer it, after 6 years.

[bizley]

If you could take a look at the above link and see if it meets at least some of your expectations it would be great.

[alex-wdmg]

Not sure about the routes in the console, but some RBAC extension might collect a list of routes. I dare to assume that this happens by recursive analysis of the actions of all controllers. Perhaps it makes sense to implement it in this way, because if there are such actions, then it is assumed that there will be routing rules for them too. Go from the opposite!?