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
This prevents it from failing for proxied values
like BlogEntryForm, where the field name doesn't exist,
and rather gets processed and saved into a different field.
In 3.0, doing $Action => SomeController would redirect all action requests
to that default controller. In 3.1, you need to do //$Action => SomeController
but it didnt work - those initial slashes broke matching
Since that used to be the default shortcode notation
for our core "insert media" functionality, its important
to have this fixed and keep supporting "legacy" content
created with 3.0.
example configuration wuldn't allow to install silverstripe, as
install.php does exist as a regular file (and that was ignored in the
old version of the documentation)
Similarily, the last rule in the htaccess snippet that should allow the
access to the tinymce php files were never applied, as a previously
listed regex did match and denied access. Even if it would have taken
effect: as those files do exist on disk, they would have been handed out
as-is and not been interpreted by php.
Also the statement regarding accidental/exploitable execution of
arbitrary php was misleading (and to some degree even wrong) in the old
context.
squashed commit as per pr#1791
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)
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.
Caused the UploadField rows to show "[Object object]" because
it tried to pass through a PHP object to JS without string casting
(the return used to be a string).
DO NOT MERGE: to be reviewed. Only i18n & Deprecation classes use
->getModules() as far as I can see. Given that the method still simply
returns an array of modulename => modulepath, I don't think it's really
an API change
