It would be very helpful if the text format influenced the visible buttons on the WYWIWYG editor. E.g. if the <strong> element is not allowed by the text format, the [B] (bold) button would not be visible, or would be greyed out.

This would add a level of cohesion between the projects.

Comments

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

That's really difficult to do. The topic has been discussed and argued back and forth in several issues already.
To summarize, the problem is knowing what each text format setting does, and how that relates to each editor setting, including any plugins (cross-editor plugins and native editor plugins).

We'd need the ability to programmatically list which markup tags, attributes and values are allowed by a format, as well as the ability to programatically work out which settings need to be tweaked to get the same effect in the output produced by an editor.
Something like a Format/Filter <-> DTD <-> Editor/Setting map. Then there's the possibility that one of the filters transforms BBCode to HTML, so the editor would need to have a BBCode plugin enabled, but also disable the table plugin because it can only produce HTML...

Without that, we'll have to resort to semi-automated solutions, like allowing modules implementing filters to say which editor settings or plugins should be used. We kind of have that with our hook_wysiwyg_plugin() and hook_wysiwyg_editor_settings_alter(). The first one allows you to describe native editor plugins to Wysiwyg, and the second allows modules to override native editor settings. But neither of those will do exactly the thing you want without a lot of code and difficult work. To get it closer to the goal we'd need to build the settings mappings manually into the module, and keep them up to date as editors change...

The administrator is still the best judge in the matter for now.

brylie’s picture

brylie commented

That makes sense. To clarify, the components would be something like:

  1. Text format index (lists allowed tags and attributes)
  2. Editor settings map
  3. Markup transliteration

Does that seem like a rough sketch of the major components? I.e. abstracting the system into significant components.

It may be useful create, and focus primarily on, #1 (the text format list) as an API. Then, project maintainers such as CKedit can choose whether or not to implement functionality based on the API, and continue to manage markup transliteration.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

Yeah, that sounds like the basics, but it quickly gets complicated. :/

I don't know where to start looking at designing #1, there are so many filters out there I've not even heard of yet, and this needs to be generic enough to expose exactly what a filter will remove (if it's disallowing tags) and how it relates to any editor plugins which would need to be enabled to insert placeholders or other markers recognized by the filter in WYSIWYG mode.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Issue summary: View changes

Fixed HTML.