Themes

How did you do the upgrade? Using github, or by deleting/removing the old files except config.php and replacing them with the new 3.2 ones?

Hi,

I have just updated my server to MOODLE_32_STABLE branch using GIT. If you have not got that branch version dated 20161205 then anything can go wrong.

I must admit I have had problems like you have described and so I suggest you wait until the OFFICIAL Moodle 3.2 is launched which should be in the next 24hours. There were four fixes that went in this last few days so the version you have may have those bugs in it!

Hope this helps?

Mary

The fact you deleted the cache probably has not helped. I did than found later that it was a SCSS error that I had made when adding some styles, just a missing } curly brace was enough to sink HMS Moodle!

Mary

Al, I have had these same problems.  I have concluded that the overall CSS is not kicking in.  

I see that I am into this discussion a little later than everyone else.

When I installed my 3.2dev into MAMP, I had these same problem.  But as I tried things, such as clearing the cache, switching to CLEAN, switching back, etc., (can't say exactly what) all of a sudden Boost would kick in and work.  Then, as I would add some CSS or variable to Boost's theme, the overall CSS wouldn't work and I would get what you get.  Once again, doing this and that would fix it.

I could never figure out what was fixing it.

On my VPS, I have had some, but not as many, similar experiences.  I thought that I was the only one, but now I see that I am not alone.

I am encouraged that it may just be something with 3.2dev.

Have you tried enabling "Theme designer mode"?

Site Administration > Appearance > Themes > Theme settings

That way you will have the CSS files included separately, which would hopefully help you find out where it breaks.

I'm also experiencing this issue on a completely new install. I pulled the stable 32 branch from git, ran the install process and ended up with a screen identical to the OP.

I can get it to work by turning on the theme developer mode. With that mode off, the cached "all" style doesn't load.

I'm not seeing any php errors and everything seems to work fine in clean, so it's as if the SASS isn't compiling correctly.

Ive run out of ideas for testing myself, so would appreciate any advice.

Cheers!

I've been working on a new theme in which I cloned the boost theme and renamed the needed lines of code and files and was soon ready to start customizing. I haven't really used SASS that much as I'm quite content using plain ol css so I decided to try and commit to using SASS as Moodle seems to be pushing this.....I think?. As soon as you turn on the designer mode SASS recompile's everytime taking 2+ minutes all to end up timing out, due to php timing out, followed by a few more refreshes. I then turned it off and tried purging caches via CLI and it's the same result of waiting for a few minutes just to get a page with no CSS at all, exactly like the image you posted.

I'm sorry but this is horribly inefficient when it comes to making theme changes. If I make one little css change in my sass file I then have to wait a few minutes only to refresh again, wait another 30 seconds and refresh one more time. I spent a few hours just trying to change a couple things and decided to quit using sass. 

Perhaps I'm missing something to speed this process up??

I cannot have this on production. There are times when I have to purge caches as other mods/blocks/plugins have javascript or css changes. And on the occasional time something just weird is happening and caches need to be purged mid day (don't like to do this but sometimes it has to be done). If this happens on production then thousands of students are gonna hit a page with no css and we'll get a flood of emails and tickets complaining moodle is broken.  Only cause SASS is taking it's sweet time recompiling. 

Again, maybe I'm missing something to speed this process up??

HOW TO FIX: So my work around was to simply grab the all.css file in your moodle data directory:

   moodle_data/localcache/theme/[some number here]/[name of your theme]/css/all.css

   theme/[your theme]/style/all.css

Remove all references to scss in the theme/[your theme]/config.php and now add all.css to your sheets array.

$THEME->sheets = array('all')

// $THEME->scss = function($theme) {

//     return theme_uleth_get_main_scss_content($theme);

// };

// $THEME->csstreepostprocessor = 'theme_uleth_css_tree_post_processor';

At least this way while scss is disabled you can quickly make theme changes and be able purge caches and see the results almost instantly.

Perhaps if you really want to turn scss back on once your done styling you can reverse the process above and include your new changes in either a sass file or add it to the $THEME->sheets array.

HTH.

Another cause with the same symptoms is exhausted "memory_limit". The minimal necessary value for my site is 160 MB, to render a request "/theme/styles.php?/boost/123.../all", otherwise the php css parser fails on memory allocation every times if the result is not cached. (moodle/lib/php-css-parser/Parser.php) It can not be cached until it succeeds once.

Unfortunately, the setting "Debugging / Debug messages" was NONE and nothing has been found in error_log. It was also very complicated to search and understand anything in administration settings without css. I think that "Debug messages" should be increased during upgrade or maintenance mode at least to level "MINIMAL: Show only fatal errors", because it is terrible to find and increase it through site administration after failed upgrade.

To recapitulation of this long thread: There are three known causes of the same symptoms: 1: invalid css, 2: short max_execution_time , 3: low memory_limit. It is trivial to differentiate them with fatal error reporting, but without this - we can only guess. Maybe removing some modules helped other people (above) not because there was every times something invalid is the css, but also because memory and time requirements decreased by less modules.