With a many to many relation, e.g. SiteTree_MyRelation, and listing
them in your template then adding ?archiveDate=x in the URL, a SQL
error is shown because Versioned::augmentSQL() tries to query the
non-existent table "SiteTree_MyRelation_versions" assuming there's
versioning setup, but there isn't.
Priority for translations was hardcoded, and hardcoded the project name as "mysite".
This takes the order from a configuration property "module_prority". You can
use standard config fragment before and after rules to make a module less or
more important than anything else, with these tweaks:
- Unless it has it's order explicitly defined, the "project" module (normally mysite)
will be considered highest priority
- There is an "other_modules" value in the order list which will be replaced by
all the modules (except the project module) that don't have their order
explicitly defined.
$forceWrite was being ignored because it was tested in a part of the
code that is reachable if and only if there are changes to the object.
This patch adds an additional test to correct that logic error.
Also, refrain from needlessly checking for changes when $forceWrite is
true.
Fixes#1687
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.
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.
