https://github.com/miraheze/ManageWiki/pull/398

I now have a working patch for this, just need to finish a few things then will submit a PR for SRE to review...

I've ran the script again so I'm closing this as resolved however, indeed it seems we have an issue with Cargo but I'm not sure why. Our configuration is, for the most part, standard, so it's strange that we encounter this issue. I don't know if it's an upstream issue or just us but this is indeed something we must look into. Unfortunately, none of the SRE team really used Cargo enough to be very familiar with it so we need to familiarize ourselves with how it works in order to debug it best.

Could I get this ran again? I just did a bunch of editing that touched a lot of the effected pages.

The upstream issue is marked as resolved.

Related to T4699: Module /doc subpages not using wikitext as page content model

Oh, I missed the email. It's not about specifically my wiki, but when creating .css subpages in the Template namespace in any wiki, the content model still remains default to wikitext instead of automatically creating as sanitized-css like the behaviour in Wikimedia wikis. Users still need to manually change content model for new pages to make them sanitized-css content model.

Agent Isai is the Community Engagement Specialist. There's not a reason to be pinging them on this request. They're not an extension developer.

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.

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 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.

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.

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.

In T6110#213987, @Bbbtest wrote:

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

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

Before I resigned this is what I meant to say but never did, but up to someone else now.

It refreshes on a cron, so it probably just refreshed on schedule.

Odd. Let us know if it occurs again.

Probably some tables were updated, cause today it showed more or less correct (-4) number.

I've changed this in DPL3 now it'll be updated during next round of extension updates.

Should now be fixed following the re-resetting of the wiki around a month ago. Please feel free to reopen if that is not the case.

seems fixed.

Part of this can be put on hold while assessing the possibility of TSPortal integration. The part that can be done is having a cw_flagged and cw_flagged_reason.

In T10522#213218, @OrangeStar wrote:

Is good-old JSON acceptable for the list?

Is good-old JSON acceptable for the list?

https://phabricator.wikimedia.org/T328595 is relevant. It'll probably be useful to see how the WMF does things

In T10583#213148, @kaoyu666 wrote:

In T10583#213100, @Reception123 wrote:

We don't generally approve personal extensions/extensions used by a person for a single wiki. What is the purpose of your extension?

1.Custom footer text

2.UCenter user avatar embedding(UCenter means the user center of Discuz forum)

3.MCBBS user point analysis(mcbbs is a minecraft forum)

4.BiliBili video embedding(BiliBili is a website like YouTube in China)

These four functions are very useful for my wiki. And there is no substitute for this extension on the mediawiki website.I really hope you can add them.

We don't generally approve personal extensions/extensions used by a person for a single wiki. What is the purpose of your extension?