Previously relied on the presence of a last column which wasn't filterable,
commonly a GridFieldEditButton. If this wasn't present, the filter buttons
were never added, leading to the GridField JS reload request being sent
without the required button form action, so GridFieldFilterHeader->handleAction()
was never called.
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.
Moved to end of requirements, to work around a bug in composer - see https://github.com/composer/composer/issues/1147. This caused the dependencies to be installed in the wrong folder because the custom 'silverstripe-module' instructions hadn't been loaded at the time the core modules were installed via composer.
It was using $fieldName, which is the CSV field name, not the database
field name. This prevents duplicate detection from working. It now
properly uses $SQL_fieldName
It was using $fieldName, which is the CSV field name, not the database
field name. This prevents duplicate detection from working. It now
properly uses $SQL_fieldName
Makes setups which are completely driven by that file a bit easier
to automate, particularly if the same codebase is deployed
multiple times (e.g. to a staging and live instance)
API: CompositeDBField::setValue() may be passed an object as its second argument, in addition to array.
These changes provide a 15% - 20% performance improvement, and as such justify an small API change in the 3.0 branch. It will likely affect anyone who has created their own composite fields, which is fortunately not all that common.
