I've been using Froala WYSIWYG Editor for the last few months on a production site where is used daily and works great, is modern, and most importantly works on mobile devices. I wrote a lightweight module to provide support for this editor on this site and would like to contribute my work to add support via your WYSIWYG Module.

I tried to search your documentation for basics/examples for adding a new editor, but didn't find anything (sorry if I missed it). Is there a quick example for basic integration I could follow? Perhaps you can take a browse at the code (not much) and let me know how we can proceed?

Comments

in0ni created an issue. See original summary.

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD as a volunteer commented
Category: Task » Feature request
Status: Needs review » Active

I'm afraid I don't have time to look deep into this editor right now, but I can give some quick pointers.

The only "examples" are the existing editor implementations themselves, notes about the hooks in the file wysiwyg.api.php and the clientside code in wysiwyg.api.js (currently only includes examples for cross-editor plugins).

A third party module wanting to integrate an editor via Wysiwyg's API first implements hook_wysiwyg_include_directory($type) needs to return a folder name (relative to the module's own root folder) when $type is "editors". (Wysiwyg already does this step for those supported by Wysiwyg itself.)

Next step is to create a file EDITORNAME.inc in that folder, which contains at least a function named MODULENAME_EDITORNAME_include() that returns the actual "editor definition", mostly a bunch of names of callback functions for finding out more information about the editor library. At the very least it needs a version callback and the name of a file to load from the editor library, so Wysiwyg can determine if the library is installed and what version it is.

Lastly, Wysiwyg needs to be told which JavaScript file to add to the document when the editor is going to be used, the "clientside integration". This is where most of the work is actually done to initialize the editor library, load required plugins, apply settings, attach an editor instance to fields, detach (just send data back to the original textarea on 'serialize', or destroy the instance completely on 'destroy'), etc.

If you want to, you can try to make the editor integration support cross-editor "Drupal" plugins. However, that part of the API is a bit difficult to work with and fairly limited in what it can actually do now (plugins can basically pre-process or post-process raw content or insert something into the editor when a button is activated). I recommend you leave that to last though and ignore any hooks or callbacks mentioning "drupal plugins" for now. ;)

Detailing exactly how this works for each editor would take a long time so I'm not going to do that right now. It's probably easier to simply dig into the CKEditor or TinyMCE implementations and see what they do when instead. If you don't understand how or why, just ask and I'll do my best to explain it.

I'm in the process of redesigning Wysiwyg's internals (for instance, see the latest patch in #2243413: Error when adding field items - Add another item), but it doesn't alter much about the way Wysiwyg's core communicates as seen from the perspective of an editor or a plugin. (Another WIP patch does add more callbacks for dealing with existing editor profiles when up-/downgrading editor libraries, but that's all optional.)

Again, if you want to know how/why, ask and I'll do my best to answer when I can.
Judging just by the quick look I had at your clientside code it's not that different compared to Wysiwyg. Wysiwyg has some baggage from starting out with just TinyMCE support so some things may look odd, but the basics are not that different.

in0ni’s picture

in0ni CreditAttribution: in0ni commented

great, thanks for the detailed response. also running low on time here, but will definitely look into creating an addition with the information you provided and existing editors. i'm wrapping up a few things on the existing module, once that settles i'll take a stab at it.

thanks again.

iqbalpk’s picture

iqbalpk CreditAttribution: iqbalpk commented

@in0ni . . what is the current status of your module ? can it be uses

in0ni’s picture

in0ni CreditAttribution: in0ni commented

iqbalcoeus -- it's currently a sandbox project and is awaiting approval to a full module, which will be hopefully soon. the module has been in use in a production site for the last 6 months -- using v1 of froala editor. i recently upgraded the module to only work with v2 of the editor since it will be released this month (i've also updated it on the production site, works without issues). keep in mind that v2 of froala is RC (again, i am using it without problems so far). once the module is approved, i will take a look at contributing the work to this module as well.

that being said froala is an amazing modern editor, which is why i've taken the time to write a module for it. i suggest downloading my code from git (see sandbox page) and giving it a try yourself (take a look at README for full instructions). let me know how it works out for you!

iqbalpk’s picture

iqbalpk CreditAttribution: iqbalpk as a volunteer commented

@in0ni.... thanks for your kind suggestions

iqbalpk’s picture

iqbalpk CreditAttribution: iqbalpk as a volunteer commented

Any update on it..

in0ni’s picture

in0ni CreditAttribution: in0ni commented

@iqbalk

no updates... again... you can try the sandbox module which is currently being used in production site -- as previously stated. that being said, there will be no further development on this module as i am switching platforms... "the times they are a-changing..."