Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API Stop refering to "pages" when dealing with generic records #1867

Merged

Conversation

GuySartorelli
Copy link
Member

Replaces #1837

Two commits here:

  1. Updates some i18n keys that should live in LeftAndMain. Found this because I had to review all i18n strings in CMSMain anyway.
  2. Updates some API that currently refers to "pages" when it's really dealing with any DataObject class, and adds a new getModelClass() method to LeftAndMain (standardises that method between ModelAdmin and CMSMain and will be used extensively in the follow-up refactor cards in this epic)

Issue

CMSMain::class . '.ACCESS',
LeftAndMain::class . '.ACCESS',
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CMSMain doesn't even exist if you're installing silverstripe/admin without silverstripe/cms. LeftAndMain is the obvious choice here.

'category' => _t(Permission::class . '.CMS_ACCESS_CATEGORY', 'CMS Access'),
'category' => _t(LeftAndMain::class . '.CMS_ACCESS_CATEGORY', 'CMS Access'),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This belongs on LeftAndMain as it goes hand-in-hand with the one above.

$abstractClasses = [LeftAndMain::class, CMSMain::class];
$abstractClasses = [LeftAndMain::class];
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is needed so that CMSMain can be included in the left menu and have its route built.
Without this, it was the CMSPagesController which was a very-nearly-useless subclass of CMSMain that was used.
That class has been merged into CMSMain so we need its menu item back

Comment on lines +111 to +112
if ($publishedRecord instanceof SiteTree) {
$treeTitle = CMSMain::singleton()->getRecordTreeMarkup($publishedRecord);
Copy link
Member Author

@GuySartorelli GuySartorelli Dec 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like new hard coupling - but this class was always intended to be used with SiteTree - or at least has really only been used with it until now in core. The SiteTree use statement was even already there.
The coupling will be removed in silverstripe/silverstripe-cms#2950

@GuySartorelli GuySartorelli force-pushed the pulls/3.0/generic-cmsmain branch from ac52d1d to b42c820 Compare December 11, 2024 01:51
@GuySartorelli GuySartorelli marked this pull request as ready for review December 11, 2024 23:13
@emteknetnz emteknetnz merged commit 1d5cecb into silverstripe:3.0 Dec 12, 2024
5 of 16 checks passed
@emteknetnz emteknetnz deleted the pulls/3.0/generic-cmsmain branch December 12, 2024 04:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants