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.
Update CsvBulkLoaderTest to remove keys that are nonexistent in the CSV
test data. Having them causes the test to fail with an undefined-index
error. This did not previously fail because of the bug in CsvBulkLoader
that this patch fixes. This partially reverts c4eac53.
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)
