The class ApiOptions is extended in extension GlobalPreferences, but the class is not part of the stable policy and that does not allow to extend it.
I am not sure what the best way is for the extension
https://codesearch.wmcloud.org/search/?q=extends%5Cs%2BApiOptions%5Cb&i=nope&files=&repos=
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T259960 Inject services into API modules and special pages | |||
| Declined | None | T285798 Stop extending core's ApiOptions |
It sounds like ApiGlobalPreferenceOverrides should extend ApiBase rather than ApiOptions, and have whatever it's using in ApiOptions moved into itself. That'll result in a bunch of duplicated code, so first a good bit of what's happening in ApiOptions::execute() should be moved into a new method in \MediaWiki\User\UserOptionsManager. For example, UserOptionsManager::setOptions( UserIdentity $user, IContextSource $context, $changes ); could be created to take most of what's happening in the main foreach loop in ApiOptions::execute(). Does that sounds suitable?
MaxSem refactored ApiOptions to allow GlobalPreferences to extend it. He just didn't add @stable to extend because his work predated the introduction of those annotations.
Per my comment at T323076#9678101, I am thinking that maybe these modules should just become parameters on the core ApiOptions module, with the core/extension interface being further back towards the storage layer. Have core expose a concept of global preferences.
As such, I don't think this task is a helpful way to frame the tech debt in GlobalPreferences.
Note that the other classes extended by GlobalPreferences (DefaultPreferencesFactory, PreferencesFormOOUI and SpecialPreferences) are also not marked stable to extend.
It's not against policy to extend a class that is not marked stable to extend. It's just that there's no guarantee of a deprecation period. That's fine for GlobalPreferences which can be updated simultaneously with core.
For the reasons above, I am marking this declined.