Opened 10 years ago

Last modified 10 years ago

#12167 confirmed Bug

The save plugin needs improvements

Reported by: Wiktor Walc Owned by:
Priority: Normal Milestone:
Component: General Version: 4.2
Keywords: Cc:

Description (last modified by Wiktor Walc)

It looks like the save plugin has been left in a state which is pretty much hard to explain and where this plugin isn't useful at all.

  1. The Save button is only available when editor.elementMode == CKEDITOR.ELEMENT_MODE_REPLACE, which means that it is not available for example in "Replace Textarea with Inline Editor" where editor mode is ELEMENT_MODE_INLINE.
  1. "Replace Textarea with Inline Editor" is not the only case where the Save buton would be useful. After all thanks to the "save" event each CKEditor instance can benefit from this button to save data using AJAX.
  1. The requirement of having a parent <form> element is invalid. Again, thanks to the save element a developer may want to have such button even inside an instance that is not wrapped inside a form. Actually, if there is a need for the Save button and a listener for "save" event used, it's even more probable that CKEditor is not a part of a form element.

What we should do is:

  1. Keep the Save button always enabled.
  2. If parent <form> element is detected, submit the form.
  3. Always fire the save event when Save button is used: (i) to make it possible to save data through ajax and (ii) to prevent from submitting the form if the developer doesn't want it.

Warning: (1) is tricky as it will enable Save button for any existing instances. On the other side we can simply warn about this in changelog and blog just like we did with ACF.

Change History (9)

comment:1 Changed 10 years ago by Wiktor Walc

Description: modified (diff)

comment:2 Changed 10 years ago by Piotrek Koszuliński

Or needs to be dropped.

comment:3 Changed 10 years ago by Jakub Ś

Status: newconfirmed

I think @wwalc is right. Currently we have HTML4 button but with this approach we can give users freedom of choice and ability to implement save behaviour in AJAX way.

Such change plus Docs explaining how to make custom save and prevent default form submit (if it is available) should be really cool feature.

comment:4 Changed 10 years ago by Alfonso Martínez de Lizarrondo

This is what I had to do to be able to use CKEditor 4: http://ckeditor.com/addon/allowsave

comment:5 Changed 10 years ago by Jakub Ś

We really need to check addons from time to time, especially your plugins Alfonso:)

comment:6 Changed 10 years ago by Piotrek Koszuliński

I didn't have time to explain why I think that this button should be dropped in CKEditor, but @alfonsoml's plugin is one of the reasons.

We are struggling with too many features that need to be maintained. Many times we choose to work on core, or most complex features, leaving these fairly simple features like save for years. I don't even know what it does now and I'm not very interested to be honest.

In my opinion, core team should work on core and most important features and provide necessary architecture and documentation for others, so they are able to write new plugins and properly integrate CKEditor into their systems. Take save button for instance - everyone except it to work differently, because it is affected by case in which editor is used. Whether form binding is used, AJAX save, multiple editors that should be save at once, etc. Now, we can spend a week designing this feature in a way that it will be useful in at least 90% of use cases, but such general solution will be unnecessarily complex and we'll never satisfy everyone.

It would be much better for everyone if we spent that week making docs or fixing bugs in core. Additionally, we may have a savebutton plugin which does exactly one thing - adds save button and command which do nothing. It's developer's decision how to use them, when to enable, etc.

comment:7 Changed 10 years ago by Jakub Ś

In my opinion, core team should work on core and most important features and provide necessary architecture and documentation for others, so they are able to write new plugins

I can't agree with that. Save is one of most basic features WYSIWYG editor should provide. In this case we don't have to provide super complex solution but at least basic submit plus handle that will allow user to do whatever he wants. I believe this is what @wwalc meant and IMHO such approach will cover 100% cases.

comment:8 in reply to:  7 Changed 10 years ago by Piotrek Koszuliński

Replying to j.swiderski:

In my opinion, core team should work on core and most important features and provide necessary architecture and documentation for others, so they are able to write new plugins

I can't agree with that. Save is one of most basic features WYSIWYG editor should provide. In this case we don't have to provide super complex solution but at least basic submit plus handle that will allow user to do whatever he wants. I believe this is what @wwalc meant and IMHO such approach will cover 100% cases.

I can't agree with that. It correctly applies to standalone app, but CKEditor is a component. Saving is always handled by the system and there are dozens of ways to do that. Additionally, save button was commonly implemented in standalone desktop editors, but the web is different - in most use cases save button should not even be used, because CKEditor is a part of form which has its own submit button. And AFAICS save button loses importance in desktop editors too.

comment:9 Changed 10 years ago by Wiktor Walc

My goal was to make this button usable in 4.x (where we can't just drop features), with a minimal effort. The suggested improvements are pretty easy to implement, besides it makes a bad impression where we have a feature that seems to be broken.

For 5.x I believe what Reinmar wrote makes sense. There are certain types of plugins which fit better tutorials or a cookbook (see here how it could look like: The Symfony Cookbook).

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy