Allow user to dynamically change in-editor theme

subscribe

Subscribe.

This strikes me as a little difficult to achieve without some probably fairly significant changes to the wysiwyg module. Maybe it wouldn't be so bad though.

Certainly what would need to happen is that when the value in the dropdown changes, an AJAX request would be sent to the server, which would then need to initialize the appropriate theme, which, unless we duplicate the code in the drupal_theme_initialize() function would probably require overriding the value of the global theme variable, then proceeding with the rest of the processing in wysiwyg's current wysiwyg_get_css() function.

The new stylesheets would have to be returned in the response to that AJAX request, and then all the existing stylesheets in the editor iframe removed, and replaced with the newly fetched ones.

The question would be whether or not all browsers would respect the new stylesheets. My guess is no, in which case the ajax response would have to actually cause the entire iframe to reload with the appropriate stylesheets in place, in that case this would basically work like AJAX form elements built with the form API.

I can see this probably being a useful feature, but it seems to me the bigger issue is being able to specify the default theme that should be used in the first place. Currently you can tell it to use 'theme css' but that will always be the theme that's configured for content editing, which more often than not is probably the admin theme. That's not very helpful if you want to get an idea what it's going to look like on the front end.

That's a problem I've tried to address here: #1309040: Select which theme's CSS to use when choosing 'Use theme CSS' in settings
I think it still needs some work. Currently it will support a base theme or a sub-theme that's a direct subtheme of a base theme, but not a sub theme of a sub theme. Well, to be more specific, it would work it just won't necessarily load all of the appropriate css.

I suspect what I said earlier about overriding the global theme variable would be a better solution that what I've currently got in the patches in that issue, but I haven't had a chance to test that theory yet.

The other issue at play here on this, and all issues relating to this; not all of the supported editors support custom css in the same way that ckeditor and the like do. At least that's my understanding having looked through the includes for all of those editors, only a handful of them make calls to the wysiwyg_get_css() function.

The easiest way to get the iframe based editors to use the new stylesheets is to "simply" detach and re-attach them so they recreate the iframe etc from scratch. Then they'd also take care of parsing the new stylesheets if some plugin wants to look for classnames etc. We might need #356480: Lazy-load editors and/or #1155678: Implement Drupal.behaviors.attachWysiwyg.detach to make that process smoother.

It looks like the editors which are not based on the iframe approach either don't support stylesheets at all, or only include a stylesheet in their preview mode (popup). There's not much we can do about those editors other than skipping this feature, introducing stylesheets from one or more themes into another is not something I'd like to deal with.

Last time I checked, jWYSIWYG, nicEdit, markItUp and Whizzywig did not support in-editor stylesheets at all. WYMeditor fetches a single stylesheet but I think it injects it into the current document rather than a separate iframe. OpenWYSIWYG does not load stylesheets on its own, but uses an iframe, so Wysiwyg injects tags for them "manually" each time the editor is attached.

If we get #1309040: Select which theme's CSS to use when choosing 'Use theme CSS' in settings in first we'll most likely have a way to fetch the correct stylesheets and the basics for using the theme selected there as the default for the switcher in the mockup, like willvincent said.

Thoughts?