How to integrate with CKEditor?

Jan 20, 2012 at 12:39 PM

Hi, great module! (Something I wanted to have for a while but never got around to)

You mentioned how this won't work with WYSIWYG editors. I'm wondering what I'd need to change in the CKEditor module to make it compatible with this feature. Would it be enough to, at regular intervals, populate the hidden field that actually posts the data behind the scenes?

My second thought:

Since you have a script that detects changes, this could actually be turned into an auto-save, for Draftable content at least. All you have to do is harvest the form data and do an AJAX post with jQuery as though the Save button had been clicked. Thoughts?

Jan 20, 2012 at 2:56 PM


A hidden field would indeed work and it would be awesome, but the real solution would be to write adapters for the different WYSYWYG editors (currently for TinyMCE and CKEditor would be sufficient). I thought about this but in the end do not got to implement it.

Well, such autosave could be neat, what's actually needed is submitting the form with jQuery, then also WYSYWYG editor fields should be properly populated. Also the part should give the information for the script whether to autosave or not (depending on whether the content type is or isn't draftable). I don't know of any mines here, so this should be pretty straightforward.

I might work on these two ideas in the future (now, among others, I'd like to release a new version of Combinator soon).

Jan 20, 2012 at 3:03 PM
Edited Jan 20, 2012 at 3:04 PM

If I modified CKEditor to store in the hidden field after every few keystrokes (there may well be an option or plugin already to do this), then that would solve both cases, without having to actually target the WYSIWYG editors from your side. Probably much easier. Same can be done for TinyMCE.

The autosave option can just be a simple setting, doesn't have to be a part. Using settings hooks, you can add new settings UI to all content types - this is how e.g. the Indexable setting works, without needing a specific part. It's much easier to implement than a part and doesn't require the administrator to manually add the part to all content types, which could be a chore if you have a whole load.

Jan 23, 2012 at 10:23 AM

It would be sure easier for me (and possibly altogether as detecting what a WYSIWYG editor is used is not trivial) and I'd be very thankful. But I guess modifying the TinyMCE module is not really an option.

Actually this module is a part now, but would indeed be better as a type setting. Doesn't Sebastian mentioned somewhere that how settings are registered will change with 1.4?

Jan 23, 2012 at 11:21 AM

Nothing is changing from a configuration perspective; it's all behind the scenes, which classes perform the mapping to and from XML when the settings are stored/retrieved in the database. The mechanism for modules and migrations to update and retrieve settings remains identical.

TinyMCE can probably be modified with an override somewhere, or could submit a patch to core.

Jan 27, 2012 at 12:16 PM

Ah thanks. I'll go on with modifying the parts of Facebook Suite too (same story, and it really bothers mee).

I'll think a bit about what would be the best.

Jan 27, 2012 at 5:04 PM

I've just got over the 1.3/1.4 compatibility hurdle by using a different method to serialize the settings :)

I've been writing a small library called Putty that's a set of Clay behaviors that will serialize to and from both JSON and XML (JSON is working really well, XML not so yet).

Because it's dynamic it lets you do this:


dynamic putty = new Putty();
putty.One.Two.Three = "Four";
var json = putty.Json();
==> {"One":{"Two":{"Three":"Four"}}}

So it's really handy for getting settings in and out of dictionaries, there are a load more things it can do as well. I'm just converting to that instead, existing code even still works because it still accepts dictionary syntax.