[D7] Routing Debug

Hello there,
Could you explain how exactly this module is different from the Admin_menu module-provided admin_devel module?

When you enable asmin_devel, you get an additional set of debug tools, including a menu router info tool. There's no Reflection that gives the exact file and line name, but gives everything else I can see this module is showing.

There are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxdavidlukac2479685git

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

I'm a robot and this is an automated message from Project Applications Scraper.

I'm not reviewing project applications to get a review bonus, and I'm merely helping Klausi and other admins to keep the queues clean. Sorry for popping questions/doubts this way. I'm just providing my feedback with hope to speed up the process.

I think the Devel + admin_devel approach is there because you do not have to load all the files in order to extract the menu item data. Devel module is already designed for developers, so I think providing the router path from URL is not a big UX issue.

admin_menu is a really active module, so I would rather try to add the function line features and other drupal_get_form() extras into the admin menu module itself. You can still get the vetted status and of course get attribution set to your account.

Either way, note that drupal_get_form()'s first argument is usually a function name, but not always. Modules can implement hook_forms() to get called for form IDs that do not have a matching function name.

Hi, this seems like a handy dev module, I think all those small things + the debug block you just added are enough for a separate module to make sense. Quick look at the code gave me an impression of a very clean code, so there seems to be no issue from that point of view. One suggestion though - I would expect to see the provided menu links somewhere in the admin menu, perhaps under Reports - this would also switch your gui to use administration theme (if the site uses it) which copes much better with the wide table you provide (URLs would change to e.g. "admin/reports/routing_debug")

Some very minor suggestions which you might completely ignore:
- I like very verbose comments, but putting in comments like "We just define our block here; it's actual contents is being provided by hook_block_view() function." for one of the most widely known and used hooks does not seem necessary - I would rather state here what the defined block(s) is for. Same goes for "hook_block_view", I havent noticed more of these.
- _routing_debug_block_contents() - you use escaped single quotes to display them - why not use double quotes instead? Escaping quotes for such reason seems unnecessarily confusing to me - also, double quotes on front end in texts seems more natural to me than single ones (might be just me though)

More comments to come if required :)

Additionally, you use "access routing information" as access argument for the menu items, with no access callback defined - which means default user_access is used - but I do not see "access routing information" permission defined anywhere. This way no one but user 1 can access these menu links.

I was bored so here is the permission hook patch :).

Hi again,
I don't think there are anymore blockers in the code, but here are a few suggestions.

- In the .module file, you include the admin and pages.inc file, which you don't really have to. In the hook_menu() implementation, you can define the file to load, so they won't be loaded on every page; just when the user tries to access the page. I'm kinda feeling silly for saying this to you now that you have written a module to debug routers themselves. If there's any reason to include them on any page, please disregard my note.

- Can we capitalize the first word of list items (.module:88...90)

- In the .module:230, make sure there is no double encoding. url() function can do the urlenode() call for you for parameters passed in the 'query' array for the second parameter.

- .module:234: Please use the t() function to wrap the string literals.

- I also agree with Milan (m1n0) about code commenting. Beautifully commented! The @var commenting is just candy to IDEs. Really great work. In the RoutingInfo class, you could define the describe class properties in the @property syntax on the root comment. It would look much cleaner.

None of the above suggestions are not blockers. I'm not going to override m1n0's "Needs work" here, but I think this is pretty much RTBC now.

I think the only blocker is the permission thing, as that is actually a bug.

Sorry, yes you are right about the permission issue. Oh look we have a patch too!

Are you sure you pushed the code?

Also, please note there is a minor change necessary with your git strategy to match the drupal.org module packaging system.

For each major Drupal core version, we create a branch. 7.x-1.x, 8.x-1.x, likewise. If the module has major version for each Drupal major version, they can be named like 7.x-1.x, 7.x-2.x, likewise.

However, we do not create a branch for each release. The branch is supposed to be the latest HEAD, and when you are ready to release a version, you can add a tag to that commit. 7.x-1.0, 7.x-1.1.
This format is expected by the d.o packaging system and Drupal itself (in update checks, etc).

Thanks. Module looks quite ready to me, so I'll go ahead and RTBC. I still think you could go for a Review Bonus, so Klausi or some other git admin can take a look at this application quickly.

Sorry about the delay in this, and thank you for co-operation during the review process. I will go ahead and mark this account as vetted. This is by the way, my first module that I'm approving after becoming a git admin.

Thanks for your contribution, David Lukac!

I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.

Here are some recommended readings to help with excellent maintainership:

• Dries' post on Responsible maintainers
• Best practices for creating and maintaining projects
• Maintaining a drupal.org project with Git
• Commit messages - providing history and credit
• Release naming conventions.
• Helping maintainers in the issue queues

You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

Thanks to the dedicated reviewer(s) as well.