Can you please explain how this works, since I am confused?

I understood that information entered into a text field was written directly to the database, and then passed through the Input Filter when the page was subsequently viewed.

However, I have finally worked out that when using Wysiwyg plus an editor, the Filter settings change what is written to the database when the page is saved. In fact it happens before the page is saved, since if I examine the HTML using the editor's "Source Code" button the style attributes concerned (in this case attributes on the table tag) have disappeared; even though they are being displayed on the screen at the time.

I believe that this occurs in the Wysiwyg module, since I get the same effect with two different editors.

Can you confirm that my understanding is now correct, or give a reference to a more detailed explanation?

With thanks,
Tony Maynard-Smith.

Comments

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

Fillter/Format settings never affect what is saved to the database, and there's nothing Wysiwyg can do to change that either. Filters are only ever applied during rendering - after content has been fetched from the database.

Almost all changes to the source code before the form is saved are made by the editor itself, even if it just gets loaded and is immediately turned off. This is because most editors apply their own filters and parsing routines both when reading existing content and generating the final markup based on the DOM in their editing area. Usually, the same code generating the final output runs when you enter an editor's "Source" mode, to give an accurate representation of what the final markup will look like. Then the editor [re-]applies its own input filters and parsing rules when you switch back to WYSIWYG mode. Otherwise the editor could crash or cause other problems if invalid or malicious content was input by the user.

If you click "Disable rich text", the editor is forced to produce the final markup and shut down, just as it does when the form is submitted. What you then see in the original textarea is exactly what will be submitted to the database, and fetched from there again before any of Drupal's filters have been applied during rendering.

In the case of TinyMCE, it requires that plugins define which tags and attributes they intend to produce so they can be white-listed for output by the editor. I don't remember the exact rules used - they can be found on the TinyMCE wiki under the valid_elements setting - but they might not allow style attributes on the tags you've had them on. And unless a plugin intends to use style attributes on some/all tags and adds them to the extended_valid_elements setting, TinyMCE will skip them.
As far as I know, other editors aren't as strict and any markup produced by their plugins will pretty much be left alone. If the editor

Wysiwyg module itself does not apply any filters to the content during editing - but it may pass the content through plugins provided by other modules - and runs no code whatsoever during Drupal's content rendering process.

I can't say exactly why the styles you used on the table tag were removed without seeing the original and altered markup and which editor settings were used.

Anonymous’s picture

Anonymous (not verified) commented

Thank you for your reply, though it still leaves me rather confused.

After I made the last post, I made some changes to the configuration of the WYSIWYG_Filter which was part of the active input format, and the effect of pressing the Source button in the editor changed. Specifically I added rules to permit the table attributes I was having trouble with, and they then appeared, and functioned correctly thereafter.

Something somewhere would seem to be linking the editor to the filter.

No great worry. I have worked out how to get the result I want, even if it is a bit mysterious as to how it does it.

Thanks, Tony

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Component: Documentation » Miscellaneous
Status: Active » Fixed

That does sound strange, considering the WYSIWYG Filter module does all its processing on the server and Wysiwyg/TinyMCE does all its processing in the browser during actual editing, and there's no communication between them.

Glad to hear it worked out though!
If you are able to reproduce this behavior later, I'd be very interested in hearing if changing WYSIWYG Filter settings still triggers it.

Anonymous’s picture

Anonymous (not verified) commented

OK, sorted.

Reading the help text more carefully, what the WYSIWYG Filter actually does is edit the TinyMCE configuration file, so the processing all happens client side as you describe.

(I have not gone back and checked what it does if TinyMCE is not installed or configured for that particular Input Format.)

Tony

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

Well I'll be... I didn't know it actually did interact with Wysiwyg/TinyMCE, but while studying the code again I did notice they use
hook_wysiwyg_editor_settings_alter() to overwrite TinyMCE's valid_elements setting.
If TinyMCE isn't used for a format, it does nothing on the client and only applies filtering on the server.

IMO, since they change valid_elements they should also empty the extended_valid_elements setting or that will [partially] override whatever WYSIWYG_Filter tries to do.

Sorry for doubting your observations, they were indeed correct and I should have looked at the code again. Turns out the hook_wysiwyg_editor_settings_alter() implementation was added over a year ago but I completely missed it...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.