With this modification we can use Object::useCustomClass() to create a
custom ChangePasswordForm form:
Object::useCustomClass('ChangePasswordForm',
'CustomChangePasswordForm');
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.
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.
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)
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
