Some of the SQLQuery recipes are now handled better by DataList,
others should be contrasted with their respective DataList implementation,
pointing out the limitations
PaginatedList needs to be notified about this, otherwise it will
errorneously try to further limit the already limited set, making the
subsequent pages empty.
Without this bugfix, if you had a Page that used to be a SiteTree, and you tried to use Versiond::get_version() or Versioned::get_latest_version() to return the older SiteTree version, nothing would be returned, because the results were being filtered by ClassName. This caused bugs in the history panel for certain combinbations of page classname alteration.
- Removed duplicated content from page-type-templates (was more or less a variation of the content in templates.md)
- Removed built-in page-controls, which was a bit of a dumping ground for unconnected topics.
Moved the majority to page-type-templates
- Removed all recipes from "sitetree" docs, since they were outdated or hacky (like grouping of records, or implementing custom *children() method on subclasses)
- Added pagination, escaping, base_tag, CurrentMember to template docs
- Removed default_parent docs from SiteTree, as this setting doesn't have any effect looking at core
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.
