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.
By Ken Watts on
I'm trying to include some svg in a form, in conjuction with radio elements.
I've been using #prefix, #suffix, and <foriegnObject>
The strange thing that's been happening is that when it creates the form drupal has been changing the prefix and suffix code my module inserted.
Specifically, it has been closing off all the svg code in the prefix (adding </svg> at the end of the prefix), and it has been eliminating whole sections of the #suffix. This breaks my code. (by the way, the code I'm trying to achieve already works perfectly if I simply insert it by hand into a node and display it that way--so the problem is definitely the changes)
I've been assuming that this must be some incompatibility of drupal with svg, that it sees this as bad html code and tries to fix it--but I cannot figure out where this is happening in the core modules, or what a work-around might be.
Any suggestions?
Thanks.
Comments
Are you seeing these closing
Are you seeing these closing tags in the HTML source?
Drupal won't auto-close tags created in the #prefix or #suffix, so there is nothing to look for there.
Yes. Exactly. They show up in
Yes. Exactly. They show up in the source code for the page, after the prefix, and the closing tags I put in the suffix are removed.
Thanks for the help.
Just to double-check.
Sorry to ask again, but it does bear repeating.
Did you actually "View Source"?
Possible answers are
"Yes, I used the browser 'View Source' option and scrolled down through the raw text to find my strings"
and
"No, not really, I just used the browser DOM/Element inspector, which shows me something that looks like the source code but is in fact a regurgitation of what the browser *thinks* you mean after it's corrected all the syntax problems and incorrectly nested stuff using its own algorithms"
Most often, when it *seems* like an element has been closed prematurely, or that a closing tag has gone missing, it's because someone is using the DOM inspector to see the interpreted version of the code (which by definition will never show any syntax errors) and not directly looking at the source where the syntax, nesting, or validity errors are actually introduced. This matches perfectly with the problem as you describe it. Comparing what you actually said with what the browser thinks you meant directly (the difference between view-source and inspect-element) often leads to the obvious answer.
So, were you lying to the support desk and making it harder to solve? Or did you actually really "View source"?
:-D
.dan. is the New Zealand Drupal Developer working on Government Web Standards
I am humbled. I did not know
I am humbled. I did not know that firebug showed me anything but the actual source.
So. If the source is correct, then how do I keep the browser from lousing up my code? And why didn't it louse up the exact same code when I just pasted it into a node to check it?
Any hints welcomed...
And thanks for pointing out the error of my ways...
Sorry for my smugness
Sorry for my smugness ;-)
This really is a loopy trap, that I enjoy pointing out...
OK, so your HTML is what you think it should be and what you think (and have proved out of context?) can render...
My first guess would be the DOCTYPE - which can/would affect handling of weird embeds like SVG.
But as you tested in a node body already, probably not that.
Does copying the EXACT output from view-source after it's gone through the FAPI into your node still work just as well?
Maybe pasting the full view-source text into the W3C validator may indicate why your browser isn't treating it right?
.dan. is the New Zealand Drupal Developer working on Government Web Standards
That was the trap I was
That was the trap I was referring to as well, I should have spelled it out better in my question than just asking if he'd viewed the source, I'm glad you were able to pick up on what I was getting at.
I spent a full-day trying to track down a non-existent closing tag one time. That's when I learned about the discrepancy between what firebug shows, and what is in the actual code.
I'm still chasing it down,
I'm still chasing it down, but want to thank all of you for putting me on the right track. I'll report back when I get it figured out, or if I get completely stuck again. :-)
Thanks for saving me more days of chasing my own shadow.
Ken
Okay, I found it, and
Okay, I found it, and wouldn't have without your tips, at least not for a long, long, time.
It was a misspelled tag, which apparently triggered a chain reaction in the browser. Anyway when I spotted it and changed it, the code was fixed. So thank you very, very much!
Great work!!
Hello,
Glad to hear you got it working :) Please make sure you edit the subject line of your original post, add "[SOLVED]" to either the beginning or end (of the subject line). That way, other folks can find the solution.
In addition, I wanted to suggest using a "programmers" editor. There are many editor which perform real-time check of html. css, javascript, php, you name it. Many free IDE's like Eclipse or Netbeans have editors that will analyze your code. A really big time saver :) It basically works the same way a spell checker does (except for html. css, computer languages, etc).
You are welcome :)
Good Luck :)
Big win!
Hey Dan,
I came across this in Google, I was getting frustrated that Google Chrome's inspector was claiming my prefix was being auto completed by Drupal. I then did a view source as you suggested and sure enough, Drupal was outputting the correct code but Chrome's inspector/dev tools were overriding the actual output. I know FF does this a lot with CSS but had no idea it would change markup also.
If anyone knows a way to turn that off please let me know!
Thanks again Dan!
-----------------------------------------------
The Future is Open!
You can't "turn it off". The
You can't "turn it off".
The DOM inspector is a (realtime) view of the data model the browser has of the page. Every tag must be closed, and have a parent. All major invalidities must smoothed out, all attributes must have valid strings, etc.
If you give it bad strings and tag soup, every browser will interpret it a lot or a little, and make corrections on the fly to get to what it thinks is a valid document object model simply to be able to do anything with it. Then that is displayed on the screen, and then an HTML-version of the memory state is generated and displayed as the DOM Inspector.
If you had an unclosed tag, it wouldn't be able to be displayed in the DOM inspector because the data simply would not be a tree any more. The tag wouldn't be a valid bit of data for the browser to work with, all would be broken.
So, um, validate your code, y'all!
.dan. is the New Zealand Drupal Developer working on Government Web Standards
(No subject)
.
A question
Hello,
First, the issue of "how I do view html source with my web browser", really should be a separate post :)
The original post is about diagnosing the Drupal Form API. Let's remember that a good deal of the Drupal Form API processing occurs on the server, not in the web browser. Looking at the html doesn't diagnose where in the server process, an issue is occuring. The html source simply indicates there is an issue with the server process:)
For argument sake, lets say the original poster was working on a site that had additional modules (and/or themes) altering the form in question. The original poster would need to examine the server processing that occurred after (or along side) his module:)
Thus, asking someone to review the html source is a good step. However, it's just a step :)
I use Chromium web tools. The network tab provides the same thing as the old "view document source" (only a whole lot more). Thus, use the network tab to review the servers raw response:
Please open a separate post if you really want to discuss how to use diagnostic tools :) A worthy subject, no doubt:)
Would that mean it's
Would that mean it's something the theme is doing? I'm using Zen.
A suggestion
Hello,
The short answer is, a form display can be changed at either the module or theme layer.
Personally, I always string test (AKA unit test) everything. Have you verified that your implementation is not throwing any exceptions (errors)? Again. personally, I would start with a verification of my own code first :)
Once I verified my code is working as expected, then I run Drupal through a debugger. Put a break point on my form code, then trace execution till the form is rendered. In a dynamic environment like php (and potentially javascript), that's only sure way of finding where in the process, the unexpected results are produced.
One other idea, although this really doesn't sound like your issue. Can you verify that your web server is configured to handle the svg mime. Again. that really doesn't sound like it's your issue. But couldn't hurt to check.
Good Luck :)