wymeditor fails when javascript is served from a different domain

[chris_v]

Currently, WYM editor only works when its javascript files are served from the same domain as the page embedding the <textarea>. However, especially in high-traffic setups and/or to achieve faster page loading, it may be desirable to serve media files from a different server (e.g. page is located at http://mysite.com, and media files reside on http://media.mysite.com).

Unfortunately this is not possible with WYMeditor due to the ajax call in jquery.wymeditor.js, Line 1138 (Wymeditor.prototype.load):

if(typeof XhtmlSaxListener != 'function'){

// This is the only way to get loaded functions in the global scope until jQuery.globalEval works in safari

eval(jQuery.ajax({url:this._options.basePath

+ this._options.xhtmlParser, async:false}).responseText);

In the setup described above, this._options.basePath will be something like 'http://media.mysite.com/...'. Since the Javascript security model assumes the calling script (jquery.wymeditor.js) to be part of "mysite.com" (because it is embedded in a page served from mysite.com), the ajax call will fail.

(Note: the same applies to the ajax call some lines below; Wymeditor.prototype.configureEditorUsingRawCss() ).

This problem could be avoided if -instead of loading static code through ajax calls- other options for loading scripts dynamically would be employed (like dynamically inserting script tags). One would still have to apply domain relaxiation to the iframe's html (wymiframe.html), but at least this would be possible then.

[jf.hovinne]

The XHTML and CSS parsers are now embedded in the main JS file. The issue still occur when you use the language option, so my proposal ( see r474 ), is to embed the language file (like before) in the document's head ( see noajax.html ).

Unfortunately, you'll need to init the WYMeditor namespace before loading the language file, as I don't know any reliable cross-browser synchronous global eval, so we can test the existence of the WYMeditor namespace in the language file ( any idea? ).

[jf.hovinne]

No feedback from the reporter, issue fixed, and taken into account (avoid AJAX calls or provide an alternative when possible).

[sazwqa]

I am currently facing the same issue and the instructions provided does not seem to be working. I am using the latest version of WYMeditor (0.5-rc1).

Am initializing the WYM editor using the following:

<link rel="stylesheet" type="text/css" media="screen" href="/wymeditor/wymeditor/skins/default/skin.css" />

<script type="text/javascript" src="/wymeditor/jquery/jquery.js"></script>

<script type="text/javascript"> var WYMeditor = {}; WYMeditor.STRINGS = []; WYMeditor.SKINS = []; </script>

<script type="text/javascript" src="/wymeditor/wymeditor/lang/en.js"></script>

<script type="text/javascript" src="/wymeditor/wymeditor/jquery.wymeditor.js"></script>

<script type="text/javascript">

jQuery(function() {

jQuery('.wymeditor').wymeditor({

classesItems: [

{'name': 'date', 'title': 'PARA: Date', 'expr': 'p'}, {'name': 'hidden-note', 'title': 'PARA: Hidden note', 'expr': 'p[@class!="important"]'}

],

editorStyles: [

{'name': '.hidden-note', 'css': 'color: #999; border: 2px solid #ccc;'}, {'name': '.date', 'css': 'background-color: pink;'}

]

});

});

</script>

Let me know if this is the correct way of doing this or am I missing something ? Just to notify the CS and JSS are served from a static cookie less media server for performance.

[mr_lundis]

I tried to serve WYMeditor from a different domain earlier today, without luck. It's when WYMeditor tries to access the iframe document from the outer page things break.

The question is if it's possible to work around this or if the browser policies makes this impossible.

[mr_lundis]

The removal of the iframe in 0.6 will most likely fix this. Until then there's a workaround for this issue posted in the forum:

http://forum.wymeditor.org/forum/viewtopic.php?f=2&t=731&p=2507#p2504