Installation problems often come down to a 'white screen of death' either during installation or after it. The WSOD is generally caused by a PHP error that isn't picked up by SilverStripe's error handler. This change fixes the first of those.
As a bigger fix, I'd like to see us allow the installation of sites in dev mode, the enabling of display_errors=on in dev mode, and perhaps even the ability to easily perform an initial installation in dev mode before switching to live mode. However, that's a bigger change for another time.
increase_memory_limit_to() was broken a while ago, and this causes a lot of problems for people trying to install on environments where the memory limit is 32M.
If the applyRelation() was passed a relation that went to a class with a parent
class with a database table, applyRelation would return the name of the parent
class, rather than the class the relation was actually too.
Nasty issue where nested requests to sub-controllers within LeftAndMain->EditForm() would fail because of
LeftAndMain->currentPageID() being taken from the URL, even though it was a field action name.
Example: POST /admin/pages/edit/EditForm/field/MyGridField/item/1/ItemEditForm/field/MyUploadField/upload
The current ID would be detected as "field" in this case.
Bug was previously fixed for AssetAdmin.
This bug was caused by the fact that SQLQuery::whereAny() removed existing filters. In line with addWhere() and setWhere(), I split this into addWhereAny() and setWhereAny(). Strictly speaking, this drops the method SQLQuery::whereAny(), but it was really just an internal function for exclude, and so I think that's acceptable.
7427 was mostly fixed by Ingos previous patch. But two batch actions, delete from draft site and delete from published site werent returning
status messages. Abstracted out the status preperation code that the batch actions that were returning status messages were using, and
used that to add status messages to the problem two
2.4 used to use a manifest to find css. One side-effect of that is that even without explicit support,
css files in module-specific themes (/themes/{theme}_{module}/) would get picked up. This broke in 3.
This fix does still require the module name to be explicitly passed as a parameter to themedCSS, but if
you do, and a css file of that name exists in the module-specific themes css directory, that will
be included in preference to the theme or module provided css
