13.. continued... OK so there's conflicting reports of if Block Cache Alter module (above) is able to make a difference if core's block cache is disabled. I think not, but regardless I've enabled it and applied the correct settings to every block as this was a 15 min job. The reason for going ahead with this (apart from it might work) is that then now we have a correct record of what blocks should be cached, and how.
We now need to track down which module is disabling them. Once we know what's causing it we can hopefully get around it and instantly gain a good boost in performance. This then becomes proposal I: Re-enable block caching.
Another part of what I just did was to split the 'top user links' bar with login/account into two, one for anonymous, one for authenticated. This way we can cache the former for every page (as it uses the page path to return users to the page they were on when logging in), and the latter means we can cache it once for the current user. Each version is now shown to the correct user.
The reason this was needed is that these blocks are currently executing evaluated PHP, which is php calling php on a string with eval() -- this is very slow. So the work I've outlined allows us to now grab these blocks and push them into code, which is proposal J: Convert inline PHP into module code and features.
Finally, this required the CSS to be corrected (as it was looking for just the specific block), so I've tweaked that and also noticed Ben had left LOTS of SASS debugging code in the CSS. I've now stripped that out for a minor client speed/bandwidth improvement.
Summary updated.
