This resulted in Object extensions not working for it, and methods not existing
where they should have. It also resulted in poor error messages appearing when
thrown from Object since $this->class was empty since the constructor was never
called in Object.
Anyone who has run "sudo -u www-data ./framework/sake dev/build" knows that SilverStripe's temp
folder permissions can be very brittle. This patch resolves this by making the temp folder
user-specific.
To minimise directory pollution it first creates a chmod 777 parent folder with the same name
as the current folder. It then creates a subfolder of this with the same name as the current
user.
The positive impact of this change is that sake can be used without fear of messing up file
permissions. This means, among other things, that we can put a Composer post-update-cmd into
the installer to run dev/build. Progress!
The negative impact is that you will get two caches if you run sake as a different user. However,
that is much better than the current situation - which is a bunch of bugs - and if you're concerned
about that, you still have the option of running sake as www-data.
Sometimes GridState URL will have a query string already appended,
e.g. "?local=en_GB", but the GridField javascript assumes there won't
be.
The result would be an action URL like:
"/my/url?locale=en_US?RelatedPage=123" which is obviously invalid.
The fix is to check that "?" exists in the GridState URL and use
"&" instead to connect the URLs if that's the case.
Fixes http://open.silverstripe.org/ticket/6473
When using CSVParser::$columnMapping to map columns to a callback action, it previously used the action name as the key value. This prevented users from defining multiple entries to the same callback. This patch retains those key values and simply runs the callback field name filter later on.
Using SiteTree is faster, because it doesn't do any joining of Page
to get the aggregate, even though the LastEdited field is only on
SiteTree in the case of Page.
Filesystem::sync() tries to run through all pages, without caring
which subsite the page came from. The problem with this is
code in SiteTree::validURLSegment() will return invalid information,
as it will check if the page exists, thinking it does, return false,
then the page will get a new URLSegment written, e.g. "home-2".
Instead of disabling the subsite filter in Filesystem::sync(), this
fix will just loop through each subsite and sync each subsite's pages
individually before doing the main site.