Given that we are a Gentoo Linux shop and that SilverStripe hasn’t been packaged yet, I wrote an ebuild script to aid installation and maintenance.
SilverStripe itself is somewhat a mixed bag – it looks very shiny, but on the back-end it’s not so nice… For one, it requires “lower_case_table_names = 1” to be set on MySQL on Linux (which is admittedly at least half MySQL’s fault – but how difficult is it really to ensure that you only access a given table with the same name you created it with?), it also fails to install unless “allow_url_fopen = On” is set in php.ini (which definitely is SilverStripe’s fault – this setting can be changed in the PHP code being executed), and installing on anything other than Apache (such as lighttpd in our case) requires some obtuse re-write rules.
Worst of all, though, is that the webapp aggressively caches into the /tmp/ directory (which has got to be a bad idea, from a sandbox point of view if nothing else) and isn’t very clever about invalidating the cache. This means that if you reinstall the CMS (for testing purposes, for example) or change the database connection being used, then you’ll get back nothing but a bunch of error pages until the /tmp/ directory is cleared out.
You can admittedly append “?flush=1” to any SilverStripe URL you request – but this only affects the fetched page. This means that, for any non-trivial changes, access to the filesystem is probably going to be required to ensure that any visitor is seeing the site and not errors.
In my opinion, caching should be an optional feature which is off by default and which caches only within the webapp installation directory. It should certainly be able to regenerate is something significant is changed – perhaps each installation needs a UUID against which each page is compared in a light-weight test, and is only served from cache if these match?