I am using CKEditor 4.1RC. I'm now using the editor in inline mode instead of the replace mode that was in previous versions.
I have a plugin that adds html elements to the body and then calls updateElement to save the changes. The updateElement call only works for the replace mode. How do I add elements while in inline mode and have it take affect so that if I click on the source button the changes are there AND if I destroy the editors the html elements will remain?
Code Example:
var body = editor.document.getBody();
body.appendHtml("<myelement />';
editor.updateElement()
Starting from 4.1 you need to
Starting from 4.1 you need to integrate your plugin with the Advanced Content Filter. We haven't yet updated guides with the chapter explaining how to do this, but you can check its source version, which is mainly ready.
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+
And note that to make this
And note that to make this code working on IEs you need to run one of HTML5 shim libraries. I gues that this is the most popular one. It will enable non standard HTML elements which IE may reject in some cases.
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+
figured it out
I used jquery to update the original div instead
$(editor.element.$).append("<myelement />");
I don't used the advanced
I don't used the advanced content filter. I allow my users to input whatever they want.
A friendly suggestion for future releases would be to disable new features by default. When I upgraded, my stuff stopped working because I relied on attributes set ('data-attribute') on elements to identify them. This was being stripped out by the advanced content filter. If it were disabled by default this part of your new release would have been backwards compatible.
This doesn't seem to work on
This doesn't seem to work on image elements for some reason.
Once my dialog is open the following is not writing the attribute. If I do it on the onShow event it writes correctly but if I set the attribute on the onHide it doesn't keep it.
element.setAttribute("data-attribute", true)
If you plugin is not
If you plugin is not compatible with ACF, then it should call editor.filter.disable() to disable ACF. Otherwise there will be conflict.
Then these features would not make sense. We believe that ACF is extremely important part of editor, therefore it is included in core and therefore it is enabled by default. Of course - plugins have to be updated (your can be to - you can easily allow data-* attributes on all elements), but this is normal situation. Every platform (OSes, browsers, other libs) need to change and we cannot be always stopped by some old stuff. Of course, we do care about backward compatibility and do not change API every day ;). It's all about moderation.
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+
They would make sense for
They would make sense for people that intend on using them. Then they would have to do the research on how to implement these new features and in turn educate themselves. Instead, by forcing everyone to just deal with your update and patch things to conform, you introduce frustration and confusion.
I understand that you don't do this every day but just about every release you add something that isn't backwards compatible.
With ACF as an example, you could have disabled it by default and then whomever cared about content filtering could enter that realm while users already using your editor could keep their code the same. The main thing here is that the user has an option instead of saying everyone must update.
Based on your documentation I call CKEDITOR.config.allowedContent = true; to diable ACF for all editors
What are we? Users or Developers?
Hi jnoreiga,
I presume that implementing an application is not for the mere mortals but for people who know what they are doing (e.q. programmers, developers of webbased software and the like). ACF is already prominantly mentioned and my guess is that by the time CKEDITOR 4.1 is released it will be the first line (and link to the guide) we will read (plus the CKEDITOR.config.allowedContent = true; option) .
IMHO ACF is a giant leap foreward and after a while we play with it as we see fit.
Also the 4.1 RC is clearly out there to learn about ACF. I have also seen some problems but by reporting them to the dev team (and talk about it here) it is taken into account and solved or cleared. I'm very pleased with that and it all is giving me the feeling that this great product is becoming even more excellent!
We develop for users, not ourselves
I agree that implementing an application is for people that know what they are doing.
I also like the new addition and I think it's very powerful.
My point is backward compatibility should be preserved whenever possible. ACF for example could have been disabled by default giving the developers the option to turn it on when they see fit.
Instead, when 4.1 is released, if anyone is using custom tags or attributes (especially data- attributes that are valid), they will be stripped out and the user will have to look further into ACF.
Remember, We develop for users, not ourselves
You are in control
I, as a programmer/developer, have already code into place that wil turn ACF on whenever the implemention of CKEditor with ACF is ready for it! Luckely it is an option that can be turned off!
That's is part of the joy and what makes us tick... programming and anticipating things to come :-)
Bigger picture
You are thinking about your application.
I am talking about backward compatibility that will be benificial to everyone by flipping a default bit. A very simple thing.
This is my opinion which doesn't affect this project at all, but just automatically stripping things with a new release is far from ideal. Not everyone has your extensive knowledge and foresight as a programmer/developer.
I am talking about backward
Again - switching ACF off by default would kill this feature. Plugins developers wouldn't care about integration with ACF, great majority of developers would never learn about ACF and even if they would learn, incompatible plugins would ruin overall experience. At some point we would have to switch ACF on by default and... the same would happen - some developers would be disappointed because of lacking backward compat. What's more - it could be even more surprising that ACF is switched on if we delayed this.
As the core developer I'm trying to follow all important topics on this forum and Stack Overflow. I've seen tens of questions about better clean up of pasted content and how a developer can restrict allowed content, because none of us like when user ruin our carefully cut layouts. Unfortunately we know that for many developers it is hard to find information about feature which existence they are not aware.
On the other hand, developers updating CKEditor to 4.1 will find out very quickly that something is wrong (if of course something will be). It will be easier for them to check latest release notes, latest topics on forum and SO. We'll be there, waiting :). No one should ever update CKEditor automatically (without checking the result) to the next major version (yes, this is a major version - please remember about that!). I bet you wouldn't do that with PHP, Apache, or whatever else you're using.
In the worst possible case, if integration with ACF isn't possible, you can always switch it off and voila! You can ignore it forever. In fact, we're aware that ACF may not have all features required for integration with some special cases. E.g. at some point we had to remove already implemented support for regexp based attributes validation and now it is not easy to add one rule for all data-* attributes on all valid elements. So if you need something we didn't implement, report us a feature request and if it is reasonable and possible, we'll add it ASAP. But for now, we'll advice you to disable ACF.
Anyway, my point is that we chose solution we consider being less evil. It requires some attention from developers, but less from you, than from us. And after short stormy period the world will be a better place ;).
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+
Ok
I respect your choice. Just sharing my opinion :)