Ticket #12128 (confirmed Bug)
Relative links for TinyMCE CSS is suboptimal
Reported by: | runyaga | Owned by: | robgietema |
---|---|---|---|
Priority: | major | Milestone: | 4.x |
Component: | Visual Editor | Version: | 4.1 |
Keywords: | performance, optimization, navigation | Cc: |
Description
The default usage for generating custom css to be used by TinyMCE is relative to the location the editor is invoked. The URL is wrong, why /Plone/? For instance:
GET /faculty/scott.carotherstiny_mce_popup.js GET /faculty/scott.carothers/Plone/portal_tinymce/@@tinymce-getstyle
GET /faculty/saler.axel/Plone/portal_tinymce/@@tinymce-getstyle HTTP/1.1" 200 255 " http://learning.hccs.edu/faculty/saler.axel/educ1301/edit
these URLs get cannot be cached and while there is some "context" specific information that needs to be passed - i doubt that we need this call. And its unnecessary computation.
One recommendation would be to add a /@@tinymce-getstyle-byname/$skinname Since the caller knows the skinname that is being used.
For sure the referrer (ehe edit page, /edit) requesting @@tinymce-getstyle SHOULD NOT request a URL with physical path information such as site id, /Plone/ in it.
Change History
comment:2 Changed 4 years ago by kleist
- Status changed from new to confirmed
- Keywords performance, optimization, added; performance optimization removed
- Version set to 4.1
comment:3 Changed 3 years ago by jpg
I was trying to find out why tiny_mce is using relative links for every request. TinyMCE has some code to detect the baseURL from where the script is called and thereafter uses that for dynamic request, but that code depends on the name of the js itself:
https://github.com/plone/Products.TinyMCE/blob/1.2.x/Products/TinyMCE/skins/tinymce/tiny_mce_src.js#L47 (I'm linking to tiny_mce_src.js for readability)
so, this was working until this commit:
https://github.com/plone/Products.TinyMCE/commit/5a3c9623c9c324e29c2da2f9ebdbf970d195c7ce
because until then the expression matches but now that never happens and the code ends up with a null baseURL, so everything is relative...
as long as I can test there is three solutions:
- revert that commit, tiny_mce.js should be no cacheable and no cookable, this forces a new request for every page to non anon. users, but improves the cacheability of tinymce dynamic content
- patch tiny_mce initialization to not use that code, we don't need it because plone already define a portal_url variable than could be used as baseURL
- define a new global variable at jsvariables.py, var tinyMCEPreInit = { suffix: , base: '%(portal_url)s' };, tiny_mce uses that and didn't try to guess the baseURL
IMHO the last one is the cleaner solution.