More robust template path hints (block name, block parents

[apiuser]

Feature request from erikhansen, posted on GitHub May 16, 2014

Currently, the "template path hint" feature displays the template name and block class name.

Fabrizio Branca's Aoe_TemplateHints module extends the native Magento 1.x template path hint functionality to add much more information to the hints including:

• Block name (very useful)
• Parent block names
• Module
• Caching status

Here is a screenshot from his blog post, visualizing what this could look like:

I propose that this functionality be built into Magento 2. If Magento accepts this proposal, I may be willing to build this functionality and then issue a pull request to have it incorporated into Magento 2.

[apiuser]

Comment from erikhansen, posted on GitHub Jan 14, 2016

@ryanstreet It would be awesome if you could take this on in February. Frontend developers will thank you for years to come. The Aoe_TemplateHints extension is pretty robust and does quite a bit more than what I think we could reasonably expect to be included in the Magento core.

If I were you, I would target adding this functionality to core Magento: In addition to the block class and template file, add the block name and block alias to the template hints.

I'm not sure if you've submitted any pull requests for Magento 2, but you'll need to keep in mind that Magento expects integration/unit tests to be included in any pull request. You can read up here on how to get Magento's native tests running on your development environment: http://davidalger.com/development/magento/running-the-magento-2-test-suite/ Since Magento should already have tests in place to verify the existing template hints functionality, it shouldn't be too difficult to expand upon those tests to cover the new functionality.

Here is my suggestion of how to change the config:

Here is a suggestion for how you might add the block name and class:

You'll want to test with all combinations of settings and block combinations (e.g., blocks with no names but aliases, etc)

[apiuser]

Comment from alankent, posted on GitHub Jan 14, 2016

I would love to see this tool improved, or a better version created as a module. It just struggles to get high enough on the list compared to other features internally. Should we fix checkout or the hints too? Checkout! Should we fix payments integration or the hints tool? Payments! This sort of project I think would make a great community contribution.

[apiuser]

Comment from erikhansen, posted on GitHub Jan 14, 2016

@alankent I'm glad you would like to see this tool improved but certainly understand the difficulty in prioritizing it against other features. I like that Magento has focused on more building developer tools (including a Grunt/livereload workflow, bin/magento, etc). I want to contribute in helping make the platform better for developers (via things like this PR).

Do you have any feature suggestions beyond the pared down functionality I recommended in my previous comment? Any time I've used Aoe_TemplateHints, the main thing I've wanted out of it is the ability to see block names/aliases. Although on occasion I've used the block nesting, caching status, and "displaying all of the information as HTML comments instead of HTML elements" features. I could see those features being useful, but not as much as just getting block names/aliases displaying.

[apiuser]

Comment from alankent, posted on GitHub Jan 15, 2016

I would be tempted to have all the hints in a popup box when you hover (just like the start of this thread). For small areas on the screen, all the text gets truncated at present. I would rather have a little clean popup box that can include a clear list of the settings. Then you can add more content as appropriate over time without running out of screen real estate.

You could then drop some of the options regarding what to display - just always display it all! You need to turn it off at present to make things easier to read at times.

It would be nice if the popup box markup is clearly separate from the normal HTML module output (e.g. in a separate div) so you can expand/collapse more easily when doing inspect element. At present, the hint markup is pretty in your face making "inspect element" pretty unfriendly when the hints are turned on.

I would love to see the path from the root of the view element tree with the names of all the blocks, or at least the block's parent, so you can work out how to construct layout instructions more easily. (If you got crazy, a full expand/collapse tree of all the blocks that make up the current page would be great! Then add the path name to the layout file the block came from... but I think that is going too far.) Just having hovers is a step forwards however as you can deduce the block tree structure just moving the cursor around the page.

I personally find the red not very nice - looks like an error rather than just a developer exploration tool. I do like the rectangles though - helps understand the area the block covers.

Again, if you wanted to go crazy, you could make the popup have a link to display the PHTML template file (not just show the path name). However this starts becoming a security concern as you are starting to make it easier to read the source code remotely, which I would frown upon.

[apiuser]

Comment from alankent, posted on GitHub Jan 15, 2016

I am not a JavaScript guy - I guess you could have bar at the top of the page with options, like an on/off button so you can just hover all around the page without inserting the rectangles. So you see what the page really looks like. Think Z-ray. But clearly that is a lot more work. Simply having popup boxes with little icons instead of embedding the text directly into the page would be a huge step forwards. E.g. draw a rectangle with a little space inserted, and a little box or triangle in corner that you click or hover over to display the popup.

[apiuser]

Comment from erikhansen, posted on GitHub Jan 15, 2016

@alankent I love where you are going with this.

I like the developer bar idea. It reminds me of Alan Storm's Commerce Bug.

I agree with you that moving the information into a tooltip is the best way to unobtrusively display robust debugging information.

Having the popup link allow you to open the phtml file in your IDE is a great idea. PhpStorm supports the phpstorm://open?file=%f&line=%l format for opening files (coincidentally I just added these links to Xdebug in Classy Llama's development environment). TextMate has a similar link format, and I'm sure that Sublime, Netbeans, etc also do. We could add a dropdown in the "Debug" section allowing a developer to choose a list of IDEs from a dropdown.

I'm going to put some time into this over the coming week and see what I can come up with.

[apiuser]

Comment from alankent, posted on GitHub Jan 15, 2016

"I love where you are going with this." - if you get something built, then I would think the community would turn it around and point it back at you! ;-)

[apiuser]

Comment from aepod, posted on GitHub Jan 15, 2016

Drupal 8 has a pretty nifty built in toolbar(although it was a little tricky to get working). It's based on something in symfony and has quite a bit of templating and other info, as well as a click through to very detailed info page on some bits.

[apiuser]

Comment from erikhansen, posted on GitHub Jan 15, 2016

@aepod Interesting. I'll have to install Drupal 8 locally and play around with it.

@alankent It looks like Fabrizio implemented support in Aoe_TemplateHints for the older style of linking to PhpStorm:

[apiuser]

Comment from ryanstreet, posted on GitHub Jan 25, 2016

Wow! What great feedback!

@aepod I'll have to look at what Drupal 8 does with their hint system.

@alankent and @erikhansen: I think an iterative process will be the best way to handle this. I don't want to pack too much into it all at once, and have it take forever to complete. My initial thoughts are to get basically what Aoe_TemplateHints did in there first. I really like the idea of the PHPstorm popup feature. I think that would be good to add in a later iteration.

I have worked with the Laravel debugBar and the Symfony Debug Toolbar as well. I would like something like that in here as well. That might be beyond what we are trying to achieve with this particular request, but I think it would be a great addition. Even if it must go into another request, I think the developer community would get a lot of mileage out of a feature like that.