I was thinking in the preferences definition, they could set 'noglobal' => true and GP would ignore them based on that definition.

In T173474#3529568, @Legoktm wrote:

I was thinking in the preferences definition, they could set 'noglobal' => true and GP would ignore them based on that definition.

That would be a bit weird when multiple extensions use a modified core preference definition schema. As if some of this stuff begs to be in the core:)

In T173474#3532580, @MaxSem wrote:

In T173474#3529568, @Legoktm wrote:

I was thinking in the preferences definition, they could set 'noglobal' => true and GP would ignore them based on that definition.

That would be a bit weird when multiple extensions use a modified core preference definition schema. As if some of this stuff begs to be in the core:)

Probably, but I think that battle was already lost when we let extensions define custom classes to add preferences with (I didn't realize that was possible until I saw CirrusSearch doing it...).

Mostly I like that it's very little complexity on both the extension and GP side. And if GP isn't installed, PreferencesForm/HTMLForm will just ignore the 'noglobal' key.

I'm guessing the consensus here is to use the 'noglobal' key in the preference definition.

@Legoktm Your thoughts on Max's proposal in T173476: Investigation: Figure out what needs to be rewritten in GlobalPreferences would be welcome, whenever you get time.