Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Renderviz breaks the form action value. An example from the user login form:
<form class="user-login-form" data-drupal-selector="user-login-form" action="<!--RENDERER_START--><!--{"contexts":["languages:language_interface","theme","url.path","url.query_args","user.permissions"],"tags":[],"max-age":-1}--><!--{"tags":[],"max-age":-1,"contexts":["languages:language_interface","theme","user.permissions"]}-->/user/login<!--RENDERER_END-->" method="post" id="user-login-form" accept-charset="UTF-8">
Comment | File | Size | Author |
---|---|---|---|
#19 | renderviz2016-09-30_1044.png | 192.98 KB | itsekhmistro |
#18 | Screen Shot 2016-09-27 at 13.37.46.png | 166.03 KB | Wim Leers |
#14 | interdiff.txt | 1.48 KB | Wim Leers |
#13 | 2640280-12.patch | 1.16 KB | Wim Leers |
Comments
Comment #2
claudiu.cristeaI guess because the action url is a placeholder?
Comment #3
claudiu.cristeaEDIT: accidentally duplicated.
Comment #4
Wim LeersIndeed.
Comment #5
Wim LeersComment #6
Wim LeersActually, the problem is broader: any non-HTML rendered output cannot be visualized by renderviz (at least not for now that's out of scope), because there's no HTML element to target that we can set a 3D transform, an outline or a box-shadow on. So, don't wrap any output that is not HTML (i.e. that is plain text) in renderviz metadata (which uses HTML comments).
Tested this approach on a page with a node comment form:
As you can see, only plain text has its wrapping renderviz metadata removed.
In fact, both before and after, we get
206 unique rendered elements on the page.
— so thejquery.comments.js
jQuery Plugin wasn't even able to find those comments anyway in the first place!Comment #7
Wim LeersComment #8
Wim LeersI can confirm that this fixes all forms (e.g. comment form, module form, node form, star-to-add-or-remove-shortcut, et cetera).
Comment #9
itsekhmistro CreditAttribution: itsekhmistro at Adyax commentedHi Wim,
I have faced same issue with debug output and created a patch for it,
have contacted about it on your blog.
Please check the patch attached, it looks safer cause the patch in comment #6 will also exclude an output like "text ..." from debug.
What do you think?
Comment #10
Wim LeersInteresting :)
Why would excluding
text…
be wrong? It's not HTML, so we wouldn't be able to safely wrap it. So it's behavior would be correct. The behavior of your patch is the same for that particular example.Can you give an example where your patch does the correct thing and mine (in #6) doesn't?
Comment #11
itsekhmistro CreditAttribution: itsekhmistro at Adyax commentedHi,
The ... dots in the example in comment #9 are a link.
"text <a>...</a>"
I mean if the result output doesn't start with a tag but contains a tag/tags inside
- then we can consider that the output can be safely wrapped with debug info.
Comment #12
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedRTBC for #9
Comment #13
Wim Leers+1. But I didn't think the comment was very clear.
Comment #14
Wim LeersThe interdiff was wrong.
Comment #15
Wim LeersAssigning credit.
Comment #17
Wim LeersUgh, I failed to squash the commits. My bad. But no big deal :)
Comment #18
Wim LeersIt looks like this caused a serious regression…
Comment #19
itsekhmistro CreditAttribution: itsekhmistro at Adyax commentedHi Wim,
Tested the latest version (with the patch applied).
Looks good as for me, please see the attached screenshot.
For the test I have used a fresh Drupal installation based the latest version of Drupal core (8.1.10).
Could you confirm that you 've got a regression ?