Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Upgrading SilverStripe /

Ask questions about upgrading SilverStripe to the latest version.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

THEMES_DIR not loading properly


Go to End


10 Posts   3142 Views

Avatar
Mr V Dot

Community Member, 8 Posts

28 December 2009 at 9:28am

Edited: 31/12/2009 4:56pm

I just upgraded a couple sites to 2.3.4 (and have the same problem on all of them, including one fresh install at 2.3.4) and editor.css is no longer getting loaded by TinyMCE. I traced my requests with Firebug and saw that it was trying to call it at '[site_root]/css/editor.css' instead of from my theme directory. Looking through the code for a bit, it looks like it should prepend the 'THEMES_DIR' variable in front, but for whatever reason that's loading in blank. All these sites worked in 2.3.3.

The code is in the _config.php file for the cms module. This is the line is question:

'content_css' => 'cms/css/editor.css, '.(SSViewer::current_theme() ? THEMES_DIR . "/" . SSViewer::current_theme() : project()) . "/css/editor.css",

Any ideas on why it isn't loading? Thanks

NB: If I hard code the file to point to my editor.css file in the theme directory, it works, so I know it's not a problem with reading the file. Also, all the other function calls within the _config.php file work.

Avatar
tazzydemon

Community Member, 135 Posts

8 January 2010 at 12:34pm

Edited: 08/01/2010 12:35pm

I too had this problem on a fresh 2.3.4 install which was not there in a 2.3.1. I checked the code in the _config.php of the cms module as referred to above and added a print_r() of the content_css line.
It was incorrect and contained neither the theme editor.css or the alternative project editor.css

After that I tried a print_r() of just SSViewer::current_theme() and it was blank which was obviously wrong

adding

SSViewer::set_theme('dreamy');

just above the HtmlEditorConfig::get('cms')->setOptions()

did the trick

This means that when this cms config is loaded the site config has not yet been loaded (which is clearly incorrect in this context and is a bug)

Julian

Avatar
freakout

Community Member, 49 Posts

13 January 2010 at 8:58pm

I also have this behaviour. Is there a fix or workaround available?

Avatar
Devlin

Community Member, 344 Posts

15 January 2010 at 11:29pm

To workaround you can add, like tazzydemon described,

SSViewer::set_theme('myowntheme');

into cms/_config.php or reset content_css after set_theme in mysite/_config.php

HtmlEditorConfig::get('cms')->setOptions(array(
'content_css'=>'cms/css/editor.css, '.(SSViewer::current_theme() ? THEMES_DIR . "/" . SSViewer::current_theme() : project()) . "/css/editor.css"
));

http://www.silverstripe.org/content-editor-discussions/show/274755

Avatar
freakout

Community Member, 49 Posts

16 January 2010 at 12:02am

Thanks - but this doesn't help for me because i'm using the silverstripe core shared for 60+ sites. I cannot put the theme name into the core code. I need a more flexible workaround.

Avatar
freakout

Community Member, 49 Posts

16 January 2010 at 1:44am

I also tried to add a bug in the tracker - but it said the database is down.

Avatar
Mr V Dot

Community Member, 8 Posts

16 January 2010 at 3:32am

freakout, you should still be able to use the second workaround JayDevlin suggested, reseting the content_cms in 'mysite/_config.php', since that should be different for each site (though conveniently you can paste the exact same code in each one).

Avatar
freakout

Community Member, 49 Posts

16 January 2010 at 4:06am

this statement (SSViewer::set_theme('myowntheme'); ) _IS_ already in every mysite/_config.php !
this is exactly the bug because it is not read from mysite/_config.php!

to put it in mysite/_config.php is not a workaround because that's already the way it is normally.
this bug must be fixed and a flexible workaround must be given.

Go to Top