Wp-tinymce.php deprecation

General Discussion
1

Hi,

there is wp-tinymce.php file in /wp-includes/js/tinymce. The files in the folder don’t follow best practices and raises some doubts (e.g. Shield Security Unrecognised Files: wp-tinymce.js.gz).

The reason of wp-tinymce.php is to detect if browser supports GZIP and if so, the static gzipped version of TinyMCE is served (wp-tinymce.js.gz) + expires headers are set. I think it is not necessary today - almost all browsers supports gzip and webservers can handle the compression and headers themselves.

The same logic is performed in the class-wp-editor.php, so the function of that PHP file is redundant.

Besides,It is suspicious to find “.php” file in the “/js” folder. The wp-tinymce.php is only file in wp-includes which is called directly. if you remove this request, you can apply stricter security rules and harden you installation by blocking all direct HTTP requests for PHP file from wp-includes.

I suggest to deprecate wp-tinymce.php and load regular TinyMCE JS from the class-wp-editor.php.

2

Is “almost all” good enough? And how would a piece of software influence the server’s handling of the expire headers? This software is supposed to work everywhere, not “almost” everywhere.
The post editor is not the only place that the TinyMCE is used.

3

I’m talking about wp-tinymce.php script, not TinyMCE itself. This script is used only in one place Search · wp-tinymce.php · GitHub. The code is redundant, unnecessary and complicates usage of security best practices.

According to gzip compression | Can I use... Support tables for HTML5, CSS3, etc I think “almost all” is good enough. The point is that there won’t be any breaking change - uncompressed version will be served in case of unsupported browser.

2 Likes