can anyone elaborate how can I enable rich text editor for webform description field? (it is currently available for redirect or confirmation message??)

I have instilled TinyMCE

thank you

CommentFileSizeAuthor
#8 description.JPG64.49 KBarx-e
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

axon’s picture

Title: Webform description field and Eich Text Editor » Webform description field and Rich Text Editor
quicksketch’s picture

Status: Active » Closed (fixed)

TinyMCE is not supported with Webform.

dewpurdy’s picture

I've had the same issue. To get around the problem, I edited my description in the confirmation field, then copied the html code over to description. A hassle, but it works until a more permanent solution is developed.

arx-e’s picture

Is there some other Wysiwyg editor supported in order to better format description?
I am trying with FCKeditor and CKeditor but none seems to work...

Note: I am using webform 6.x-3.2 (drupal 6.19)

arx-e’s picture

Version: 6.x-2.8 » 6.x-3.2
Category: task » support
Status: Closed (fixed) » Active
arx-e’s picture

From what I read http://drupal.org/node/599288 input format and according wysiwyg editor should be selectable for the description in webform 3.x.
I am now wondering why this is not the case with me???

quicksketch’s picture

The "description" (I'm assuming you mean the body field) is not affected in any way in Webform 3.x. You may not have WYSIWYG configured properly.

arx-e’s picture

FileSize
64.49 KB

I mean the text area labeled "Description" after the default value in each form component (see attachment).
I haven't found a way to enable a wysiwyg editor there and there is no input format choice.

quicksketch’s picture

Ah, okay. Yes WYSIWYGs will not work on those textareas because they do not use the filter system. We currently only allow strong, a, em tags I believe, making the usefulness of WYSIWYG on these fields rather minimal.

arx-e’s picture

Wouldn't it be nice to have full formating options there?

I am building a rather complex application form (http://admin.blueflag.gr/aitisi-aktes) and I am really missing this, especially in the fieldset component where I would like to give information and guidance to the applicants.

Is it (reasonably) possible to use the filter system on those text areas?

arx-e’s picture

Category: support » feature
quicksketch’s picture

Status: Active » Postponed

I probably won't be adding filter support to descriptions.

flaviovs’s picture

Since Forms API does not apply any filter to the "#description" attribute of any field, why do we do it here?

Any use cases where non-admin users are allowed to create form components for a site?

Which kind of security vulnerability we're trying to protect users that cannot also be "exploited" using a "Markup" field?

At least, can't the list of allowed tags be augmented to include some more useful formatting tags like <table> et al, <fieldset> etc.?

Or at least couldn't the module use the default input filter (e.g. "Filtered HTML") so at least the admin has some control of what is allowed?

quicksketch’s picture

The reason for not using the filtering system here is for simplicity, not for security. In my own experience the number of times that you need a WYSIWYG or more than a strong or em tag in a description very low. If you need more than a sentence, you probably should be using a markup field anyway.

Or at least couldn't the module use the default input filter (e.g. "Filtered HTML") so at least the admin has some control of what is allowed?

I think this is already the case. Webform uses the default format for descriptions. Though in Drupal 7 we had to change that to use a defined list of tags ('a', 'em', 'strong', 'code', and 'img' by default). You can change this too if really needed, though there is no UI option for doing so.

flaviovs’s picture

Thanks for the reply, quicksketch.

I fail to see how the filtering make the module (or user's life) any simpler. Somewhere in the code lies something like '#description' => filter_format($description) which cannot in any way be simpler than '#description' => $description!

BTW, I use rich description a lot. I was just trying to include a table on a field description when found this issue.

As the use of the default format, I don't think that webforms use it, at least not the version I'm using (6.x-2.7). My default format allows all table-related tags, but all of then were being chopped off when the field description was rendered. I had to use a "Markup" field to include the description needed, which solved my issue but caused other problems (layout related, not to mention that it's not semantically correct).

emdalton’s picture

The reason for not using the filtering system here is for simplicity, not for security. In my own experience the number of times that you need a WYSIWYG or more than a strong or em tag in a description very low. If you need more than a sentence, you probably should be using a markup field anyway.

Funny, my users seem to want to provide a formatted introduction to their webforms fairly regularly. It seems counter-intuitive to me to tell them they have to fill in the rest of the "add" form and create the webform before they can create a "markup" component to describe the webform, when there's a "Description" field right there, and the "Confirmation message or redirect URL" field right below it does use rich text.

Given that a formatted description holds no interest for you, would you accept a patch if I can put one together?

quicksketch’s picture

Funny, my users seem to want to provide a formatted introduction to their webforms fairly regularly.

This issue is not about an introduction to the form or the "Body" field shown when adding a new node, this is about the "description" or help text shown beneath every individual field. I definitely agree that if you're writing an introduction to the form, that should almost certainly be a rich-text field (or be possible to enable rich-text on that field). Most of the time this field is the "Body" field or another CCK field that has input filters enabled. Webform has no effect on these fields in any way and of course you can use a WYSIWYG and the Drupal filter system on them.

emdalton’s picture

Thanks for the response-- #3 made me think we were talking about the "Description" field in the "body" portion of the webform. I get WYSIWYG on the Webform's "Confirmation message or redirect URL" field, but not the "Description" field. I don't get an "Input Format" choice, either. I'm on 6.x-2.9. If I update to 6.x-3.x will that fix this? I've been putting it off because there always seems to be something more critical to do around here....

quicksketch’s picture

I get WYSIWYG on the Webform's "Confirmation message or redirect URL" field, but not the "Description" field. I don't get an "Input Format" choice, either.

Yes in the 2.x version both "Confirmation message or redirect URL" and the "Description" field (for the entire Webform, not an individual component), shared a single input format. In 3.x they have separate input format fields, allowing each to have a WYSIWYG.

emdalton’s picture

Ok, thanks.

negiti’s picture

negiti’s picture

I see that different content types can be webform-enabled in the 3.x version of the webform module. That. Is. Cool.

What I think means for me is that I can set up a page node for instance, edit the page content to my heart's content using whatever WYSIWYG editor I can schlep into Drupal 6.2, and start a webform as a subset of the page node, solving the rich content issue surrounding the "Body" field of the webform proper.

I am going to give this a go and see what comes of it.

negiti’s picture

. . having gone into Home › Administer › Site configuration > Webform settings, the first set of controls in the 3.x webform modules is titled, "Webform-enabled content types:", with a listing of my defined content types and a checkbox for each. Upon enabling (checking) the types in question and saving the changes, I find that:

- I can indeed establish webform subcomponents as part of existing node types.
- Even straight-ahead webforms have the desired WYSIWYG editor available now to edit the "Body" field in question.

Excellent.

"Spelling things out is so much work at the outset, and so very much less work at the end."

chaloum’s picture

I'd like to add my two cents worth here. basically all the fields need to be WYSIWYG. its tedious:"

  • building complex option lists and yes I've seen the option list modle but the is far to basic.
  • building question descriptions and supportive information.

I've modified the code somewhat to allow for markup to be used but doing this by hand time consuming and there is no way I could hand this over to a client

I would be great if this module would be an enabler for more user friendly forms than apply restrictions based upon assumptions.

david.a.king’s picture

as above- subscribed!

vernond’s picture

On the flip-side of that 2 cent coin in #24:

Why is it more reasonable to assume that "all the fields need to be WYSIWYG" than to assume that they do not, in fact, need to be WYSIWYG?

The purpose of Webform is to help you create complex surveys, questionaires and other input-intensive forms and it does that job amazingly well.

Using tools that already exist, and using the right tool for the right job, you can achieve the ends you desire:
a) Webform to build the form;
b) custom code and/or CSS and/or themeing and/or javascript to make it as pretty as you need.

It is not through evil intentions, laziness, or even oversight that these fields are not WYSIWYGed. Achieving that goal is not as trivial (IMO) as you seem to think. However, it certainly tends toward trivial when the time and effort it requires to implement is compared to "real" Webform issues (such as keeping two versions of Webform in sync, or trying to help some poor dude who cannot get submitted data downloaded from a form for some reason) - these issues relate to actual Webform functionality as it relates to the actual and stated purpose of Webform.

In my messy little mind, the engine that makes it go is waaaayyyyyy more important than what the neighbours think of the color of my cars bonnet. I'll expect the mechanics to look after the engine and I'll take the responsibility of spray-painting the bonnet (but ONLY if it absolutely MUST change color, or the neighbor is really really really really hot and I want to be a bit more impressive). But hey, that's just me and that's just my full half two cents :-)

Then again, I could be completely wrong and you bang out a five-line patch that solves the entire issue!

chaloum’s picture

@26 so your saying there is only one way one choice? You may find it fine but thats your choice, I and other dont get that choice. Plus its not just coder and people that are familiar with HTML hat need to use these forms?

vernond’s picture

What I'm actually trying to say (in a very convoluted way) is we should use the right tool for the right job. The description field is not meant to be used as a rich html display thing. It is meant to be used to provide some helpful information as users fill out the form.

Rich html can be achieved with a markup component placed immediately before or after the component you want to refer to. The markup component is available to all Webform users (assuming you have not disabled it in the main Webform configuration).

andrewfn’s picture

Issue summary: View changes

In #14 QuckSketch says there is no UI for making changes. However you can change the variable manually.
E.g. if you want to add list tags, you can run:

drush vset --format=json webform_allowed_tags '["a","em","strong","code","img","ul","ol","li"]'

Note that the above command should be on one line.

Check value is set with:

drush vget webform_allowed_tags
DanChadwick’s picture

Version: 6.x-3.2 » 7.x-4.0
Status: Postponed » Fixed

Re #32: this works in the current 7.x-4.0. Since there is a viable way to do this, I'm marking this feature as closed.

rcls’s picture

I have somewhat of a similar problem with this, except mine is with CKEditor and it doesn't let me save the settings at all now. I was able to insert something the first time I installed the module, but now after trying to insert a new value to the 'Submit button text' -field all I get is an error 'Text format -field is nescessary'.

http://i.imgur.com/vh6loDF.jpg

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

narayanis’s picture

@rcls, I've struggled with this for two hours myself today. The cause is due to the text format not being selected for the Preview Page option. To fix it, check the box to enable a preview, set the text format, and then uncheck the box again. Now you can save.