CK Editor - Support for Quote Module and other input formats.

To make the editors aware that they should not interpret the BBCode-like [quote] tags as regular HTML one could write plugins for them.
The plugin needs to do some text processing to find the starting [quote=author] tag, the ending tag and keep track of the contents between them (as well as any nesting of the tags) so that they can be replaced by a <div> styled in a proper way (a placeholder of sorts). The plugin would also have to be able to do the reverse for when contents are retrieved from the editor and posted to Drupal.

You could write an editor independent "Drupal plugin", which is written specifically for use with Wysiwyg module's API, like the included Teaser Break plugin, and it'll work with any editor for which Wysiwyg has full support. Or you could write a native plugin for the editor you are using (ie a 'normal' editor plugin which you create as if Drupal didn't exist). Wysiwyg module can then tell the editor where to load it from. How to get started with Drupal plugins and the hooks needed to tell Wysiwyg modules about plugins can be found in the .api.php files in the -dev versions. If you decide to build a native plugin for more power over a certain editor, please refer to the documentation of that editor as well.

BUEditor module supports a single editor, Wysiwyg module can theoretically support any editor, we can't have a common GUI as not all editors are alike. Even with BUEditor's GUI you'd still have to write a plugin for it to make it do something more than just show the [qute=xxx][/quote] tags as they are, which Wysiwyg currently does as well. The input filter on the server is able to find and transform it to a quote block in both cases once saved.

The GUI we have is left over from when only TinyMCE was supported so it's not at all what we really want, but it has had to be enough while the module gets stable enough. Wysiwyg 3.0 will have a much improved UI and overall API, sun posted some things we discussed on http://groups.drupal.org/node/25112, but there has been no interest in participating so far. So believe us, we're trying but we also have other responsibilities. Sun is putting a lot of work into Drupal 7 and my top priority is getting a new job.

Considering what year it is, there should have been world peace long ago as well. ;)

Merry Christmas!

How is WYSIWYG supposed to know about your custom input formats without you telling it about them?

But isn't that the whole point of this module? Otherwise wouldn't that indicate that this module has a failed concept and that per editor modules are better after all.

No. It means that Wysiwyg module provides an application, communication, and interaction programming interface and abstraction layer between arbitrary editors and arbitrary Drupal modules.

If Quote module wants to support editors, then it can support any editor by implementing support for Wysiwyg. And not by implementing support for countless of other editor-specific modules, having to understand all kind of different APIs as well as having to update its integration code for every new release of any of those editors and editor integration modules.

That is the goal and paradigm change, which Wysiwyg module introduces.

(Sorry if this becomes a bit of a rant, my girlfriend passed around a bottle of Absinth not too long ago. ;)

What I meant was that developing a complete 'editor settings GUI' for Wysiwyg module is a more complicated process than doing it for a single editor, which is part of why it has taken time. That and the fact that we are only two people (I joined not so long ago) working on this in our spare time so the good old "it's done when it's done" applies. We need to redesign the editor profile page to use one or more callbacks in the individual editor implementations so they can extend the GUI to suit their editor's options, and the enabled plugins should in turn be able to do the same. Currently, some of the options we have are not supported by all editors, due to different designs, and we'd hate to add to that confusion by putting even more in there which only works for a single editor. To get this right from the start, and not have to start over again for each new supported editor, we need to look at as many editors as possible and find their common elements and what kind of requirements the 'basic settings framework' needs to fulfill. Some of this is discussed in #313497: Allow configuration of advanced editor settings, tho not much has happened there for a while, it's top priority for 3.0.

The options currently in the profile GUI (originally mapped to TinyMCE) have so far been enough to support the basic features needed to get the most popular editors up and running. They're in a state where someone with knowledge of how the module works can basically have them tapdance if they'd like to. Now that we know what's actually possible to do with this module, we can look at how we let our users do the same thing without having to jump through hoops.

