Before this was only possible for some specific ones, like onBeforeWrite.
This excludes any callbacks with augment*() or update*() naming,
since these are assumed to be on extension only, with a corresponding
base method available on the class itself (e.g. "updateCMSFields()"
vs "getCMSFields()").
- Refactored SiteTreeURLSegmentField to render controls in template
rather than JS for better clientside performance, and cleaner behaviour.
- Added dynamic ellipsis to start of URL, to retain most relevant
part of the URL (the last bits)
- Added "suffix" setting to field, which defaults to ?stage=Stage
- Removed prefix from edit view to leave more room for URL
Thanks to @sunnysideup for getting this started in
https://github.com/silverstripe/silverstripe-cms/pull/269
Utilise the new features provided by the framework to get richer
interface:
* save buttons that highlight the current state of the page
* minor actions in a drop-up
* embed last publishing and saving information
The custom SQL does not take subsites into account and breaks the CMS
on certain pages - under some circumstances the custom count will return
1 or more, while the set will be in fact empty because of augmentation.
This function is misspelled, and was marked deprecated. This commit
removes that function. Please use prepopulate_permission_cache()
instead (note the removal of the extraneous "p" in "prepopuplate")
Object::extend already does a check for NULL before it adds the results
to the array of return values. This was required for Translatable as the
result from Translatable::augmentValidURLSegment was being ignored.
Was fetching the record from live (and its direct URLSegment),
but all of its parents from the current stage, which might be draft,
leading to "mixed" draft/live nested URLs which might no longer
be reachable in live mode.
translations were not added in the same translation group, and the
translation module didn't work. Also commited changes in the translation module, which will need this commit.
Called for each subclass by the collector,
so we don't need to aggregate here.
In fact, its harmful because it causes entities
to be placed in the wrong definitions file.
The <class>.DESCRIPTION entity was always placed in cms/lang/en.yml,
regardless of the original location of the file containing the class.
Allow loading a SiteConfig by ID (by specifying $tree_class),
and pass the ID through with the form data. Unifies processing
with SiteTree, and allows the Translatable module
to use the same logic for interacting with the load/save process.
Mainly to make it compatible with the Translatable
extension linking to existing translations of it,
but also to make it work similarly to the SiteTree logic elsewhere.
