Closed patrickmj closed 8 years ago
I think this is a possible way to tackle themes needing to change the css on tinyMCE using content_css
( http://www.tinymce.com/wiki.php/configuration:content_css )
First, instead of working with tinyMCE the way the admin side does it, we change where the default initParams are to outside Omeka.wysiwyg()
on public pages
Omeka.wysiwygInitParams = { }; // same object now inside Omeka.wysiwyg()
Omeka.wysiwyg = function(params) {
initParams = Omeka.wysiwygInitParams;
// everything else continues as it does now
}
Then, if a theme wants to add content_css
to tinyMCE, it can add it to Omeka.wysiwygInitParams
.
There might be better ways to expose those initParams to the theme than this way, of course. Maybe it would just be a global floating around that Omeka.wysiwyg
needs to check for?
I imagine that more plugins will want to use tinyMCE on the plugin side, so if we can figure out a pattern here, that'll be helpful, I think.
I don't really get the context for this issue.
Omeka.wysiwyg
doesn't even exist in the public theme.
that's another twist -- Commenting plugin currently adds it. if more than one plugin wants to use tinyMCE, we'd need to figure out how to make them play nicely.
The default tinyMCE styles are very bright, which is a bit of a clash with the darkness of 'night'. I think I now understand people's reaction the first time I wear shorts in the summer:
First looks seem like these might the relevant CSS rules, but not entirely certain that's the best approach:
This is most noticable in 'night', but might be something to look at across themes