Custom styles in wysiwyg editor

[Rob]

We have a requirement to have custom style dropdown in wysiwyg editor. This should be straightforward according to TinyMCE docs but it looks like the way TinyMCE is used in PW is non-standard and so what I'm doing isn't working.

The wysiwyg inputfield code suggests that the styleselect dropdown should be visible in the first (and only) row of buttons, but it isn't. If I edit the config for second row of buttons I can get it to appear, but I'd rather just have it next to the block format dropdown where it should be!

Is this possible without enormous hackage of the module code?!

Thanks.

[ryan]

I don't know of anything non-standard about our implementation with this, but if you can think of any ways to change it for the better I'll be happy to. Tell me what you've had to modify/hack to make it work and we should be able to make it a core change. I've never had the styleselect working the way I want, and it's in part because it seems like TinyMCE requires changes in multiple places for this, including its content.css file, so just didn't seem particularly straightforward from a simple-configuration standpoint. So the intention with PW's TinyMCE was to just exclude the styleselect, since I didn't want my clients using it, nor was I sure how to explain it to anyone else.

Looking in the code, I can see one reason why it's not working. There should be a comma after "styleselect" and before the "|", i.e. "styleselect,|". So if you edit the setting in Setup > Fields > [your field] > Input > TinyMCE Advanced, you should be able to correct it there.

Styleselect wasn't intended to be included in our default TinyMCE settings anyway, so that must be a bug I introduced in 2.2 when experimenting with the styleselect. Luckly, TinyMCE appears to just ignore it, so not much of a problem, but I will correct it in the next commit.

Assuming you can get the styleselect working as easily as I did here (by adding the comma in the field settings in the admin), then next question comes to what styles it should show. This is where I get hung up. It's pulling them from content.css, but this is something that one must edit to add more styles to it, so not as portable as I'd like... I'm also not sure why a jQuery UI style is showing up in there. When it gets down to it, I just don't understand the TinyMCE styleselect and how to get it to pick up exactly what I want (and none of what I don't), despite repeated attempts at trying (and I did read the docs).

[apeisa]

In case of portability: maybe content.css should be in /site/ folder instead of /wire/?

[Rob]

It seems that the settings in 'theme_advanced_buttons1' element of $defaults variable in InputfieldTinyMCE doesn't have any effect on anything. I also tried tweaking the settings in the JS file but that didn't help much.

The reason I implied "non-standard" is that I can add the styleselect by changing 'theme_advanced_buttons' element of that $defaults variable but nothing happens with changes to 'theme_advanced_buttons1' so I assumed it was being ignored in favour of hard-coded settings elsewhere. I've used TinyMCE before (although some years ago) and it wasn't a problem to get a style dropdown then, thus my confusion.

[ryan]

It seems that the settings in 'theme_advanced_buttons1' element of $defaults variable in InputfieldTinyMCE doesn't have any effect on anything. I also tried tweaking the settings in the JS file but that didn't help much.

That's because the defaults get overwritten by the field-specific settings. Those defaults only serve as the default settings at the time the field is created. If you want to change them for an existing field, you'll need to go edit the field in the admin. Setup > Fields > [your field] > Input (tab) > TinyMCE Advanced Settings. The purpose of this is so that you can have multiple TinyMCE fields without them having to all share the same configuration.

so I assumed it was being ignored in favour of hard-coded settings elsewhere.

It's actually the opposite. The hard-coded setting you tried to change was being overridden by the dynamic one.

In case of portability: maybe content.css should be in /site/ folder instead of /wire/?

I think this seems like a good idea to provide the option for this. But I don't want to send people towards modifying it until I can get a predictable behavior out of content.css. Right now, if I add stuff in there, sometimes it works and sometimes it doesn't. Likewise, some styles showing up (like the jQuery UI one) that aren't in my content.css. I need to spend some time in the TinyMCE forums I think.

[Rob]

That's because the defaults get overwritten by the field-specific settings. Those defaults only serve as the default settings at the time the field is created. If you want to change them for an existing field, you'll need to go edit the field in the admin. Setup > Fields > [your field] > Input (tab) > TinyMCE Advanced Settings. The purpose of this is so that you can have multiple TinyMCE fields without them having to all share the same configuration.

I totally missed those settings, seems fine now. I'l have to find out where the other styles already in content.css are being used, I'd really just like styles of our own choosing in the select box.

I don't want editors being able to align text, this is a design nightmare waiting to happen!

[ryan]

I totally missed those settings, seems fine now. I'l have to find out where the other styles already in content.css are being used, I'd really just like styles of our own choosing in the select box.

If you can figure out how to make it work in a portable way, we'll make it part of the core. Please let me know what you find.

I don't want editors being able to align text, this is a design nightmare waiting to happen!

Those classes are intended for built-in image alignment functions. They aren't intended for the styleselect. I'm just not (yet) sure how to prevent them from showing up in the styleselect. Are you also seeing the random jQuery UI style in there? I'm in the dark about that one...

[Rob]

Ryan, good news!!

http://www.tinymce.com/wiki.php/Configuration:theme_advanced_styles

I basically added 'theme_advanced_styles' to the $defaults variable in the TInyMCE inputfield code, and this added another field to the advanced field config. If you read the above link you'll see the format required, basically a seried of name=value pairs separated by semicolon.

It works a treat. Probably needs a few more checks to make sure it's bulletproof, but it basically works fine as far as I can tell.

[ryan]

I've been down this road before with the theme_advanced_styles / content.css and have had strange and inconsistent behavior. However, that was with the previous version of TinyMCE. I've not tried it since we've upgraded. If your experience is any indication, this all works now, so that is good news! I will plan to get a core entry added for theme_advanced_styles.

[Rob]

I'm on 2.1, just so you're aware.

I guess we'll see if I get weird behaviour another day!

[ryan]

Just playing with it, even now I get strange behavior. Could be something related to cache settings in MAMP's apache, but who knows. TinyMCE is pretty fantastic for what it does. But it's also one of those things I've always had to look past and just go with the flow sometimes. I've lost entire days to little issues in TinyMCE only to find them disappear on their own the next day.

[Soma]

I spent a lot of time looking for a solution to styles select in tinyMCE. I ended up using bramus css extras, as it allows for inherit and dom element dependent styles. So from infos, he states that it fixes problems with the tinyMCE default styles select only allowing anchor styles and some other weird behaviors. So his plugin enables to do things like li::ul[ yourclass ], so if you have selected a li it will put the class on the parent ul. Also it only shows styles that are allowed for the current selected dom element. It also can be set up to so it parses the .css file automaticly.

When I started playing around with it in PW I ended up copying the tinyMCE inputfield into my site folder and rename it. So I could easily setup whatever I want without touching the core. Since then I use it this way. It was still using the older version before Ryan updated it, so I'm not sure if it is any different now, but I doubt.

I can if you want attach my modified version, so you could try and go from there. I'll just have to clean it a bit.

BTW I also recognized a strange behavior with the configuration "theme_advanced_buttonsX", I had to add 'theme_advanced_buttons3 :""' to get a 2cond menu bar working. I wasn't working straight away. Just forgot completely about it.

[Soma]

Ok since I still can't upload files here, I just created a repo.

https://github.com/s...ldMyTinyMCE-PW2

here's the plugin used http://www.bram.us/p...amus_cssextras/

I forgot I updated it already with the version Ryan put in PW. There's a content.css which I used for a project, so feel free to change it to your needs. Basicly you can use it to style the look of what you have in the body in the RT to look like on the frontend (fonts, colors, styles), just put them carefully into your content.css.

Only html selectors like a.myclass, td.mytdclass get's parsed, so you can use ".myclass" to style without getting added to the select. And only if an "a" is selected the dropdown gets acitvated and show's the class. Oh and you can also do the same with #ids.

There's also a template setup included, in the "tinymce-templates" folder are the html files you can select using the "template" button (just need to add it to the config, as it's not in by default). They are then also added to the config in the js with path and name/description.

