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.
When adding a markup component to a webform using form builder, the wysiwyg doesn't load. It looks like it's because the wysiwyg.js isn't properly returned when form builder makes its ajax request. In form_builder_json_output(), the javascript settings are properly returned, but any additional javascript scripts that are added aren't.
Comment | File | Size | Author |
---|---|---|---|
#17 | form_builder-wysiwyg-1532536-17.patch | 3.78 KB | JeffM2001 |
#13 | spinning-around.png | 10.99 KB | franz.skaaning |
Comments
Comment #1
quicksketchThanks for the report. I've noticed this also.
Comment #2
duellj CreditAttribution: duellj commentedAnother thing to note is that even if the correct wysiwyg javascript is added to the component form, the output from the wysiwyg is never saved, since form_builder is watching for onchange events from the textarea, and the textarea doesn't get updated from the wysiwyg unless a submit button is pressed (or the text format is changed).
Comment #3
duellj CreditAttribution: duellj commentedI was able to hack a solution:
Basically this manually adds the wysiwyg js into the form, and then adds an autosave callback for TinyMCE to update the textarea and trigger a change (which updates the form builder form).
Obviously this won't work for other wysiwygs, and I'm not sure how this would integrate into form_builder, but it's a short term solution for me.
Comment #4
avergara CreditAttribution: avergara commentedHi duellj,
Do you happen to know what is the alternative for
drupal_add_library('system', 'drupal.textarea');
on drupal 6?Comment #5
avergara CreditAttribution: avergara commentedSeems like simply adding a dummy textarea with filter_format works for drupal 6
Comment #6
cgove CreditAttribution: cgove commentedThe fix in #3 works for form builder, but breaks the WYSIWYG in the panels in-place editor.
Comment #7
heyyo CreditAttribution: heyyo commentedI'm looking for the same kind of solution but for Ckeditor only.
Comment #8
abarpetia CreditAttribution: abarpetia commentedHello heyyo,
Did you got this solution for Ckeditor?
Comment #9
pjbarry21 CreditAttribution: pjbarry21 commentedI'm also running into this problem with ckeditor. Doesn't load in markup.
Comment #10
Plits CreditAttribution: Plits commentedHello,
I had the same issue with a customized form builder using ckeditor. I managed to make it work with a simple hack :
You will also need to add some JS to properly handle the saving mechanism :
This will load the required ckeditor files without creating any unwanted for element in the DOM and it should work fine.
Regards,
Alan
Comment #11
Lams CreditAttribution: Lams as a volunteer commentedThe solution in #7 was breaking form builder ui drag and drop component for me (form builder v7.x-1.7). The code chokes on
CKEDITOR = CKEDITOR || {};
(error is CKEDITOR undefined). I attempted to fix this; but, it was surprisingly difficult.I am still using the php component of #7; but, I replaced the JS with the following:
I wrote a different technique that isolates the configure button for markup fields specifically and unbinds the click event so that the field opens in a new window where CkEditor can load. The destination value of the link also needed to be fixed (in some cases) so that the user could come back to the webform and save. The jQuery targeting could be improved; but, it is working.
Why form builder 7.x-1.7? The later versions (I was using 7.x-1.14) seem to focus on moving to OOP, which is great; but, they broke (among other things) the ability to successfully create radio buttons (issues with options). Fixing this cascaded other issues for me; so, I researched and found this more stable version.
Comment #12
torotil CreditAttribution: torotil at more onion commentedI've committed a fix for #2709179: Loading CSS/JS in element configuration does not work today. This means
#attached
anddrupal_add_*
should now work in field configuration forms. Does this change anything wrt this issue?Comment #13
franz.skaaning CreditAttribution: franz.skaaning commentedUsing 7.18 still does not work with ckeditor on webform.
Also when closing an area the spinner just keeps spinning if I try to reopen the same or another.
Comment #14
torotil CreditAttribution: torotil at more onion commentedA fix for the spinning is already in 7.x-1.x. That means that the remaining issue is now with form_builder's auto-submit.
Usually before submitting a form the wysiwyg editor first puts the updated text into the original (and hidden) textarea. This does not happen with when the field-configuration is submitted via auto-submit so the content is lost. I don't have a ready solution for that yet.
Comment #15
interdruper CreditAttribution: interdruper commentedIf it helps... in my case, the exception reported in #2665706: Database updates #7002 Integrity constraint violation is associated with this issue. There is one more error while markup element becomes unusable:
callback form_builder_deliver_ajax_or_html not found: admin/structure/form-builder/configure/webform/1210/new_1472815707400.
CKEditor is being used.
Comment #16
torotil CreditAttribution: torotil at more onion commented@interdruper: In what way do you think the issues are related?
Comment #17
JeffM2001 CreditAttribution: JeffM2001 commentedHere's a patch that gets the Markup component working with the wysiwyg module. The approach is roughly based on what's done in panopoly_magic — wrapping the wysiwyg.attach.* javascript functions with additional code that adds event handlers. I've tested it to work with both TinyMCE and CKeditor.
Note, if you are also using panopoly_magic, you will need the patch from this issue as well: #2924074: Don't wrap WYSIWYG attach when not necessary
Comment #18
torotil CreditAttribution: torotil at more onion commentedMany thanks for the patch @Jeff.
There is an issue in #641900: Integration: Trigger javascript on WYSIWYG attach? which seems to aim at providing a more reliable JS interface for this. Is there already something usable in there?
Until then I think it’s ok to use some sort of hack.
Comment #19
torotil CreditAttribution: torotil at more onion commentedAnother idea to try to make this simpler:
JavaScripts in the head are guaranteed to run in the specified order. So if we …
Then it should work too without too much of a hassle.
Comment #20
JeffM2001 CreditAttribution: JeffM2001 commented@torotil the last comment in that wysiwyg issue is 8 years old, so I wouldn't expect much to come from that.
On the suggestion in #19, I could be wrong, but I suspect that won't work when the element is added via AJAX. Even if form_builder.js is last in the head, it won't be able to wrap Drupal.wysiwyg.editor.attach.tinymce at that point because the wysiwyg plugin scripts aren't loaded until the element is rendered (
wysiwyg_pre_render_text_format()
callswysiwyg_get_profile()
callswysiwyg_load_editor()
). Perhaps if the script was attached when the markup component form is generated, but I'm not sure where to do that.This whole thing is pretty complicated with lots of moving parts, and I tried a bunch of different things before finding the panopoly_magic solution. I'd love for there to be a simpler solution if we can find it.
Comment #21
gbirch CreditAttribution: gbirch at Tag1 Consulting commentedFor what it's worth, the following approach seems to work with ckeditor 7.x-1.19 and form_builder 7.x-2.0-alpha8.
1) Edit the relevant text_format properties to replace:
'#wysiwyg' => FALSE,
with
'#pre_render' => ['ckeditor_pre_render_text_format'],
2) Create a new js file with an override to form_builder's elementChange method:
3) Add your js file to the form builder preview form: