Closed (fixed)
Project:
Drupal core
Version:
9.5.x-dev
Component:
theme system
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
30 Aug 2022 at 13:55 UTC
Updated:
15 Sep 2022 at 16:24 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
mherchelComment #3
lauriiiComment #4
lauriii🙈
Comment #6
lauriiiI swear that test was passing locally.. But it did fail locally 😬
I improved the tests and it should pass now.
Comment #7
mherchelOMG this is amazing! You're doing the Lord's work here @lauriii!
I tried to break this through various means of inserting emojis and nonsensical data. I also installed the Twig Tweak module and tested with that to make sure it works... and it all worked as expected!
Below is the result from inserting a
{{ dd(_context) }}intocore/themes/olivero/templates/content/node--teaser.html.twigComment #8
alexpottI think we should reconsider the naming of
drupal_dump()anddd(). I think dd() originates in Laravel and means dump and die as in stop execution. It means the same thing in Symfony too - see vendor/symfony/var-dumper/Resources/functions/dump.php. For more info see https://laravel.com/docs/9.x/helpers#method-ddI think we should be adding a single function here called
dump- I don't think the "drupal_" adds anything. And dump would do pretty much what it does in Symfony and Laravel too.Comment #9
alexpottAnother argument in favour of #8 is if you have core's dev dependencies installed and you do dd() in PHP code it will dump and die.
Comment #10
lauriiiWondering if this could fly.. I'm overriding the
dump()function when\Symfony\Component\VarDumper\VarDumperis available.Comment #11
alexpottLet's make this a private class const
twig_var_dump()there'sShould we be doing something similar? I wonder why this is there?
Weird - so a lower priority comes first?
Comment #12
alexpottOh and the twig one does:
Which also seems reasonable in a way. Not sure.
Comment #14
lauriii#11.2: I think that may be something specific to the fact that
twig_var_dumpusesvar_dump. The var dumper code is a bit hard to grasp but it looks like it may have some processing for this use case.#11.3: One with lower priority takes precedent because it's loaded last.
Comment #15
lauriiiGot some feedback from @alexpott on Slack. This should address that.
Comment #16
alexpottI think this needs 'is_variadic' => TRUE in the options too now.
Comment #17
lauriiiThat's true 👍
Comment #18
alexpottfinal and static or $this... imo we should be doing self:: everywhere here. There's no point doing $this::
This can be a 1 liner with less variables :)
Comment #19
lauriiiThis should address #18. Thanks for the reviews! 🙏
Comment #20
mherchelThis looks amazing to me.
Things I tested
{{ dump(_context) }}{{ dump(node, content) }}{{ dump(sdfsadfasfsd) }}I also disabled Twig debug and verified that the output does not show.
Comment #21
alexpottCommitted and pushed 07994b06fb to 10.1.x and 6c1225de86 to 10.0.x and 6425af2663 to 9.5.x. Thanks!
Comment #25
chi commentedI'm a bit late to the party, but don't you think that PHPDoc for the $variables parameter is wrong?
References:
https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/modules/upda...
https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/lib/Drupal/C...
Also we could have native
mixedtypehint for that parameter.Comment #26
lauriiiI think we could fix that in a follow-up 👍 I'm happy to review that so feel free to link that here.
Comment #27
chi commentedSubmitted a follow-up.
#3307344: Wrong documentation for DebugExtension::dump