We are migrating CKEditor issue tracking to GitHub. Please, use GitHub to report any new issues.

The former tracking system (this website) will still be available in the read-only mode. All issues reported in the past will still be available publicly and can be referenced.

Important: we decided not to transfer all the tickets to GitHub, as many of them are not reproducible anymore or simply no longer requested by the community. If the issue you are interested in, can be still reproduced in the latest version of CKEditor, feel free to report it again on GitHub. At the same time please note that issues reported on this website are still taken into consideration when picking up candidates for next milestones.

Skin sprite image caching causes garbled toolbar icons after upgrade

Description

We just upgraded from v4.1.1 -> v4.1.3, and upon viewing the first time, everyone sees garbled/unreadable toolbar icons. Refreshing or clearing cache fixes it, but it appears very broken the first time people load it after upgrade.

Looks like there's no cache version on the skin's icons.png file (ckeditor/skins/moono/icons.png).

We'd like to see the same cache timestamp that's applied to other files, applied to the sprite image, to prevent this going forward. So in the case of 4.1.3, the sprite url would somethinglook like 'ckeditor/skins/moono/icons.png?t=D6IC'.

Unfortunately, despite the importance of this issue, we will not have any resources to work on the builder part for at least next 2-3 months. This forces us to postpone this ticket even further, so currently the most reasonable milestone is 4.6.0.

4.6 is the closest possible milestone. 4.5 will be released in couple of days and change like this one cannot be included in a minor release. The good news is that 4.6 will not take so much time as 4.5. We we'll be back to our ~4 month release schedule.

In the meantime - we really do recommend serving every CKE version from a different directory (e.g. ckeditor/4.4.8/ckeditor.js). Unless you try to concatenate all files together this solves the issue.

It's worth mentioning that concatenating all files is considered best practices.

Yes and no. If you have a website where CKEditor is used in 3 of 10 subpages, then it does not make sense to serve the same asset on all of these 10 subpages. It's better to split the asset so CKEditor can be loaded conditionally. Also, I cannot find the article now, but I remember reading that the optimal number of assets isn't really 1. If I remember correctly it was because browser waits so long to download it, while it could start parsing and executing some other file if the asset was split.

Anyway, not important here. We understand that some developers want to concatenate CKEditor with other scripts or that URL cannot be changed.

+1 for this from me, also. This has been a source of pain for me with regards to CKEditor upgrades.

In the meantime - we really do recommend serving every CKE version from
a different directory (e.g. ckeditor/4.4.8/ckeditor.js). Unless you try
to concatenate all files together this solves the issue.

I do not entirely agree with this approach for CKEditor. I recognize this is considered a best practice regarding cache management by many, but my view is that it really is most applicable to resources in the folder structure that do not end up getting referenced via <a>/<img> tags in the content.

A specific example would be the smileys. A huge headache that I ran into was that I was ending up with a huge bunch of broken <img tags for smileys when upgrading from one ckeditor version to another and using the folder version approach. (300,000+ users... major pain) The reason, of course, was that the smileys are essentially content that is bundled with the smileys plugin in editor builds, and they are inserted into the content via <img tags that reference their file folders in the current editor folder structure, *unless you specifically tell the editor to look in another folder location in the config*. It took me a while to sort out isolating the smileys folder separate from the cke folder structure and setting the smiley folder location in the editor config.

Therefore, the folder version approach can cause problems for anything that the editor *inserts into the content* via a link or image tag that references bundled content in the current folder structure. Since I do not know what types of content (beyond smileys) you may bundle with the editor in the future, I specifically choose not to use the folder version approach, and I am also very much in favor of using a version/timestamp query parameter instead. What I would prefer is that you include it as an version/timestamp value as "buried" default config setting that I can override via a config setting I specify--that will help with special cases where I may need to force a resource reload for my users. (A specific example is forcing a reload for mono vs color toolbar icons.)

The priority of doing something about this should be elevated, because in the current state this (like all caching-related bugs) breaks things in an unpredictable way, and when it does break it happens in a spectacular way (in the case of a cached icons strip).

The big problem here is that CKEditor advertises that it takes care of cache busting with the build version it appends everywhere. To make matters worse, with the icons the markup makes it appear that the right thing is happening, because each toolbar button has an inline style with a resolved background image url and a build number--the version of the url without the build number is sneakily winning because the rule in the skin's editor.css is !important. If something is known to be broken, it's better for it to be broken in an obvious way.