CKEditor support for textfields [#2427559]

If you have a plain text field in Drupal that uses the wysiwyg (ckeditor) widget, no text will appear and when you attempt to save the text entered in ckeditor will not save.

This is because of how CKEDITOR.replace() works. it will use the innerHTML() of any DOM element, http://docs.ckeditor.com/#!/api/CKEDITOR-method-replace. To get around this it might be possible to clone the original textfield before calling CKEDITOR.replace, replacing the textfield with a textarea. Then when the CKEDITOR instance is destroyed, the original textfield may replace the textarea that was created.

Comment	File	Size	Author
#16	wysiwyg-2.3-ckeditor_text_field_support-2427559-15.patch	1.27 KB	nplowman
#14	wysiwyg-ckeditor-textfield.patch	1.4 KB	dlriley
#12	wysiwyg-2.3-ckeditor_text_field_support-2427559-8.patch	1.31 KB	sgalindo2388
#8	wysiwyg-2.3-ckeditor_text_field_support-2427559-8.patch.txt	1.32 KB	Stefan Lehmann
#6	wysiwyg-ckeditor_text_field_support-2427559-6.patch.txt	1.51 KB	blake.thompson
#1	wysiwyg-ckeditor_text_field_support-2427559-1.patch	1.48 KB	svajlenka

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

svajlenka CreditAttribution: svajlenka commented 16 February 2015 at 23:23

Version:

7.x-2.2

» 7.x-2.x-dev

File	Size
wysiwyg-ckeditor_text_field_support-2427559-1.patch	1.48 KB

This also affects 2.x-dev, I'm also supplying a patch made against dev.

Comment #2

svajlenka CreditAttribution: svajlenka commented 16 February 2015 at 23:24

Status:

Active

» Needs review

Comment #3

TwoD

Swedish

Sweden

CreditAttribution: TwoD commented 17 February 2015 at 02:05

Component:

Code

» Editor - CKEditor

Thanks for the patch!
I've been meaning to write something like this for a long time, see #971632: CKeditor breaks on text field (not on field type Long Text) but I've just not gotten around to it.

I see one potential problem with this specific implementation though. What happens if another script has references to the original field or attaches events to that element? Since it's being cloned and replaced, I'm assuming those events would get lost.

What if we instead just hide the original field and create the new textarea next to it, then sync contents to the textfield after detaching?
That'll keep all references/events intact (and things like onchange should trigger when the contents do change).
Do we need to consider newlines? A quick experiment seems to indicate that newlines will simply be ignored when put into a textfield.

Maybe we should make it so that the editor implementations do not have to worry about this at all and always see textareas by moving this into wysiwyg.js (maybe into Drupal.wysiwyg[De|At]tach()). That would take care of FCKeditor as well (yes, I think some are still using it.) I don't remember if all other supported editors work with textfields. If they do, maybe just copy this change to FCKEditor...

Comment #4

jojonaloha CreditAttribution: jojonaloha at Metal Toad commented 13 October 2015 at 22:33

The patch in #1 fixed the issue for me using Wysiwyg 7.x-2.2.

Comment #5

sadashiv CreditAttribution: sadashiv commented 17 December 2015 at 05:29

#1 worked for me.

Thanks,
Sadashiv.

Comment #6

blake.thompson CreditAttribution: blake.thompson at Forum One commented 10 January 2017 at 16:58

File	Size
wysiwyg-ckeditor_text_field_support-2427559-6.patch.txt	1.51 KB

The patch in #1 kept the data when changing text formats but didn't save the changes when the input was a textarea. Updated patch fixed that issue for me.

Comment #7

VeniaminLopatin CreditAttribution: VeniaminLopatin commented 17 February 2017 at 14:26

The problem is still exists in 7.x-2.3 version.
Is here any solution for that?

Comment #8

Stefan Lehmann CreditAttribution: Stefan Lehmann at Sparks Interactive commented 12 March 2017 at 23:42

File	Size
wysiwyg-2.3-ckeditor_text_field_support-2427559-8.patch.txt	1.32 KB

I just reapplied the patch from #7 to the 7.x-2.3 version and it still seems to work, when put into the correct place. Might fix the issue for people until somebody comes around with a real fix.

Comment #9

JamesOakley

he/him/his

English

Kent, UK

CreditAttribution: JamesOakley commented 20 March 2017 at 13:19

I'd gladly submit an amended patch, but I don't understand how this particular module works. So I'll report the problem and someone else can comment on how easy it would be to fix.

The patch at #7 fixes the problem on a test site I tried it on. However, the ckeditor text area that was created was collapsed into minimum height, so that (even though a text field had content in it), it still looked empty when the rich text editor was enabled. I therefore almost thought the patch hadn't worked, until I dragged the resize handle down, then I could see the content in the editor.

Is there any way to set the starting height for the rich text editor to be one line high?

Comment #10

TwoD

Swedish

Sweden

CreditAttribution: TwoD commented 20 March 2017 at 13:43

I'm not very happy about replacing the original field completely because we may destroy event handlers attached to it, and we'll have no way to add them back.

I think if we on attach instead hide the original field, insert a textarea with some unique id, and then attach the editor to that.
On detach we detach the editor, sync the contents to the original field, and then remove the textarea.
One issue is that the editor will need to attach to a different id than what the client has been passed settings for so that part will be out of sync. "Outwards" will also have to give the appearance of attaching to the original textfield using the original id, or 3rd party code will not find the correct editor instance.

Comment #11

Stefan Lehmann CreditAttribution: Stefan Lehmann at Sparks Interactive commented 20 March 2017 at 20:39

@JamesOakley:

Is there any way to set the starting height for the rich text editor to be one line high?

You could probably try to add a style attribute on the textarea with a minimum height value or so ..

@TwoD:
Yeah I thought so too. However it's an interim solution for people who have clients strangling their necks. :-) Before that issue I didn't even know that one can assign a WYSIWYG to a normal textfield.