I have now installed the skin. It can now be enabled from https://facquodvis.miraheze.org/wiki/Special:ManageWiki/extensions#mw-section-skins.
No response. Please reopen if still needed, and provide us with a list to delete. Thanks!
Per conversation I had with @R4356th via Discord, declining until the skin reaches a more stable state, right now the code is changing to much to do a proper review.
Add this to MediaWiki:Common.css and it will likely fix it for you.
This was fixed upstream, but should be resolved, but usually Upstream stuff or invalid status.
This should now be fixed.
Should be fixed now.
You can restrict editing to certain namespaces by setting a right required to edit in it in Special:ManageWiki/namespaces/0 ($wgNamespaceProtection)
https://github.com/miraheze/puppet/pull/1834 did PR, feel free to close it though if we aren't doing this.
Declining per above. Will revert the current opt-in
Review in progress.
Declined per T7277#144598
The two mentioned PRs were merged, so closing task.
This is now done in extensions, just $wgWikiDiscoverUseDescriptions = true; needs to be set now. Closing as resolved since support has been implemented.
Wed, Jul 28
Some pages like https://crappygames.miraheze.org/wiki/Wild_West_Online and https://crappygames.miraheze.org/wiki/Afro_Samurai_2:_Revenge_of_Kuma still actually use the old category. Please remove it from them and reopen this task if the issue still remains. Thanks!
I think we shouldn't deploy this change globally for minimal, if any true performance improvements, which would also have negative impact on wikis' special query pages being updated less often. I don't think the community would fully appreciate a sudden change like this globally due to the impact. It seems to not have the impact I wanted when creating this task. My opinion, revert the opt-in, remove it from all current wikis, and remove the updateSpecialPages cron from puppet so it isn't being unnecessarily ran. This can be probably be reconsidered later if it is necessary but for now I don't think it is.
There seems to be no method to do this exactly how you want on Miraheze at this time. The best that could potentially be done is non case-sensitive searches it would seem. But even that I'm not certain.
Should be fixes now and the new Kartographer configs are now done as well.
I don't think there is much we can really do about this. I looked into the MirahezeMagic stuff regarding this, and it doesn't seem to be anything we could do to resolve this.
Regrettably declining this task.
Too few arguments to function Parser::__construct(), 0 passed in /srv/mediawiki/w/extensions/ApprovedRevs/includes/ApprovedRevs.php on line 628 and exactly 16 expected
This has now been deployed.
I drafted some quick JS, if this is the way we want to do this:
There are two options for this.
- 1) Make this "search" filter the current tab values or
- 2) Make the search return if the variable is available in ManageWiki, and in what section its in.
Declining per what I said above. This I don't personally feel is a good idea to do with MatomoAnalytics at the moment.
Mon, Jul 26
Currently blocked on community consensus.
I guess this wasn't moved over to the next goal period, so doing that.
I'm thinking this was meant to be closed per above. So doing that.
I drafted a bit of JS for this, using the oojs dialogs. This should be fairly good to do, with a "review" button, next to the save button, so it does not annoy users if they don't want to review them.
Sun, Jul 25
@Void: what are your thoughts about doing this?
@Reception123: any progress on reviewing the rights? I do think this should be done so we don't have unnecessary ones.
Sat, Jul 24
No response. Please re-open if you still wish this to be fixed, and if I can delete the table as mentioned above.
For most users this wouldn't be really necessary as it doesn't necessarily provide useful information about the wiki for WikiDiscover. Also, it has some negative UI impact, and not very easy to implement. Therefore, I am declining it for now at least.
I don't think this can really be done to MatomoAnalytics. Also doing so provides potential negative performance impact. Wikimedia has higher resources to allow for their API. I'm not certain doing so with MatomoAnalytics is a good idea.
I looked into ways of implementation as I mentioned above. I don't think this is worth the effort at this time. We don't have to deal with this to much right now, and Stewards can always restore it if necessary.
This should now be fixed. Sorry for the inconvenience.
Fri, Jul 23
I am looking now.
There is no Module:NavboxBuilder on Wikipedia so I'm not sure which one from there you want?
Closing as resolved since the first 3 parts are done, and the final part is quite difficult and not necessarily worth it at this time. If it is wanted enough later it can be reconsidered.
Part 3 now deployed.
The PR to change the way the submit is done, does many other improvements as well. I explained that on https://github.com/miraheze/ManageWiki/pull/281#issue-692147089.