WYSIWYG API

I've made some progress on this. The attached patch adds some extra fields to the generated form so that functions further down the form rendering line can correctly determine the input format to use for the field, and WYSIWYG can then do its thing. This works with and without the Better Formats module.

Unfortunately, WYSIWYGs 'thing' (for the TinyMCE plugin at least) involves hiding the textarea element (using CSS display:none) and introducing its own set of elements including an iframe inside of which the actual editing is done in a body element, which breaks Editable Fields handling of the onblur event attached to the textarea.

So I can see a few things that (might) need to be done in the JS, at least for the TinyMCE plugin and using the "click to edit" display type:

• detect if WYSIWYG is rendering a plugin, if so:
• remove the onblur handler for the textarea element, and add one to the body element in the (TinyMCE) iframe (which gets the focus once TinyMCE has rendered itself), or whatever the current active element is that's being used by the WYSIWYG plugin.
• The onblur handler for the body element should (could) then call wysiwygDetach, which causes whatever plugin was rendered to unrender and save the edited contents back into the regular textarea element. I guess it should then just call the regular onblur function.
• Add WYSIWYG support to Drupal.org text fields, cos I hate having to write <ul><li>... in comments and everywhere else... :P (that's right, this line is nothing to do with editablefields).

Also unfortunately, I don't have much time to mess around with this. I did do a bit and found I could get WYSIWYG to detach its plugin with this bit of code at the start of the Drupal.editablefields.onblur function:

  var params = new Object();
  params.field = element.Drupal.wysiwyg.activeId;
  Drupal.wysiwygDetach(element, params);

With the above code if WYSIWYG is loaded then as soon as you click in the editor or anywhere else it unloads and you're left with the regular textarea (since the contents hasn't changed and editable fields currently doesn't collapse unchanged fields, see #878094: Provide a Save button for some fields).

Clearly this comment is pretty my-case-centric, as it mostly address TinyMCE and the "click to edit" display type which I would like to use. It would be good to have some WYSIWYG developers look into this to provide a bit of guidance to make it generic and robust. I'll post an issue for WYSIWYG for support for editable fields to this effect.

And now with the aforementioned patch...

The attached patch introduces a working version of this. Instead of the rather convoluted approach outlined above I realised this task would be much simpler to accomplish if a Save button was introduced instead of trying to use the onblur event. Thus the attached patch makes use of code provided in #878094: Provide a Save button for some fields to use a Save button to save and close the editable field, and will detach a WYSIWYG editor if it was used.

This patch has only been tested for the "click to edit" display type and the TinyMCE WYSIWYG plugin. I'm 99% sure it won't work for the other display types ("Editable (AJAX)" and "Editable (HTML)"), but I think it will work with any other WYSIWYG plugin (eg FCKEditor). Would bce nice if someone could add support for the other display types. I might get around to it eventually if not.

This probably belongs in the aforementioned "Save button" thread, but I reckon it would be nice (as if having WYSIWYG support wasn't enough) to have three buttons: "Save", "Save and close", and "Cancel".

Hi Oliver,

I'm planning to commit the code at #359216: huge memory requirement for view with editable fields. pretty soon (if there aren't any big bugs in it).

For performance reasons (think about having 100 WYSIWYG editors in one page) I think we should consider handling this feature a bit different.
The WYSIWYG editor should be initialised only when the user focuses on it. I supports this? I already did the same thing for resizable textareas in the above mentioned patch (basically, if you have more than 25 html_editable textareas generated it will include an overriding JS file that deals with onfocus events).

I would very much like to hear your thoughts regarding this.

Cheers,
Andrei

I've created a new branch where all the new features will go in.

Advance apologies if I misunderstand what you're getting at, let me know if you think I have...

I agree it would be nice to be able to activate WYSIWYG only on a focus event for inside Views. However wouldn't this be effectively the same as using the Click to edit formatter?

In fact, if WYSIWYG was being used to edit the contents of fields, then displaying the field with HTML (Editable|AJAX) formatters and the WYSIWYG editor disabled would perhaps make little sense (I can't see my clients liking seeing raw HTML in a text box, View or not)?

In the #878094: Provide a Save button for some fields issue you propose being able to create formatters. Perhaps in this settings page we could add a warning that if the fields are being edited with the WYSIWYG editor and "Click to edit" isn't being used with this formatter then it may not be suitable for use in Views due to large memory requirements?

There's no need to apologise. I prefer to have X opinions before I start coding on something. This way I get a better understanding of the people's needs related to this module. I'm still new to this module and I like to get feedback about how other users are using it.

Regarding WYSIWYG in Views: please note that I said that you are already able to disable the setting related to resizable textareas in 6.3 dev snapshot. There is no UI for now but if set a variable called "editablefields_textareas_resizable_threshold" to 0 in your database then the code will render all html editablefields in views as normal. Otherwise, the current limit is 25: if there are more than 25 html_edit fields in the page the code will include an override JS file that will make those textareas as normal ones until you click/focus on them at which point the "magically" become resizable.

I agree that we can put some options in the formatters page and you would be able to control on a per formatter's basis how this would behave. The problem right now is that we have a lot more important stuff to fix or to add before that ticket is going to be finished.

So, for the time being I'm going to focus on having some sane defaults and a global settings page where you'll be able to override these settings.

Cheers,
Andrei

How about we use the same or a similar global setting (for now at least) for controlling use of WYSIWYG enabled formatters in Views, but instead of disabling/enabling WYSIWYG it would automatically make all WYSIWYG enabled text fields render using the Click to edit formatter (when the threshold is reached).

The only problem I see with this from a usability perspective is that if site admins aren't aware of this feature then they could spend a lot of time working out why all of a sudden the text fields in a view aren't rendering with WYSIWYG when they increased the limit of the view or added another text field to their node type, etc. Perhaps a warning message for site admins could be displayed on the view if the feature becomes active. This would probably be a must have to avoid hundreds of wasted hours, bug reports and sheer annoyance...

Re #8: I don't really agree with that idea... As you said, it is going to be extremely confusing.
I'll commit some stuff that adds the WYSIWYG implementation along with the save/cancel buttons and when we have something to test we might have a better idea.

Cheers,
Andrei

Subscribing...

I'll help review and test this as soon as I'm done with a few tasks for a client.

Subscribing

Per https://drupal.org/node/2148735, 6.x is longer maintained so issue is closed. If you wish to be a maintainer of the 6.x branch please create a new issue.