How to write WYSIWYG plugins

Great stuff! Sorry for not following up earlier.

I'll definitely review, fill in the missing pieces, and commit this in the next days.

This will be a valuable asset to developers. Using the notes, I had created my first WYSIWYG plugin in no time.

Could this be extended to briefly include notes on how to handle dialog popups? Namely the init, cancel and close/update API's

Thanks in advance

Alan

Thanks for the notes Roi Danton it's very usefull.

Good stuff. Similar notes on the javascript would be invaluable too.

Would be great if the maintainers could write all these up. Rather than making us all play guessing games. I'm sure you will be able to quickly document everything far faster and easier than any of us. It would great for everyone's benefit :)

You have a point there Starnox. As eager we are to get started on the next major version (which will change how plugins interact with the active editor, this time without even needing to know its name), we really should take some time to document how it all works in its current incarnation.

There's a bit of a dilemma here though. Few editor implementations support plugins yet and part of the reason is that we want to wait for the changes I mentioned above, before writing a bunch of code we'll soon have to rewrite. So, we're looking ahead to see which parts of the current code needs an overhaul to support the features one would expect from a module trying to wrap different editors in the same packaging.

At the same time, the community is getting interested in writing plugins (which is awsome btw!). They'll most likely run into problems because of the current API drawbacks, or end up writing hacks/workarounds which will just complicate somehting that should be easy (from a plugin POV, like inserting content at the caret position) no matter which editor is on the other side of the API. We really don't want people to have to go through that, but is it better to help people understand and work around the 2.x code which has many limitations rather than focusing on the 3.x code and "stall" the eager plugin developers until they have something better to work with?

I'm mainly thinking about "Drupal plugins" here, but much of this also applies to native editor plugins in some way or another.

Time is not merciful when one wishes to do all things... ;)
Sun has been busy lately and now I'm getting my hands full for the next couple of days [or maybe weeks], not to mention I'm looking for a new job. :/

This post got way more elaborate than I had in mind, but before I completely lose focus:
What you have so far seems pretty much accurate, but I see you struggle with the same things I did when first seeing the code. As soon as I have some time over I'll look through the notes here and add some of my own.

I really shouldn't post this late hehe... ;)

TwoD, another benefit of writing documentation is that it frees up a lot of developer time, and some of that time may actually go into benefiting this project.

I put myself forward as an example of this. I like WYMeditor, and using it with Drupal/WYSIWYG has led me to submit a patch to update the WYMeditor integration.

I believe I would have submitted several patches by now if I had access to documentation. Without it, it just takes so long trying to figure out how things work or how they are supposed to work.

"Help me to help you" as the saying goes :-)

+1 for good doc or very simple examples, like a plugin that adds a dialog, a simple form, and inserts code based on the form values. teaser_break is too simple and img_assist is way too complex.

I agree with you on that guix, docmentation is much more useful with good examples. We should of course include the the parts you mention, but in Wysiwyg 2.x there's not really much support for dialogs except for opening them. (Which is why Image Assist currently needs different implementation files for each editor and is a pain to extend IMHO, and I think Sun agrees on that...)
An example of that working with all editors will get very complicated, as not all editors implement the insert() method. I'll try my best to explain that in the docs.

This is of course to be adressed in 3.x, probably with an API method to notify Wysiwyg module that the dialog is done loading and it needs the editor instance.

And Likeless has a good point too. I don't know how long Wysiwyg 2.x will be around, but I guess that since 3.x will probably take some time to get stable, we can't stop improving the editor implementations with what we've got so far. If we at least get insert() implemented in all editors, it would make it much more useful and easier to write good [example] plugins for.

Oh btw, my ISP seems to have "misplaced" my IP etc while we were away the last two weeks... I've only got internet access through my netbook for now, so development has slowed down considerably, but I hear "they've filed an error report and will get back to me within some time". :(

Roi, I must thank you for the documentation you have provided in this thread. It's very helpful. I have to disagree with you on that last point, though. I don't think that having enough material that some people can figure it all out given enough time is any substitute for real documentation. I think it's clear from the comments in this thread that there are a significant number of keen contributors having problems figuring out this API.

TwoD - My take would be that the longer there is to wait for 3.x, the more important 2.x docs are. That said, I think 3.x docs will be far more important.

And "some time" sounds bad. The Mesozoic era was "some time".

I spent some hours tonight to document this.

Thanks for reporting, reviewing, and testing! Committed attached patch to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Looks helpful, thanks sun :)

Also img_assist-6.x-2.x seems outdated and I guess the reference should be img_assist-6.x-3.x ! May be obvious but not for me :)

Some things I noticed that were changed in 3.x
- uses hook_wysiwyg_include_directory() and the plugins directory instead of hook_wysiwyg_plugin()
- in 2.x there was custom code for TinyMCE to register a new popup window, now it's gone, all is in img_assist/img_assist.inc

[edit] I finally get it, I have a lightweight module using a popup wizard in 2 steps with WYSIWYG+TinyMCE. A lot of things are hard-coded and horrible like the wizard is in GET not in POST and Forms API. It allows to select an imagefield attached to the node by clicking the image and insert some code