[ryan]

Soma this looks really interesting. I'm wondering if we should be including the CSS extras plugin and modifications you've made into the core TinyMCE. Can you think of any down sides?

Sorry you can't upload files. I'm not sure why, I need to check with Pete on this.

[Soma]

Soma this looks really interesting. I'm wondering if we should be including the CSS extras plugin and modifications you've made into the core TinyMCE. Can you think of any down sides?

Glad you like it. I think there isn't any downsides, at least none I can think of now (im using it in a couple projects now). Only thing I would question is, if we include it in the core, the content.css is also there. But anyway it would be possible to allow having a content.css in the site folder for easy tweaking. As is it something that has nothing to do with PW and just sits on top of it, one could question why it is in the core anyway. Speaking for myself, it's always the first thing I do since a few projects already, move that module to the site folder, so I have full control, without touching the core. But for sure it would be excellent to have a better implementation of it in the core.

Sorry you can't upload files. I'm not sure why, I need to check with Pete on this.

Can you upload files?

[apeisa]

Reason for not to be able to upload files (I cannot either):

Used 1.22MB of your 500K global upload quota (Max. single file size: 100MB)

[ryan]

I've always been able to upload files. There must not be a limit for administrator.

I just hunted around in the IPB settings and found where the limit was. I removed all limits, so hoping this does the trick. Can you guys try to upload something?

Glad you like it. I think there isn't any downsides, at least none I can think of now (im using it in a couple projects now). Only thing I would question is, if we include it in the core, the content.css is also there. But anyway it would be possible to allow having a content.css in the site folder for easy tweaking.

I think this is what we should do. I'll have ProcessWire check for existence of a content.css somewhere like /site/modules/InputfieldTinyMCE/ (or /site/templates/styles/?). If it finds it, it'll use it instead.

