In T10640#214439, @OrangeStar wrote:

Are you sure you want to set rcenchancedfilters-disable and wlenhancedfilters-disable to false? I think it's true (or 1) what you're looking for.

In T10639#214400, @Agent_Isai wrote:

We strive to stay as close as possible to stock MediaWiki so we won't be doing this.

In T10624#214315, @Universal_Omega wrote:

Just to note that as one who has put significant time into ManageWiki and our cleanish configuration, I am opposed on adding this to ManageWiki, as it is not a clean method of doing so. But it is really not up to me anymore so it's up to whoever ends up actioning this task.

However, these are already done per-request, and there are numerous wikis that have already done them by request and in my opinion that should be how it continues to be done to avoid a much more complicated config.

Anyway, I understand wanting to add them, but some things are better left not in ManageWiki due to risk of overcomplicating, and this, to me, seems to be one such instance. I'll leave this to SRE now that I have said my thoughts on it.

In T10626#214191, @Void wrote:

there are more places

Such as? I'm not really aware of any. At most there might be some finicky business with sysop or autoconfirmed, but given that ManageWiki allows one to delete these groups already, I don't see any particular reason why we should prevent renaming from being an option. Same with external references such as scripts. Most global references that are important (such as Abuse Filters) were modified to search for user rights instead of groups years ago for this reason. Additionally, the upstream task you linked really only seems like it caused trouble due to WMF developers effectively forcing a technical change that the community did not support. In fact the only technical challenge that I was not already aware of that the task brought to light was:

The problem with just renaming groups is that all the old log entries point to the old group.

More interesting to me is the existence of the migrateUserGroup.php script, which would either be what we'd use for this, or a variation of the same.

In T10626#214186, @Naleksuh wrote:

@Void No, there are more places and even if you changed those you can't change external places where it's used (i.e. scripts that people make). Like I said before this happens once in a blue moon and when it does happen it's usually for a technical reason. A good example of this is https://phabricator.wikimedia.org/T112147 - and even when it is necessary, a huge amount of disruption was caused. That's why it's generally recommended not to do that, especially when the point is just to change the display name, which you can already do via MediaWiki pages

In T10626#214174, @BrandonWM wrote:

In T10626#214172, @Naleksuh wrote:

Groups can be renamed by editing the relevant MediaWiki pages. If you mean changing the underlying name, this is not something that you are supposed to do; in the 20 years of MediaWiki history I can count the number of times this has happened on one hand

Out of curiosity, why is it not supposed to be done? Changing user group names could be beneficial because of typos or something of the sort.

In T6110#214023, @Universal_Omega wrote:

Unfortunately not, I was previously the only active maintainer of the extensions, however OrangeStar might take over to an extent eventually. I am not sure though.

In T10625#214021, @Agent_Isai wrote:

This is a very wide scoped task which is ultimately unactionable technically.

In T10625#214021, @Agent_Isai wrote:

This is a very wide scoped task which is ultimately unactionable technically. If you update your site's CSS, you can try purging the page's cache and also your cache and trying again in a few minutes.

In T6110#214015, @Universal_Omega wrote:

Not really from a UI perspective. It's kinda hard to explain for me, but it really can't be done, unfortunately. Though like I said, I don't handle extensions anymore, at least not for now, so I cant say if it'll ever be attempted or not right now. I agree it's useful, and it would be very nice to have, but unfortunately can't right now as far as I know.

In T6110#214003, @Universal_Omega wrote:

I resigned yesterday. Its impossible because of the complex structure of $wgDefaultUserOptions, since each key as a preference and each value can be a different type of variable, there isn't really an ideal way to implement it into the UI in ManageWiki. It could be a new field for every possible preference but that would not be good on UI either. Apologies that it isn't possible, and hopefully that this answered your question a bit.

In T6110#214000, @Universal_Omega wrote:

In T6110#213987, @Bbbtest wrote:

@Universal_Omega Is it still impossible? I really want this.

I have resigned from SRE. I am no longer handling extensions for Miraheze right now. But to answer your question I already added $wgHiddenPrefs to ManageWiki a while ago, but $wgDefaultUserOptions is unfortunately still impossible as far as I know.

@Universal_Omega Is it still impossible? I really want this.

In T10594#213298, @Universal_Omega wrote:

I would also like to note, that for any modern security review to pass, 99% of the entire skin will need rewritten, just working will not pass review if it does not use modern codeing standards/hard to understand or uses to many deprecated functions.

@Agent_Isai Doing this tomorrow.

In T10594#213263, @Agent_Isai wrote:

We indeed have lots of skins but all of them are maintained by their developers and compatible with the latest version of MediaWiki. This skin was discontinued almost 20 versions ago. Miraheze does not maintain any skin on its own because the technical burden would be too much and as this skin is completely incompatible with MediaWiki 1.39 and broken, this task is declined. Thank you for your understanding.

In T10584#213102, @BrandonWM wrote:

I would support this, but would oppose making this the only option. Users should be able to opt out. Cross-wiki pinging is useful because it allows people to receive notifications faster.

In T10584#213094, @Bukkit wrote:

I personally would not support such a change. I have cross-wiki notifications on strictly Meta for a reason, I do not wish to have notifications regarding other wikis on any non-meta wiki.

In T10584#213087, @Raidarr wrote:

I like this idea. It's particularly useful for people with cross-wiki presence but who might not understand this option exists since it's poorly advertised (buried at the bottom of a preference menu). I don't think it would do any harm to people who only participate in one or a couple wikis and in fact it would help in cases where people need to be 'centrally notified' of something through Meta but aren't regular participants there (especially say, global username violations or something to do with a wiki request when they're only active on one). If it's not feasible to make this a default then perhaps there is a way to make people more aware - I think more people would use this if they knew.

That said, you can enable it globally through Special:GlobalPreferences. That raises the other issue with it though - to make it useful (ie, actually work globally out of the box) you have to first travel to global preferences and then enable the setting. It's not intuitive and I don't find the interface for it to be very friendly.