Problem/Motivation

Variables within twig templates can still be very interesting, they can be objects, render arrays and strings.

Render arrays itself can be #type, or #theme or have #theme_wrappers, etc.

Proposed resolution

Create a twig function to tell information about a variable:

{{ get_variable_information(pager_next) }}
This is a "render array".

It has the following variables defined:
* url, text

It has #type = link and two #theme_wrappers

or something like that.

It is introspection within Twig.

Remaining tasks

* Write a proof-of-concept approach

User interface changes

API changes

* #1804998: Add LadyBug from Symfony to Core to allow debugging variables within templates

Original report by jenlampton

It would be great if we could give our front-end devs a way to see all available variables in any given template. Something along the lines of the token UI that would show top-level items, and then allow a drill-down into each one (if available) would be awesome.

I understand something like this may be possible now that we are using Twig and Objects!
Let's make some front-end devs happy :)

marking as postponed till we get the engine working :)

Comments

psynaptic’s picture

Excellent idea! I would be happy to work on this when the time is right.

Fabianx’s picture

Here are some ideas:

@dealancer just presented me his sandbox for auto-completion of entity metadata things. That got me the idea. We _can_ wrap entities within a MetaDataWrapper Container and such could have easy: node.title, node.body.value, etc. And even {% getInfo(node) %}, which could give the properties based on the meta-data. As we are controlling access to all variables already anyway, we can easily wrap objects of type "entity" with the wrapper. That could even allow code-completion via IDE :-). - Fabianx

Here are some links for later reference:

http://drupal.org/node/1021556
http://drupal.org/sandbox/vackar/1806252

jenlampton’s picture

Think some progress has been made in #1805526: {{ _self }} in the frontend => How do I dump or debug things? towards this goal.

Fabianx’s picture

Status: Postponed » Active

It is active!

budda’s picture

Component: Twig engine » Twig templates conversion (front-end branch)

Having read this and #1805526: {{ _self }} in the frontend => How do I dump or debug things? what is actually desired in the end?

On the other thread the following is mentioned:

<pre style="overflow: scroll; height: 300px">
{{ dump(_self) }}
</pre>

or just {{ dump() }} for the whole context.

Are you wanting something more like the Krumo / kpr() command which does the collapsed drill-down data?

Fabianx’s picture

Yes, wanted some token like browser to drill down into variables, but will do so in contrib probably.

Fabianx’s picture

Title: Create a variable inspector for the TemplateData Object? » [META] Make it possible to inspect twig variables and get information about objects and render arrays
Project: » Drupal core
Version: » 8.x-dev
Component: Twig templates conversion (front-end branch) » theme system

Moving to core and making it meta.

Fabianx’s picture

Issue summary: View changes

Update issue

Cottser’s picture

Issue tags: +Twig

Tagging.

soulston’s picture

There is a similar discussion about dumping out variables going on here https://drupal.org/node/1804998 (Add LadyBug from Symphony to Core to allow debugging variables within templates)

soulston’s picture

Issue summary: View changes

Add related issue

joelpittet’s picture

Cottser’s picture

Version: 8.0.x-dev » 9.x-dev
Status: Active » Postponed

I think this should be explored in contrib first. We do have some fairly nice things like the Kint module that is part of the Devel module in D8 contrib and I'm excited for other possibilities!

catch’s picture

Version: 9.x-dev » 8.1.x-dev

We can add experimental support, or full support, for this, in a minor release.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Chi’s picture

Status: Postponed » Active
Issue tags: +DX (Developer Experience), +TX (Themer Experience)

Write a proof-of-concept approach

I just added an integration for Symfony VarDumper component to Twig tweak module. We may consider this as a proof of concept.

markcarver’s picture

Status: Active » Postponed

The {{ drupal_dump() }} function in Twig Tweak module isn't a "proof of concept" for this issue (read issue this issue and its summary).

It's just a wrapper around {{ dump() }} (which we already have). Thus, this module is actually duplicating (and confusing) existing functionality.

This issue is, specifically, about providing better information about variables; not just "dumping them". In particular, and in regard to render arrays, the #type and #theme hook used.

This also doesn't change the state of #11, so setting back to postponed.

edit: updated link to correct comment number for why this issue is postponed.

Chi’s picture

I agree the issue is not just about dumping.

duplicating (and confusing) existing functionality

Unfortunately existing functionality is not quite useful because it relies on pure PHP var_dump function.

so setting back to postponed

Can you explain why? The issue is targeted against 8.4. What are we waiting for?