Quantcast
Channel: XWiki Forum - Latest topics
Viewing all articles
Browse latest Browse all 1220

Load JavaScript skin extensions in standalone WYSIWYG editor by default

$
0
0

Hi everyone,

The WYSIWYG editor has this configuration:

Load JavaScript Skin Extensions
Some rendering macros are displayed using JavaScript code. Loading the JavaScript code improves the WYSIWYG aspect of the editor but it may cause problems if the JavaScript code interferes with the CKEditor code or if it changes content outside of the macro output boundaries.

(see also https://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor+Integration#HExecuteJavaScriptcodeinsidetheeditingarea28XWiki10.102B29 )

It was introduced before we implemented the in-place WYSIWYG edit mode. The big difference between the standalone and in-place WYSIWYG edit modes is:

  • the standalone WYSIWYG edit mode uses an iframe to implement the editable area, so the edited content is isolated from the top page (that has the breadcrumbs, the title, the action buttons, etc.); this means we can control which JavaScript code is loaded
  • for the in-place WYSIWYG edit mode the edited content is not isolated from the top page, so it is affected directly by the CSS and JavaScript code that is already loaded on the page

For this reason, when we implemented the in-place edit mode we ignored the “Load JavaScript Skin Extensions” configuration, because there was already JavaScript code loaded on the page so we couldn’t really protect (isolate) the edited content.

This means that now there is an inconsistency between the standalone and in-place editor when it comes to rendering macros that rely on JavaScript code. Such macros are common, so this difference is more and more visible.

Even if we’re planning to use the in-place edit mode for page creation also, the standalone (iframe-based) edit mode will still be used for some time for TextArea properties, so it makes sense to have a consistent behavior. Thus, I propose to enable the loading of the JavaScript code in the standalone WYSIWYG editor by default

+1 on my side.

We could also remove this configuration option, but I’m worried that some users (e.g. that have disabled the in-place edit mode) will ask how to go back to the previous behavior, and it will be harder for them without this configuration option.

Thanks,
Marius

6 posts - 5 participants

Read full topic


Viewing all articles
Browse latest Browse all 1220

Trending Articles