Adding completely new functionality will however always require a coder putting it in there. If something is added to Drupal (basically a new module) which Wysiwyg module itself has no knowledge about, the same coder, or anyone else, only need to spend a little bit more time implementing a plugin so the editor knows about it too. Isn't that better than learning how each editor works internally and create a new fork of it, or a native plugin, just to support what was added to Drupal? With separate editor modules, you'd need to do that. When Wysiwyg module is as good as we'd want it, you'd write a single plugin which works in all supported editors (and new editors when they're added) and head off to the next project.

Was that status change intentional or just a browser reload hickup?

@Sun, The status change was not intentional, took me quite some time to type that and you got in before me (saying what I tried to say in much less words).

WYSIWYG should already know what custom inputs there are by what is enabled on the selected input format.

Figuring out which input filters are enabled on an input format is not hard, figuring out what they do based on their name alone, and what the editor has to do to work with it, is impossible..

We have no chance to keep up with all the new filters being created, nor give the Wysiwyg module the ability to look it up on its own, so we provide a way for anyone who needs to integrate the functionality of a filter with the editor to do so on their own. The integration (most likely in the form of a Drupal plugin) can then be shared with others by being integrated into the module providing the filter itself, or perhaps via a 'bridging module' which is what IMCE Wysiwyg brigde does for IMCE. The former solution is of course the best one as no additional module needs to be downloaded and the maintainers responsible for the filter module can keep the plugin and filter changes in perfect sync.

@ManyNancy - quote module works well for me with wysiwyg, bbcode and tinymce 3.0 with the "bbcode" plugin enabled for tinymce in its profile.

the bbcode module includes an input filter you have to enable as well.

you also have to define a style for span.quoteStyle which is what tinymce will interpret the [quote] tags as in editor mode when both the bbcode module and bbcode plugins are enabled...

is there something about that solution that is not working?

This doesn't make any sense to me. Rather than figure it out by the name, why not figure it out by the code that's inside the input filter?

Wysiwyg module has no way to understand the code in input filter, even if it could get it. Only a human knows what a filter really does and how it affects the content.

This sounds so obvious to me... but I guess this is a feature request. Why is WYSIWYG not integrated with the core drupal input filter api? There should be a converter that automatically takes the input filter and changes it to whatever the editor requires.

Yes, we could make Wysiwyg module ask which filters are enabled for a given format using filter_list_format, but the only useful information we'd get would be their [translated] names/descriptions, which module implements them, their internal id/delta and in which order they're supposed to run.
There's nothing which could be used by an automated converter to figure out what to do on its own unless it's some kind of Artificial Intelligence.

To get perfect automated synchronization of the input format with the editor profile (from a user's point of view), we'd have to build a lookup table consisting of every known input filter by every module out there and create a custom set of rules for each editor to match the enabled filters with its available settings and/or plugins. Each input filter and editor setting/plugin would have to be carefully analyzed to find the best matches and avoid allowing incompatible settings. That task alone would be a full-time job.

Besides, automatically changing the format/filters to meet the requirements of the clientside editor is a horrible thing from a security perspective. The server is in charge of security, any synchronization should always go the other way so editor profiles are changed to match what the server expects.

As I've stated earlier; What we can do is to add some type of validation to the enabled buttons and settings when the editor profile is saved. And in that we try to compare what's been selected with what we know the Core filters do. We also allow this validation to be extended by the plugin hooks. If something seems odd, we can alert the user, but we can't completely deny the user from choosing whatever they want. We can't anticipate every situation where a choice, which seems wrong at the moment, will be made valid by some functionality brought by a new module or plugin.
I'm hoping we get some of this basic validation in with Wysiwyg 3.x, the current code does not allow for it.

The problem is that you have to manually write a processor for each filter and button in code because there's no UI to allow you to do it. So for me, something like custom filter / BUEditor is so much easier.

With the BUEditor module, you're still manually writing code for each filter, button and each unique editor profile. The difference is that BUEditor's code resides in the database and it can't already be done for you by another module, perhaps one of those providing the filters you need.

@Veggieryan, isn't that solution specific for tinymce?

It should work in similar ways for other editors with a BBCode output plugin. But this is of course assuming that you want all input for that format to be in BBCode.