SVG Editor

That's a pretty sweet tool! =)

It would be nice to have support for it in Wysiwyg module, but it seems to deal only in SVG and does not accept any other markup around it. I tried just adding a div around the SVG contents in "Edit Source" mode but it complained about parsing problems. So sadly, this is a "won't fix" unless someone finds a workaround. It might be possible to get to work if the Wysiwyg implementation searched the contents for SVG tags and only passed those to the editor, but I think that would be very hard to pull off nicely.

I don't think we have an official documentation for editor implementations yet which I can point to, but looking through the wysiwyg/editors folder should give you a pretty good idea how to start. Each editor has an .inc file implementing hook_editor and at least one .js file in wysiwyg/editors/js, which deals with the editors JavaScript API from init (attach) to shutdown (detach).

Hook_editor returns an array describing some basic things about the editor like its name, where the base of its folder structure is, which variants of the library there are along with their JS files (usually one full source file and a minified file are available). One part describes which implementation files (.js and .css) to load for which editor version, so API changes can be compensated for simply by loading a different file rather then having lots of if-elses.

In addition to all this library and implementation info, there are a set of required and optional callbacks editors can define. Editors should always define a version callback function so Wysiwyg module knows both which library version is installed, and which implementation file to load. There should also be a settings callback to translate the profile page's form element ids and their values to some structure which the editor can understand. The array returned by this function is put into Drupal.settings.wysiwyg.editorName.formatN for use by the JavaScript implementation when attaching the editor to a field. There is also a theme callback for letting Wysiwyg know which editor themes are available for selection, but the selection part is not implemented yet, and the callbacks usually just return a static array.

Since Wysiwyg can relay information about two types of plugins to the editor, editor-independent 'Drupal plugins as well as 'native' editor plugins there are some callbacks related to gathering this information as well, but you should not worry about defining those yet, if ever.

The JavaScript file basically creates a new sub-object in the Drupal.wysiwyg.editors object which is required to have an attach() and detach() method. Those methods are called by Wysiwyg module after it has parsed out which editor to load and for which field. The parameters passed to it are those belonging to the current input format, things like if the editor is enabled or not by default, which field it should attach itself to etc. The settings passed there are a clone of those put in Drupal.settings.wysiwyg.editorName.formatN. Note that the settings are safe to modify (say if some value needs to be changed before passing it into the editor init call) but they will go out of scope as soon as attach() returns and a completely new copy of the settings will be sent on the next call. The job of the detach() method is simply to make sure the editor is destroyed, and its contents are synced back to the original textarea before that. The state of the editor should be as close as possible to it never had been attached from the beginning so it could be attached to the same field again without problems. Wysiwyg will attach a fake editor implementation simply called 'none' if no other editor is about to be attached, and it will take care of putting back the resize bar on the original textarea if needed.

I don't have time to write a more detailed explanation at the moment (birthday hehe), but I'll be happy to answer any questions you have.

Hi PeakDevGuy. Did you make any progress on integrating svg-edit with Wysiwyg?