Default TinyMCE Theme

[Pete]

Can I make a suggestion that the default skin for TinyMCE should actually be "default" and not "o2k7"?

The thing is, whilst "o2k7" fits in with the default ProcessWire admin theme, the theme called "default" fits in better with almost every other theme produced so far.

I can see a couple of options here - switch the theme to "default" for new downloads from now on and override the colours for the default PW theme, or else make that a configurable part of the module (though the second option doesn't help if you want to set it with your admin theme).

I realise what I just suggested above for the default PW theme - overriding the CSS in the admin theme - is another possible way to do it but it's just that every other theme looks fine with the theme "default" and only the original PW admin theme looks fine with "o2k7".

Another alternative would be a simple way to override the setting outside of InputFieldTinyMCE.js but I can't think of one off the top of my head. It just gets a little annoying at present to have to remember not to override the setting I change with each new PW upgrade

Not a big issue of course, just one that bugs me a bit

[Soma]

Soma to the rescue.

Just add new line to "Additional TinyMCE settings" field in "TinyMCE Advanced Confoguration Options" under "Input" tab:

skin: default

or

skin_variant: anything

Enjoy!

[Pete]

Thanks, that certainly helps it stop being reset on upgrade!

It would still be ideal if there were a way of setting the value somehow within a theme package though.

[diogo]

Wow, tried this and it worked

<script>
InputfieldTinyMCEConfigDefaults.skin = "default";
</script>

put it on the default.php of your theme after all the other scripts or before </body>

[Pete]

Oh now that's just perfect - had no idea it would be that simple diogo!

It works just as well in the admin template's main.js file too!

@ryan - any chance it could be included in the main.js by default? I know it doesn't necessarily need setting for the default theme, but having the prompt there that you can change it would be handy!

[Soma]

That's cool diego, I was just about to try something in the main.js of a theme.

This might be the simplest solution. I want to add you can also make the o2k7 a silver or black skin variant

<script>
InputfieldTinyMCEConfigDefaults.skin_variant = "silver";
</script>

In case anyone wonder why this works. This is because the InputfieldTinyMCE.js javascript has a config object var with that name "InputfieldTinyMCEConfigDefaults", so with this we can overwrite the config defaults or ones set via field configuration directly before TinyMCE is enabled and reading that config.

Thanks diogo for finding this.

[diogo]

I guess my javascript readings are paying out

edit: hm... or should I say "paying off"?... maybe I should also do some reading on how to write English correctly

[Soma]

Well you never can read enough and try

So the correct version would be following. Here's what I implemented in my Teflon theme now.

...
 <script>
  // overwrite TinyMCE skin setting globally
  // as defined in /wire/modules/Inputfields/InputfieldTinyMCE/InputfieldTinyMCE.js
  // and loaded before
  if('undefined' != typeof InputfieldTinyMCEConfigDefaults) InputfieldTinyMCEConfigDefaults.skin = "default";
 </script>
</head>

[ryan]

@ryan - any chance it could be included in the main.js by default? I know it doesn't necessarily need setting for the default theme, but having the prompt there that you can change it would be handy!

Do you mean like put it in a /* comment */ or something?

[Pete]

Yes - just as a hint more than anything as I don't think it will do any harm. Maybe even mention the default skins you can switch between too (default, o2k7 and highcontrast from what I can see). That would be great

[diogo]

What if Ryan would make all the tinyMCE folder portable with the theme? Would be possible just by changing this line:

$this->config->scripts->add($this->config->urls->InputfieldTinyMCE . "tinymce-" . self::TinyMCEVersion . "/tiny_mce.js");

to this:

$this->config->scripts->add($this->config->urls->adminTemplates . "tinymce-" . self::TinyMCEVersion . "/tiny_mce.js");

on the render function of the module

EDIT: there's a better solution on the next post

Edited September 23, 2012 by diogo

[diogo]

There's no need to change anything on the module. Everything can be done inside the theme, by putting a copy of the tinyMCE folder (with the new skin inside) on the theme folder, and changing Soma's code to this:

<script>
if('undefined' != typeof tinyMCE){
  InputfieldTinyMCEConfigDefaults.skin = "ergo";
  tinyMCE.baseURL = "<?php echo $config->urls->adminTemplates?>/tinymce-3.4.7";
}
</script>

The version number can be changed to <?php echo InputfieldTinyMCE::TinyMCEVersion?>, or any better way to get this constant (i'm sure there is)

I don't seem to find any nasty effect with this. What do you think?

EDIT: ok, there is at least one nasty thing... the "html" button doesn't work because PW doesn't allow accessing html files inside /templates-admin/

[Soma]

I don't like the idea of having another TinyMCE instance outside core just for a theme's skin one have to maintain aswell. We've brought in external custom plugins and overwriting config on a per field basis and as we seen it's also possible to have the setting changed from the admin theme. It's up to the theme maker.

[diogo]

I agree that in most situations having a different skin doesn't justify these changes. But the truth is that this solution doesn't touch the core or even the module. Those two lines would go on the theme's template, and the new tinyMCE folder would go on the theme's folder. It would be completely up to the theme maker to decide if changing the skin has that kind of importance to the theme or not.

[Soma]

If you really want to have a skin together with admin theme you could do something like this without having whole TinyMCE delivered. Put the "ergo" skin somewhere into templates-admin folder.

if('undefined' != typeof InputfieldTinyMCEConfigDefaults){
 InputfieldTinyMCEConfigDefaults.skin = "ergo";
 InputfieldTinyMCEConfigDefaults.editor_css = "/site/templates-admin/themes/ergo/ui.css";
 InputfieldTinyMCEConfigDefaults.popup_css = "/site/templates-admin/themes/ergo/dialog.css";
};

[Soma]

I agree that in most situations having a different skin doesn't justify these changes. But the truth is that this solution doesn't touch the core or even the module. Those two lines would go on the theme's template, and the new tinyMCE folder would go on the theme's folder. It would be completely up to the theme maker to decide if changing the skin has that kind of importance to the theme or not.

With this hack, you'll also still have the tiny_mce.js core loaded by the field. Not very convincing. Apart from all dialogs not working.

<script type='text/javascript' src='[url="http://pw2-dev.ch/wire/modules/Inputfield/InputfieldTinyMCE/tinymce-3.4.7/tiny_mce.js"]/wire/modules/Inputfield/InputfieldTinyMCE/tinymce-3.4.7/tiny_mce.js[/url]'></script>

[diogo]

If you really want to have a skin together with admin theme you could do something like this without having whole TinyMCE delivered. Put the "ergo" skin somewhere into templates-admin folder.

if('undefined' != typeof InputfieldTinyMCEConfigDefaults){
InputfieldTinyMCEConfigDefaults.skin = "ergo";
InputfieldTinyMCEConfigDefaults.editor_css = "/site/templates-admin/themes/ergo/ui.css";
InputfieldTinyMCEConfigDefaults.popup_css = "/site/templates-admin/themes/ergo/dialog.css";
};

Did this work for you??

[Soma]

Yes it does.

[diogo]

With me it's messing up the icons, beause the stylesheet is looking for them here "../../img/icons.gif". They are not there, of course...

edit: works well if you put the "img" folder also inside "templates-admin". I agree that it's a much better solution!

[Soma]

Of course the image folder (whole "ergo" folder) should be in there.

[diogo]

The problem wasn't with "ergo". I was trying with the default skin, that gets the icons on "img" directory that is above.

[Pete]

If you really want to have a skin together with admin theme you could do something like this without having whole TinyMCE delivered. Put the "ergo" skin somewhere into templates-admin folder.

if('undefined' != typeof InputfieldTinyMCEConfigDefaults){
   InputfieldTinyMCEConfigDefaults.skin = "ergo";
   InputfieldTinyMCEConfigDefaults.editor_css = "/site/templates-admin/themes/ergo/ui.css";
   InputfieldTinyMCEConfigDefaults.popup_css = "/site/templates-admin/themes/ergo/dialog.css";
};

Soma - this was exactly what I was trying to work out the other day so thanks a million

With the joys of localhost versus live site folder structures however this is now probably better if it's put back in the default.php template file just before the closing </head> tag as this:

<script>
if('undefined' != typeof InputfieldTinyMCEConfigDefaults){
   InputfieldTinyMCEConfigDefaults.skin = "ergo";
   InputfieldTinyMCEConfigDefaults.editor_css = "<?php echo $config->urls->adminTemplates; ?>themes/ergo/ui.css";
   InputfieldTinyMCEConfigDefaults.popup_css = "<?php echo $config->urls->adminTemplates; ?>themes/ergo/dialog.css";
};
</script>

Then it'll work in every environment.

Thanks again for working most of that out - I really think this is the ultimate way now of overriding the TinyMCE template for themes and not having to worry about the TinyMCE module being updated or overridden so I'm very happy with this

[Pete]

Oh, but I'm now seeing an issue with where it's trying to pull content.css from when I look at Firebug.

NetworkError: 404 Page Not Found - http://localhost/pw/wire/modules/Inputfield/InputfieldTinyMCE/tinymce-3.4.7/themes/advanced/skins/ergo/content.css

Soma - can you confirm there's an error there? I'm not sure how to solve it though as it's not as simple as adding another line for the content_css variable

[diogo]

Pete, add this line to the code:

InputfieldTinyMCEConfigDefaults.content_css = "<?php echo $config->urls->adminTemplates; ?>themes/ergo/content.css";

[Soma]

Yes it's trying to load the content.css from ergo in core.

Though it still load the one you specify in the field additional settings. So no big deal for me.