Don't hardcode SiteTree in CMSMain

[GuySartorelli]

CMSMain has a tree_class configuration property which is sometimes referenced - but sometimes SiteTree is explicitly hardcoded.
The hardcoded references and the assumptions about using SiteTree should be removed.

Benefits

• opens a path for further refactoring to allow other hierarchical data to be displayed in a hierarchical way
• opens a path to 'demistify' SiteTree so it becomes just another subclass of DataObject rather than having its own code paths in admin
• opens a path to reduce code/feature duplication across admin and cms modules (e.g. the search UI, sending toasts, handling tabs/breadcurmbs and more)

Related

• SPIKE Analyse how LeftAndMain and CMSMain are put together and how they could work better #2933
• original POC PR - this PR includes many additional notes and implementation details

Notes

• There are many ways to make calls to SiteTree methods/properties more generic, such as:
  • Implementing a method on CMSMain that calls that method if it exists, but falls back on other things - e.g. get MenuTitle if there is one, but fall back on Title
  • Moving the main implementation of the method from SiteTree into CMSMain, and invoking an extension hook on the record (probably with invokeWithExtensions()) to allow updating the value
• Don't forget there's both a tree view and a list view! Both of these need to work and have their strings updated.

Acceptance criteria

• A getModelClass() method is implemented, which returns the value stored in the tree_class configuration property
  • This is to conform with the LeftAndMain refactor
• All hardcoded references to SiteTree or Page use the getModelClass() method instead (including subclasses of CMSMain)
• Nothing assumes the model has the Versioned extension
• Whenever CMSMain, one of its subclasses, or a template tries to call a method or fetch a property that is explicitly implemented on SiteTree, this is handled in a generic way
  • If any method/property is explicitly required which isn't provided by the DataObject class or the Hierarchy extension, throw clear exceptions if they're missing. One example (and probably the only case) is CMSEditLink.
• In an appropriate place (maybe init()), a clear exception is thrown if the model class doesn't meet requirements to be used in CMSMain (i.e. doesn't have the Hierarchy extension applied, or is missing a method/property that is explicitly required for CMSMain to work)
• Strings which assume SiteTree is being used are updated to pull from whatever model is used.
  • e.g. "Page type", "Add page", "Choose where to create this page", "Pages", etc.
• With exception of the history tab, filtering the tree list, and batch actions (which will each be handled separately), all functionality in CMSMain works with TaxonomyTerm (when that class has the CMSEditLinkExtension extension applied - see config in the description of the POC PR)

TO DECIDE

• Currently the site name (defined in siteconfig) is displayed as the root of the tree. This makes sense for pages but probably not for other models. What should be the root of the tree for non-page models?
  • Should it be configurable?
  • Should there be no root?
  • Should we just leave it as the site name for now and change it later if we feel like it?

Decision for the above: Leave that as is for now. Part of #2951 will include keeping the site name being returned from CMSMain while the generic abstract class returns a generic value.

PRs

Quick cleanup PR:

This PR removes the provideI18nEntities() entry for a localisation key that was just always in the wrong place. More details are in the PR itself.
It doesn't block anything so even if you have questions about this PR, please also review any other PRs below that are ready for review.

• ENH Remove code that doesn't belong here silverstripe-framework#11430

Moving Code Around PRs:

There's a bunch of stuff that CMSMain relies on which is currently only on SiteTree. This set of PRs moves most of that stuff around so that it can be reliably called on any DataObject class which has the Hierarchy extension, which is the criteria for models to be used in CMSMain.

You can see these changes in context in the "Main PRs" section

CMS 5 PRs

• New BC-safe API to support CMSMain refactoring silverstripe-framework#11461
• API Deprecate and update code in preparation for CMS 6 #3023
• API Use new class_description configuration silverstripe-subsites#610
• API Use new class_description configuration silverstripe-blog#794
• API Use new class_description configuration silverstripe-errorpage#127
• API Use new class_description configuration silverstripe-registry#111
• API Use new class_description configuration silverstripe-iframe#102
• API Use new class_description configuration silverstripe-userforms#1347
• API Use new class_description configuration recipe-content-blocks#51
• API Use new class_description configuration silverstripe-elemental#1272
• API Use new class_description configuration dnadesign/silverstripe-elemental-userforms#102
• DOC Document new class_description and deprecated DBEnum::flushCache() developer-docs#626

Reassign to Guy after merging these so they can rebase the CMS 6 PRs on top

CMS 6 PRs

Kitchen Sink CI

• API Move logic from silverstripe/cms into central place silverstripe-framework#11460
• API Move some code to framework to be reusable #3022
• API Update API to reflect changes in silverstripe/framework silverstripe-versioned#479
• API Use new class_description configuration silverstripe-elemental#1271
• API Use new class_description configuration dnadesign/silverstripe-elemental-userforms#101
• API Update code to reflect changes in dnadesign/silverstripe-elemental recipe-content-blocks#50
• API Update API to reflect changes in silverstripe/cms silverstripe-iframe#101
• API Update code to reflect changes in silverstripe/cms silverstripe-subsites#609
• API Update code to reflect changes in silverstripe/framework silverstripe-assets#655
• API Update code to reflect changes in silverstripe/cms silverstripe-blog#793
• API Update code to reflect changes in silverstripe/cms silverstripe-errorpage#126
• API Update code to reflect changes in silverstripe/cms silverstripe-registry#110
• API Update code to reflect changes from silverstripe/cms silverstripe-userforms#1346
• DOC Document code moved from cms to framework developer-docs#625

Reassign to Guy once these PRs are merged so they can rebase the main PRs and get those ready for the review cycle.

Main PRs:

CMS 5 PRs

TBD

Reassign to Guy after merging these so they can rebase the CMS 6 PRs on top

CMS 6 PRs

• API Stop refering to "pages" when dealing with generic records silverstripe-admin#1837
• API Make CMSMain more generic #3017
• API Move logic from silverstripe/cms into central place silverstripe-framework#11439
• API Update code to reflect changes in silverstripe/cms silverstripe-assets#652
• API Update code to reflect changes to LeftAndMain silverstripe-subsites#604
• API Update code to reflect changes to LeftAndMain silverstripe-versioned-admin#367
• ENH Update code to reflect changes in silverstripe/cms silverstripe-lumberjack#175
• ENH Update code to reflect changes to silverstripe/admin silverstripe-campaign-admin#336
• ENH Update code to reflect changes to silverstripe/admin silverstripe-asset-admin#1503
• ENH Update code to reflect changes to silverstripe/admin silverstripe-reports#198
• ENH Update code to reflect changes to LeftAndMain silverstripe-sharedraftcontent#265
• API Update code to reflect changes in CMSMain silverstripe-userforms#1339
• API Update API to reflect changes in silverstripe/cms recipe-content-blocks#49
• API Update API to reflect changes in silverstripe/cms silverstripe-blog#789
• API Update API to reflect changes in silverstripe/cms silverstripe-errorpage#123
• API Update API to reflect changes in silverstripe/cms silverstripe-registry#109
• ENH Update code to reflect changes to LeftAndMain tractorcow-farm/silverstripe-fluent#897
• API Add new configuration for use in CMSMain-like admin silverstripe-taxonomy#125
• DOC Document changes to CMSMain and LeftAndMain developer-docs#600