Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I installed the Better Formats module not long ago so I could have better control over HTML tag permissions by role.
http://drupal.org/project/better_formats
After installing that and setting up the permission settings and limitations for roles, the Input Format settings for Filtered HTML was set to the HTML to text. (So as to strip out any HTML tags used by those in untrusted roles.) All of the webforms on the site where updated to use the Full HTML input filter. This worked fine to correct the display of the introductory section of the webform. However, HTML tags stored in connection with individual form components is not honored. (See attached screenshot from a form showing this issue.)
I suppose opting for the HTML to text setting for the Filtered HTML seems harsh. That action was prompted by an abuser who came into the site, registered, and within a few minutes had generated some content - thankfully only seen by myself as it was never published - that contained highly undesirable images, links, etc. This is a community site, however, and there are others acting as moderators of content. Although I would hope my moderators are smart enough not to fall for "lures" such as those used, I thought I could eliminate some of the risk by stripping out the ability to use any HTML tags; especially the URL filter so as to block the creation of clickable links. (Mollom is also active on the site, but this particular post got by that too!) Just didn't expect such a setting to be blocking HTML tags in form components within created Webforms too! I thought that would follow the Input filter set for the overall form itself.
| Comment | File | Size | Author |
|---|---|---|---|
| Webform-Componets-Ignored-HTML11-30-2009.png | 12.52 KB | IreneKraus |
Comments
Comment #1
David_Rothstein commentedAs far as I understand, the Webform module uses your site's default input format for filtering descriptions such as those shown in your screenshot. So assuming Filtered HTML is your default format, this behavior is expected.
Probably it could be a feature request to have explicit input format support on webform component descriptions, but doesn't seem like a bug. I don't think it would make sense to inherit the input format settings from the main part of the webform, since that's a totally different textarea and might have totally different requirements.
I'm not sure where the "HTML to text" setting is coming from, but that's usually intended for when HTML is being output in an email or something - its results don't make much sense on a webpage (as you can see in your screenshot). Why don't you just use the normal HTML filter here and configure it to strip out the tags you don't want? You should never allow untrusted users to use the <img> tag, for example (which would solve most of your problem) and if you don't want them including links either, then turning off the URL filter (which you already did) as well as denying them access to the <a> tag would work. But it's always safe to enable simple tags like <em> and <strong> for the default format, and it seems like doing that is all you would need to get the text shown in your screenshot to appear correctly.
Comment #2
IreneKraus commentedI'm in the process of making this change. That is, allowing the basic safe tags for boldface and italics for the default format. So far, this seems to have resolved the issue.
Comment #3
jfinkel commentedA form component text often has to include a link to another node. Consider a checkbox that indicates that the user has read the Terms of Service. The Terms of Service needs to be a link to another node. I can find no easy way to do this in the Option text. I have to put it in the component's Description. Not a huge deal, but sort of sloppy and requires CSS to position nicely.