Ticket #11579 (confirmed Bug)
tiny_mce.js caching causes js load failure on browserviews
Reported by: | sunew | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.x |
Component: | JavaScript | Version: | 4.0 |
Keywords: | tinymce | Cc: | dpc22, afd, fulviocasali |
Description
When using a tinymce based wysiwyg widget (plone.app.form.widgets.wysiwygwidget.WYSIWYGWidget) on a formlib, browserview based form, causes the load of the tinymce widget javascript files to fail with a 404.
In portal_javascripts development mode all works fine. When caching/merging is enabled for tiny_mce.js the load of the js fails.
When caching and merging is disabled for tiny_mce.js, or in development mode, the javascript urls look like this: http://mydomain.com/portal_javascripts/Sunburst%20Theme/langs/da.js http://mydomain.com/portal_javascripts/Sunburst%20Theme/themes/advanced/editor_template.js http://mydomain.com/portal_javascripts/Sunburst%20Theme/plugins/pagebreak/editor_plugin.js etc. (lots and lots of plugins)
When caching and merging is enabled: http://mydomain.com/@@personal-information//langs/da.js http://mydomain.com/@@personal-information//themes/advanced/editor_template.js http://mydomain.com/@@personal-information//plugins/pagebreak/editor_plugin.js etc. And they all fail with a 404. Basically we try to load skin layer based resources on a view, which of course fails.
Looking at the edit page of an archetype, the same pattern happens - but in this case, accidentally it works, because we can acquire the skin resources from the at-object. Urls looks like this: http://mydomain.com/front-page//langs/da.js It works, but it is also a sign of the bug.
- Plone 4.0.3
- Zope 2.12.14
- Python 2.6.6 (r266:84292, Oct 9 2010, 12:24:52) [GCC 4.4.5]
Change History
comment:2 Changed 5 years ago by dpc22
- Cc dpc22 added
Worked out what was going on here. There are two complicating factors:
1) The site must be running in production mode (or merging enabled for tiny_mce.js in portal_javascript)
2) Site is addressed using Apache ProxyPass+VirtualHostMonster as http://foo/site/PLONE rather than just http://foo/PLONE
(Motivation: /site/PLONE gets XDV transform, /zmi/PLONE does not. We also have a collection of static Web pages which live outside /site and /zmi)
Is http://foo/site/PLONE simply not supported?
Brief Explanation:
tiny_mce.js startup can cope with a container script named either:
https://falcon-test.csi.cam.ac.uk/portal_javascripts/Falcon%20Theme/dropdown-cachekey1021.js https://www-falcon.csx.cam.ac.uk/site/FALTEST/portal_javascripts/Falcon%20Theme/tiny_mce.js
but is completely thrown by:
https://www-falcon.csx.cam.ac.uk/site/FALTEST/portal_javascripts/Falcon%20Theme/dropdown-cachekey1021.js
Detail from Products/TinyMCE/skins/tinymce/tiny_mce.js:
if (lo_array.length > 4) tests here are bogus:
tinymce.create('static tinymce.EditorManager', { preInit : function() { var t = this, lo = window.location; // Plone fix var lo_array = lo.href.split('/'); if (lo.href.indexOf('portal_factory') != -1) { while (lo_array[lo_array.length-1] != 'portal_factory') { lo_array.pop(); } lo_array.pop(); } else { if (lo_array.length > 4) { lo_array.pop(); } if (lo_array.length > 4) { lo_array.pop(); } } tinymce.documentBaseURL = lo_array.join('/') + '/';
Input: lo.href = " https://foo/site/PLONE/default-page"
Output: tinymce.documentBaseURL = " https://foo/site"
With merging disabled:
tinymce.baseURL gets set to something sensible if the containing script is named ".../tiny_mce.js" or ".../tiny_mce_src.js" because merging is disabled for the script in portal_javascript. All thanks to:
var tinymce = { majorVersion : '3', minorVersion : '2.7', releaseDate : '2009-09-22', _init : function() { var t = this, ... function getBase(n) { if (n.src && /tiny_mce(|_gzip|_jquery|_prototype)(_dev|_src)?.js/.test(n.src)) { ... t.baseURL = n.src.substring(0, n.src.lastIndexOf('/'));
comment:3 Changed 5 years ago by afd
- Cc afd added
I've had the same issue, fixed with the following hack:
I've created a page with the following content:
from Products.Five import BrowserView class TinyMCEPatch(BrowserView): def __call__(self): self.request.response.setHeader('Content-Type', 'application/x-javascript;charset=utf-8') return """ window.tinyMCEPreInit = { base:'%s', suffix:'', query:'' }; """ % self.context.portal_url()
I've registered it as a JS resource and made sure it is loaded before tinymce.js. By defining tinyMCEPreInit the baseURL will have a default sane value (getBase() will not find the proper value, but that won't matter).
comment:5 Changed 3 years ago by fulviocasali
FWIW, I just ran into the same issue on Plone 4.2.2, Products.TinyMCE 1.2.13. Turning on debug mode made the difference.
My situation is that I have some rich text tiles, where before TinyMCE didn't load, and I got a slew of 404s in Firebug like this:
http://my.site/front-page/@@edit-tile//plugins/contextmenu/editor_plugin.js
where the part between /plugins/ and /editor_plugin.js would change, but the rest of the URL was the same.
All these went away when I turned on debug mode, and TinyMCE loaded fine.
Not sure what other details I might provide could be useful.
Just to note: I see exactly this problem with Plone 4.0.7.
The static text portlet was the most obvious example where TinyMCE fails to start correctly.
Curiously TinyMCE starts up just fine if I transfer the Data.fs from a live system with the problem to my workstation (still running in production mode) which is using the same buildout environment. This suggests there is an additional complicating factor that we are missing here.