Make WordPress Core

Opened 9 years ago

Closed 8 years ago

#4067 closed defect (bug) (invalid)

Changes to TinyMCE filters don't get updated due to browser cache

Reported by: Viper007Bond Owned by:
Milestone: Priority: low
Severity: minor Version: 2.2
Component: Administration Keywords: needs-patch
Focuses: Cc:


Didn't know what to call this one, so someone feel free to improve the ticket's title.

I have a plugin that adds an external TinyMCE plugin and then adds some buttons via mce_buttons or mce_buttons_2 filters depending on what line number the user wants the buttons on.

However, if they change the option and my plugin uses the other filter, it won't show the change until the user hard refreshes (and clears there cache). Or at least this is the case with the latest version of Firefox.

Here's some code to show what I'm doing:

add_filter('mce_plugins', array(&$this, 'mce_plugins'));
if ( 1 != $this->settings['tinymce_linenumber'] ) {
	add_filter('mce_buttons_' . $this->settings['tinymce_linenumber'], array(&$this, 'mce_buttons'));
} else {
	add_filter('mce_buttons', array(&$this, 'mce_buttons'));
add_action('tinymce_before_init', array(&$this, 'tinymce_before_init'));
// Add buttons in WordPress v2.1+, thanks to An-archos
function mce_plugins($plugins) {
	array_push($plugins, '-vipersvideoquicktags');
	return $plugins;
function mce_buttons($buttons) {
	if ( 1 == $this->settings['tinymce_linenumber'] ) array_push($buttons, 'separator');

	array_push($buttons, 'vipersvideoquicktags');
	return $buttons;
function tinymce_before_init() {
	echo "tinyMCE.loadPlugin('vipersvideoquicktags', '" . $this->fullfolderurl . "resources/tinymce/');\n"; 

Not a big deal (I added a notice telling users to clear their cache), but a bug nonetheless.

Change History (5)

#1 @foolswisdom
9 years ago

  • Milestone changed from 2.2 to 2.3

#2 @foolswisdom
9 years ago

  • Milestone changed from 2.3 to 2.4

#3 @ev3rywh3re
8 years ago

The only method I know of that helps is to "fake load" the tiny_mce_config.php file.

I've done this by loading up a file with bogus TinyMCE_Engine javascript followed by an include of tiny_mce_config.php in my plugin admin page where they make the setting changes. So basically once the configuration is changed the tiny_mce_config.php file has been updated and should be cached because they loaded it without using it... kinda. At this point most users can just reload the editor pages and see the updated editor.

This is what I put in "admin_head" for the plugin config page:

<script type='text/javascript' src='<?php echo get_settings('siteurl'); ?>/wp-content/plugins/myplugin/js/bogus_tinymce.js?up=<?php echo rand(101, 199); ?>'></script>
<script type='text/javascript' src='<?php echo get_settings('siteurl'); ?>/wp-includes/js/tinymce/tiny_mce_config.php?up=<?php echo rand(101, 199); ?>'></script>

I don't know if adding the random numbers helps or not :P

Here is the example bogus "bogus_tinymce.js" Javascript file that is included in "admin_head":

/* for bogus tinymce.init */

function TinyMCE_Engine() {

TinyMCE_Engine.prototype = {
	init : function(settings) {
	loadPlugin : function(settings) {

var tinyMCE = new TinyMCE_Engine();

Hope that helps.

#4 @ev3rywh3re
8 years ago

Since this description is sort of confusing, how about an example? The fake loading of the tiny_mce_config.php file occurs when you view the administration panel for this plugin.

Administration interface code is in the superedit_admin.php file. I didn't use wp_enqueue_script in this case because I wanted random GET values to help this update the browser cache. Bogus javascript is located in the js/superedit.js file.

Anyway... Works for me.

#5 @darkdragon
8 years ago

  • Milestone 2.5 deleted
  • Resolution set to invalid
  • Status changed from new to closed

Recommend closing for now, since the issue isn't really WordPress related or something that WordPress can easily solve.

I'm sure that there are some things that you can do to prevent caching or invalidating the browser cache.

Feel free to reopen if occurring in TinyMCE 3.0, however, it probably should be more related to something WordPress can fix and not browser related issues.

Note: See TracTickets for help on using tickets.