Deprecate DataExtension and other superfluous classes

[emteknetnz]

The convention has been to use DataExtension instead of Extension for DataObjects

DataExtension adds a bunch of extra methods and shouldn't be used, Extension should be used instead

Acceptance criteria

• Deprecate DataExtension
• Deprecate SiteTreeExtension
• Deprecate LeftAndMainExtension
• Deprecate any other abstract or abstract-like Extension subclasses
• Message should be to subclass Extension directly instead
• Remove documentation that refers to the deprecated extensions
• Changelog indicates they have been deprecated
• Any conditional logic that uses DataExtension::class or subclasses is identified and dealt with - for example

CMS 5 PRs

• API Deprecate DataExtension #11347
• API Deprecate LeftAndMainExtension silverstripe-admin#1812
• API Deprecate SiteTreeExtension silverstripe-cms#2991
• DOC Deprecate DataExtension and others developer-docs#563

CMS 6 recipe-kitchen-sink multi PR CI

• https://github.com/creative-commoners/recipe-kitchen-sink/actions/runs/10592161773
• https://github.com/creative-commoners/recipe-kitchen-sink/actions/runs/10608455864

CMS 6 PRs - merge, merge-up and rebase CMS 5 PRs first

• API Replace Extension subclasses bringyourownideas/silverstripe-composer-update-checker#95
• API Replace Extension subclasses silverstripe-elemental#1241
• API Replace Extension subclasses silverstripe-admin#1813
• API Replace Extension subclasses silverstripe-asset-admin#1487
• API Replace Extension subclasses silverstripe-assets#632
• API Replace Extension subclasses silverstripe-auditor#90
• API Replace Extension subclasses silverstripe-behat-extension#281
• API Replace Extension subclasses silverstripe-blog#780
• API Replace Extension subclasses silverstripe-campaign-admin#323
• API Replace Extension subclasses silverstripe-cms#2992
• API Replace Extension subclasses silverstripe-contentreview#251
• API Replace Extension subclasses silverstripe-documentconverter#94
• API Replace Extension subclasses silverstripe-errorpage#120
• API Replace Extension subclasses #11348
• API Replace Extension subclasses silverstripe-frameworktest#201
• API Replace Extension subclasses silverstripe-graphql#599
• API Replace Extension subclasses silverstripe-gridfieldqueuedexport#120
• API Replace Extension subclasses silverstripe-ldap#88
• API Replace Extension subclasses silverstripe-linkfield#321
• API Replace Extension subclasses silverstripe-lumberjack#167
• API Replace Extension subclasses silverstripe-mfa#561
• API Replace Extension subclasses silverstripe-realme#156
• API Replace Extension subclasses silverstripe-securityreport#87
• API Replace Extension subclasses silverstripe-session-manager#212
• API Replace Extension subclasses silverstripe-sharedraftcontent#253
• API Replace Extension subclasses silverstripe-staticpublishqueue#200
• API Replace Extension subclasses silverstripe-subsites#593
• API Replace Extension subclasses silverstripe-textextraction#101
• API Replace Extension subclasses silverstripe-userforms#1319
• API Replace Extension subclasses silverstripe-versioned#468
• API Replace Extension subclasses silverstripe-versioned-admin#359
• API Replace Extension subclasses silverstripe-versionfeed#119
• API Replace Extension subclasses symbiote/silverstripe-advancedworkflow#550
• API Replace Extension subclasses symbiote/silverstripe-queuedjobs#444
• API Replace Extension subclasses tractorcow-farm/silverstripe-fluent#879
• DOC Replace Extension subclasses developer-docs#566

[maxime-rainville]

Not sure about this one. The empty methods on [DataExtension](https://github.com/silverstripe/silverstripe-framework/blob/5/src/ORM/DataExtension.php) might not be necessary, but they have the value of making it clear what methods have special meaning when adding an Extension to a DataObject and enforcing their signature.

Minimally, updateSummaryFields and updateFieldLabels seem to be doing a little something.

[GuySartorelli]

they have the value of making it clear what methods have special meaning when adding an Extension to a DataObject

If we think that's important, we should have a policy to document them (perhaps updating the API docs to pick up on and document them automatically). Having empty classes to pick up the slack of documentation is an anti-pattern.

and enforcing their signature.

Enforcing their signature is actually bad for us, because it makes the method signature of extension hooks part of our public API that we can't alter outside of major releases and therefore we can't add new arguments to them.

[emteknetnz]

DataExtension::updateFieldLabels() appears to do nothing, as it merges in Config::inst()->get(static::class, 'field_labels') (static::class does resolve to the owner class, not just DataExtension) with &$fields ... however that already happens in DataObject::fieldLabels() with $customLabels = $this->config()->get('field_labels'); ... $labels = array_merge((array)$autoLabels, (array)$customLabels); - $labels is an assoc array so the extension method is just duplicate code.

DataExtension::updateSummaryFields() is basically the same, it merges in fields of an assoc array from Config::inst()->get(static::class, 'summary_fields') ... however DataObject::summaryFields() already does this. There is some extra logic in the extension method to handle non assoc arrays, though based on my brief debugging it's always assoc arrays being passed in

These extension methods really do feel like old code that should have been removed a long time ago

[GuySartorelli]

CMS 5 PRs merged. Reassigning to Steve to rebase CMS 6 PRs

[GuySartorelli]

PRs merged