Broke after I optimized it to work with a TreeDropdownField
which assumes <li><a> structures that thie "preview" dropdowns
don't have. I also failed at the recursion assignment, causing
infinite loops...
SQLQuery->setLimit(0, 99) should result in "SELECT ... LIMIT 0 OFFSET 1".
In fact it does "SELECT ..." without a LIMIT clause at all,
which is unexpected. This is regardless of the $offset value.
This caused problems when duplicate() was used in the CMS UI
to duplicate a SiteTree object. Since every object of this type
has a ParentID relation, it copied this empty relation into
new "ghost page".
See https://github.com/silverstripe/silverstripe-cms/issues/689
This is a necessity for any further 3.1 pushes of master files to getlocalization.
Because we'd otherwise remove existing master strings for CTF etc,
which means we can no longer backport new translations to 3.0
(and there's no way for users to contribute translations to 3.0 via getlocalization).
It's still a very monolithic class, but at least I've refactored it to return
all collected strings without writing it to files (for easier testing).
Per [RFC 2616 section 5.1.1][ietf], HTTP methods are case-sensitive.
- Change the internal representation of the form's method to upper case
- Update FormTest to accommodate the case changes
- Change method to lower case for HTML in Form#getAttributesHTML()
[ietf]: http://tools.ietf.org/html/rfc2616#section-5.1.1
Supports passing an array to removeByName(), which is iterate and then removed. Useful for removing fields from a fieldlist that are not on a tab. Similar to removeFieldsFromTab();
This is cleaner than a new function.
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.
