Please note that in order to enable resizing, one must use the advanced theme and enable the theme_advanced_resizing setting

Whilst investigating on how I precisely could hook onto the resize event I tried all kinds of stuff (can’t even recall ‘m all … it’s been a while since I actually coded this ) yet one thing was certain: the hook had to be placed after TinyMCE got inited. Aha, that rings a bell: init_instance_callback to the rescue!

Most likely you already know this: After TinyMCE is inited, the editor itself (not the UI) in fact is an iframe. Perfect, as iframe have a resize event! Now, the init_instance_callback function we’re about to define has one parameter passed in: a tinymce.Editor instance. Via the provided getDoc function we can then get access to the iframe.

As of TinyMCE 3, the internals of it have been totally refactored (check the API: lots of classes ) and contains lots of functionality which you can also find in the infamouse JS libraries (jQuery, Prototype, MooTools, etc.). One of those classes is tinymce.dom.Event by which we can add eventHandlers to given elements via its add method.

Given the knowledge above, it’s really easy to hook onto the resize event:

1. Adjust your tinyMCE.init so that the init_instance_callback function gets called

   tinyMCE.init({
   	...
   	init_instance_callback : "myCustomInitInstance"
   });

2. In your defined init_instance_callback function, hook onto the instance’s iframe resize event via tinymce.dom.Event

   function myInitInstance(inst) {
   	tinymce.dom.Event.add(inst.getWin(), 'resize', function(e) {
   	   // Do your thing here 
   	});
   }

3. That’s it; Happy coding!

It certainly is no obligation but it would most certainly put a smile on my face

bramus_cssextras is a plugin for TinyMCE which enables the usage of CSS classes and CSS ids on any HTML element within TinyMCE. Together with an external CSS file, set via the TinyMCE content_css setting, bramus_cssextras bridges the (visual) gap between the content entered through TinyMCE and the actual output; as seen below.

Plain TinyMCE vs. TinyMCE with content_css vs. TinyMCE with content_css and bramus_cssextras

Where content_css only lets you view the CSS styles applied on elements, bramus_cssextras takes it to the next level by letting you set these CSS styles on any element, giving the user more power on the visual representation then ever before.

bramus_cssextras works really simple: Just hook it to TinyMCE, add the button references and you’re good to go. bramus_cssextras will do all the work for you, by scanning the defined content_css-file for possible classes/ids which can be set on elements. Then, when editing a piece of HTML through TinyMCE, bramus_cssextras will make your life easier by showing you which classes/ids can be set on the current element and will even let you set a specific class/id on that element.

Yes you can!

bramus_cssextras is free and released under a Creative Commons License. The latest version (0.5.0 the time of writing) can be downloaded from the project page.

bramus_cssextras 0.5.0 is TinyMCE 3.x only, older versions of bramus_cssextras are TinyMCE 2.x only. These older versions can also be downloaded from the project page (version 0.4.1 is suggested).

On a sidenote, I myself don’t suggest on using TinyMCE 3.0 as it still is in beta

As I hadn’t worked with MCFileManager nor MCImageManager before I dove into the sourcecode of the plugins to see what is happening when each plugin is loaded. Turns out the plugins were written to play nice when used together. In laymens terms it comes down to this:

• The MCFileManager plugin it basically states: If it’s an image and MCImageManager is loaded: use MCImageManager to handle the image; else (viz. file or media) use me
  (@see Line #50 of filemanager/js/mcfilemanager.js)
• The MCImageManager plugin states: If it’s a file and MCFileManager is loaded: used MCFileManager to handle the file; else (viz. image or media), use me.
  (@see Line #50 of imagemanager/js/mcimagemanager.js)

The quick fix would be to edit imagemanager/js/mcimagemanager.js, to make it so that media is passed to MCFileManager. As I don’t like modding the sourcecode of an existing plugin because that would make upgrading a pain in the ass, I continued my quest to finding an elegant solution as the two statements above gave me an opening into tricking the plugins which one would load what.

The opening lies in the fact that both plugins can handle media. Given this I quickly looked at the config we use, right where the plugins are loaded. There I found:

tinyMCE.init({
	...
	plugins : "inlinepopups,filemanager,imagemanager,paste,contextmenu,media,bramus_cssextras",
	...
});

(yes, Netlash was already using bramus_cssextras even when I wasn’t working there yet ).

So where’s the problem? That line quite obviously loads MCFileManager first which states that MCImageManager should be used when it’s an image, right? Right, but not 100% right …

TinyMCE loads the plugins in serial mode: one by one (viz. the one after the other). If (for example) the first plugin loaded states that the variable window.myVar equals 100; and the second plugin loaded states that it’s 200, one will end up with window.myVar being equal to 200. Given that as a background, we end up with 2 scenarios:

Scenario A: filemanager, imagemanager

The first scenario is the one where MCFileManager is loaded first (viz. its init function is executed first), and then MCImageManager. In code that reads:

tinyMCE.init({
	...
	plugins : "filemanager,imagemanager",
	...
});

Now, when clicking on the browse button when placing a link, an image or media, MCImageManager is executed first as it was loaded last (flash back to the background I wrote above). MCImageManager will tell to use MCFileManager if it’s a file, and continue working if it’s something else (an image or media).

Scenario B: imagemanager, filemanager

The second scenario is the one where MCImageManager is loaded first (viz. its init function is executed first), and then MCFileManager. In code that reads:

tinyMCE.init({
	...
	plugins : "imagemanager,filemanager",
	...
});

Now, when clicking on the browse button when placing a link, an image or media, MCFileManager is executed first as it was loaded last. MCFileManager will tell to use MCImageManager if it’s an image, and continue working if it’s something else (a file or media).

Translating the above into a little table, we end up with this nice “scenario matrix”:

What is loaded?	Scenario A	Scenario B
file	MCFileManager	MCFileManager
img	MCImageManager	MCImageManager
media	MCImageManager	MCFileManager

Yes, it’s the last row that’s most important of it all

In order to use MCImageManager to handle media, init the plugins like this:

tinyMCE.init({
	...
	plugins : "filemanager,imagemanager",
	...
});

In order to use MCFileManager to handle media, init the plugins like this:

tinyMCE.init({
	...
	plugins : "imagemanager,filemanager",
	...
});