tiny_mce.js content differs from wp-tinymce.js.gz

[ali3n0]

Hi folks,
we've noticed the problem in the object because we're not using gzip as content-encoding (it seems a server side bug so far...) and the fall back logic in wp-includes/js/tinymce/wp-tinymce.php doesn't work correctly because of it (tiny_mce.js tries to include not existing files, such as en.js).

The fix is quite straightforward (unzip wp-tinymce.js.gz into tiny_mce.js), but as an additional feature request I'd suggest to add support for "content-encoding: deflate" in the same way other php file do for compression in the latest source, such as:

wp-admin/includes/ajax-actions.php
wp-admin/load-scripts.php
wp-admin/load-styles.php

and use gzip only as a fallback.

[azaozz]

In WordPress TinyMCE can be loaded in two different ways:

• Standard: loads tiny_mce.js (the core) that loads all plugins when it is initialized. This is also used when SCRIPT_DEBUG is set. As WordPress loads the translation strings from PHP, there is a function to mark the language files as loaded, so TinyMCE doesn't try to load them again.

• Pre-compressed: loads the TinyMCE core plus all default plugins as one pre-compressed (.js.gz) file. This makes the loading quite faster. That file contains similar function to stop TinyMCE from trying to load language files.

The purpose of wp-tinymce.php is only to check whether it should output the pre-compressed file and if the browser supports compressed (gzipped) input. Nothing is compressed at runtime.

It seems your server has some configuration issues (perhaps always tries to compress output) that can be fixed/improved in htaccess.

Supporting deflate would mean we will have to add another pre-compressed file or start compressing at runtime. However all modern browsers support both compression formats (which are very similar), so doing this doesn't make much sense.