refactor(core): improve extensibility of Admin Pages

[DavideIadeluca]

2.x port of #4037

Progresses #4060

Changes proposed in this pull request:

Reviewers should focus on:

Screenshot

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

Required changes:

• Related documentation PR: (Remove if irrelevant)

[DavideIadeluca]

@SychO9 Before continuing with this PR I need some clarification on how to proceed here. I already refactored the AppearancePage to use multiple ItemLists. I now saw that there was a refactoring done into how settings are defined (#4022).

Mainly the BasicsPage has been refactored to leverage the AdminRegistry. Wrapping those settings in a ItemList seem superfluous to me as the settings are already an ItemList behind the scenes.

Stepping back for a bit – here are two use cases why those extensibility improvements in the Admin Frontend are useful and how they are used in 1.x:

1. In one of our proprietary extensions we allow making the forum title translatable. We replace the original input field and add a button instead with the functionality to add translations for each language. For 1.x this is done like so:

   extend(BasicsPage.prototype, 'contentItems', function (items) {
   	items.setContent(
   		'forum-title',
   		<div className='Form-group'>
   			<label>{app.translator.trans('core.admin.basics.forum_title_heading')}</label>
   			<TranslationKey translation={...} />
   		</div>,
   	);
   });

2. In a community, the Welcome Hero is not used at all. To prevent confusion, we removed the Welcome Banner setting:

   extend(BasicsPage.prototype, 'contentItems', function (items) {
   	items.remove('welcome-banner');
   });

Right now, I have 2 questions:

1. How should we cover those use cases of customizing and removing core settings in a developer-friendly way? Perhaps we introduce new methods in the AdminRegistry
2. Should/will the AppearancePage eventually be refactored to leverage the app registry (mainly thinking of the theme_primary_color and 'theme_secondary_color' here.

Thoughts?

[SychO9]

How should we cover those use cases of customizing and removing core settings in a developer-friendly way? Perhaps we introduce new methods in the AdminRegistry

I think adding setSetting and removeSetting (and same for permissions perhaps) would make sense.

Should/will the AppearancePage eventually be refactored to leverage the app registry (mainly thinking of the theme_primary_color and 'theme_secondary_color' here.

Maybe, maybe not, the reason I left it the way it is, is because of how custom the structure of the appearence settings are (color items, theme modes, ..etc) unlike other pages where settings are directly listed. It'll probably stay the way it is i think 🤷🏼

[SychO9]

I think adding setSetting and removeSetting (and same for permissions perhaps) would make sense.

Addressed in #4209

This PR should be good to go

[DavideIadeluca]

Thanks for taking care of this!

Also good to go from my side

[SychO9]

Thanks!