Glad you like it. I think there isn't any downsides, at least none I can think of now (im using it in a couple projects now).

Are you interested in doing this through a pull request on GitHub (into PW 2.2 source), or do you think better to copy/paste from the files you linked?

As is it something that has nothing to do with PW and just sits on top of it, one could question why it is in the core anyway.

In this context, I mean "core module" rather than "/wire/core/" ... something that gets included in the distribution. TinyMCE has a lot to do with the CMS side of PW even if it's technically a module. I see good core modules as any that are applicable to lots of installations (like at least 30% of installs). TinyMCE fits this, and I'm guessing it's used in at least 90% of installations.

[Soma]

Ryan, I think it's best if you copy it from my repo. If you don't mind. Since you also would need to implement something to allow external content.css. How about templates for tinymce?

Also would you also suggest it still being the prefered way to copy it to the site modules folder for extra advanced tweaking? Or would you see it possible to connect some more to be able to put in site folder, like additional plugins, templates? I could imagine having more advanced config possible to for example put in the js config code into a field or the like? What would be the way to go? As you know we already went this far with the topic, and I ended up copying it to site modules folder.

Yeah you're right about the core, I just always assume everthing in "wire" is core. Though looking closely it's kinda bundled into the distribution.

[Pete]

(sorry, checking the upload limits slipped my mind - glad you found it Ryan!)

[Soma]

Thanks Ryan, Pete it works now. No limit

[ryan]

How about templates for tinymce?

Can you expand on this? I'm not sure I understand what you mean.

Also would you also suggest it still being the prefered way to copy it to the site modules folder for extra advanced tweaking? Or would you see it possible to connect some more to be able to put in site folder, like additional plugins, templates? I could imagine having more advanced config possible to for example put in the js config code into a field or the like? What would be the way to go? As you know we already went this far with the topic, and I ended up copying it to site modules folder.

If we can make it possible for everything in TinyMCE to be customizable outside of the core, then I'm all for it. The problem is, I don't yet have enough expertise with TinyMCE's architecture to know how. We need a TinyMCE expert on our team to help maintain and optimize this module--interested in the job?

[Soma]

Can you expand on this? I'm not sure I understand what you mean.

You know the html templates in TinyMCE you can setup, to then select from the dialog using the template button? It allows to insert chunks of html i.e. table, divs, just predefined html being inserted ready to fill in your text. It is implemented in my version. You just need to add the "template" button to the config and maybe "tablecontrols"... the html templates config is hardcoded into the config js and the files located in the folder "tinymce-templates". I think it's a nice feature.

If we can make it possible for everything in TinyMCE to be customizable outside of the core, then I'm all for it. The problem is, I don't yet have enough expertise with TinyMCE's architecture to know how. We need a TinyMCE expert on our team to help maintain and optimize this module--interested in the job?

oh dear, since I already done some fooling around I could give it a try... just think need your assistance... but wait....

The hard thing for me is that I'm still not sure, what and how far this should go.

- I think for now we just can implement the css bramus plugin into the distribution, and maybe enable "templates" settings, those can be placed outside core anyway too (I think). Same with the content.css.

- If one is in need of another plugin, I could try if it's possible to include it from outside core too.

- If one needs even more, I would suggest moving it outside core and go from there and maintain it.

So I'm still trying to wrap my mind around (not first and last time I guess). Any more ideas, or thoughts?

I also think spending some energy and time to the PW plugins in tinymce, to extend or improve those, would be nice?

[ryan]

You know the html templates in TinyMCE you can setup, to then select from the dialog using the template button?

I didn't know about this. Sounds useful and I like the sound of it, but haven't seen it. Yet another thing I need to investigate further.

So I'm still trying to wrap my mind around (not first and last time I guess). Any more ideas, or thoughts?

I think we'll just go one step at a time here and start with implementing your improvements. It'll be a few days here before I can make these updates in the core, but I think it'll be a good thing to do.

I also think spending some energy and time to the PW plugins in tinymce, to extend or improve those, would be nice

The only plugins PW has into TinyMCE are the pwimage and pwlink plugins (images and links). These are powered by ProcessWire rather than TinyMCE (for the most part). What sort of extensions or improvements would you recommend?

[vsulin]

Hi,

you guys seem to be troubled more with the fact that content.css should be here or there, but as long as it is a single static file anywhere. You are limited to 1 style and class sections for all of your different fields you use the MyTinyMCE editor on your site.

So why not have a content_css.php that outputs settings that can be set per field (like all the other settings) or allowing to set the .css file used, instead of having a single style for all TextArea fields that are set to TinyMCE?

This would also allow adding the brabus plugin to the default installation and disable the need to copy the whole module to achieve it all!

Just my 2 cents!

[Soma]

Hey visulin thanks for your input, but that's basicly the idea what we (I) want to do. A setting in the inputfield where you could enter the path to a css outside /wire/ folder, basicly anywhere you want in your root or site folder. You could set all tinymce fields to share the same, or each one a different.