Fri, Jul 31
I don't have anything to add, really, to this task, but noticed it with interest. As a workaround to this, I've been using the Navigation Popups gadget (on Meta), and recently got it working on Public Test Wiki (was missing a few configuration files). So, other than for previews of special pages, it will show previews of pages when you hover the links in any namespace. It isn't a particularly difficult gadget to set up, either. If you have the Reference Previews enabled, though, I know English Wikipedia does advise disabling that as it conflicts with the Navigation Popups gadget.
@RhinosF1 Okay, thanks for volunteering. Are you just going to write a quick script to mass patrol the revisions within the given time parameters (on Meta)?
Thu, Jul 30
@John Well, many Mirahezians don't really understand how patrolled revisions even work, so they likely aren't aware this is even a problem. They may not even be patrolling revisions.
@Reception123 When was this added? Nevertheless, I was searching by its common name of Page Curation or PageCuration (as on English Wikipedia where it is chiefly, or exclusively, used, rather than its official name on MediaWiki.org. Either name is fine, but am just so used to calling it by its common name.
@John, since this was related to a reported system incident, I think we should still try and resolve this. @RhinosF1 had another idea, aside from my idea to manually patrol all revisions to a specific date, that was discussed on Discord, but can't remember the gist of the idea. Could we explore that idea, or, failing that, run either a seven day community discussion on the community noticeboard or a thirty day RfC to build community support for doing this?
@Reception123 Did I add `HIDDENCAT`` to `[[Category:Hidden categories]]`, on **//both//** wikis? Looking at the [[Category:Miraheze]] top-level category on Meta, the problem does seem to be resolved; haven't confirmed with Public Test Wiki, but will check later and take your word for it. Apologies for my error, if it was me, though, in fairness, I did see `__HIDDENCAT__`` added to other system hidden categories on those wikis. Good to know it was a user error and not a Miraheze-specific configuration issue. :P
Wed, Jul 29
@RhinosF1 My concern is that the user doesn't realize he's made a mess of things, and may need a system administrator to just intervene. He originally requested deletion of the pages, and with him having done the mass conversion, albeit malformed one, of the extension's namespace, that should be confirmation enough for you to revert his ManageWiki settings change, I think, and delete the pages properly. I'm just concerned because of all the configuration problems on that wiki. Can you either (a) follow up with him and get explicit confirmation to revert his ManageWiki settings change and mass delete the pages prefixed by Thread: or (b) revert his ManageWiki settings change and mass delete the pages prefixed by Thread://, taking his ManageWiki settings change as an implicit// confirmation? Given the configuration problem with Special:Log, this needs rectification, and shouldn't be left even if the user thinks everything is A-OK.
The user followed up by saying they modified, or created, a namespace, and thinks they've deleted the pages. However, I don't think that's what happened. You can see their modification here, but there's no record in the deletion or move logs of those pages having been either (a) deleted or (b) moved. While the pages no longer show up in Special:AllPages, if you try visiting one of the thread pages (not the corresponding talk page for the thread page), you get a bad title error (likely owing to the conflict with the newly-created namespace). As is somewhat expected, the user didn't read, completely, everything I wrote, and rushed into trying to create or modify a new namespace.
I forgot I suggested enabling this on Meta...is this even available in Special:ManageWiki/extensions yet? It's on the GitHub list of enabled extensions, but I don't see it. Supposedly, that GitHub list is the most up-to-date list of enabled extensions, but I've seen extensions in that list that aren't in Special:ManageWiki/extensions. Nevertheless, I will try and post a community discussion for formality purposes, stating this extension can be enabled after seven (7) calendar days based on the arguments presented (if any) or, seeing no responses, taken as no opposition.
Fri, Jul 24
@RhinosF1 and @Reception123, do we know this problem occurs on non-Miraheze wikis, though? English Wikipedia automatically marks all the revisions, other than new pages, of autoconfirmed users as patrolled, so we won't be able to check that there. A good place to potentially check on this might be Wikimedia's Meta Wiki, if we know any former administrators who no longer have `autopatrolled``` status.
@RhinosF1 Yeah, it's probably my second choice, but I'd support us mass marking all unpatrolled revisions on the affected wikis up to the point of the redis-server incident as patrolled. It's better than leaving them unpatrolled, and no one wants to manually repatrol years worth of old revisions.
Mon, Jul 20
@AmandaCath I wasn't sure whether it was a MediaWiki bug (or rather, Miraheze's deployed version of MediaWiki) or a problem with an extension (i.e., FlaggedRevs, but I think that's the extension that Wikipedia uses for Special:PendingChanges and is commonly not installed on most wikis, right?).
Replying to @RhinosF1's question on Phabricator, to update everyone here of our Discord conversation...I'm going to manually check a handful of the wikis affected to see if it affects more than just Meta. Just need @Paladox to re-open Paste P332.
@RhinosF1, I can't remember if I created my Miraheze Phabricator account directly, using OAuth and my MediaWiki login, or my GitHub login, but whether I registered with my GitHub login or not, I have been logging in with the "Login with GitHub login" option. I've checked my authorized applications on GitHub and Miraheze Phabricator is not revoked. Not sure if this helps with diagnosing where the configuration problem is or not, but hopefully it will.
This was the specific error message returned when trying to create a wiki:
Thu, Jul 16
I know this doesn't follow our normal bug report format, but hopefully there's enough detail in here to trace it down and what, if any, action needs to be taken.
Sat, Jul 11
@Paladox What web browser are you using, and what are your settings set to in Special:Preferences or Special:GlobalPreferences? It may make a difference whether you've enabled, or disabled, the new wikitext editor in your preferences. Frances Amadar and I can definitely produce this error on multiple wikis.
Minor edit to give props to @Paladox for fixing.
Fri, Jul 10
Jun 30 2020
Wait, how do I award that token to @Paladox for his speedy fix? :P
Jun 22 2020
Jun 9 2020
Jun 7 2020
I was just reading the Extensions page on Meta, and noticed that it said to rely on the GitHub /mediawiki/extensions/ tree as the most up-to-date listing of installed Extensions. There, I saw that PageTriage is listed, so not sure if that means it's installed or in progress, but just thought I'd to this ticket.
Interesting...hadn't heard of the FlaggedRevs extension. Yeah, agree that it's similar. FlaggedRevs isn't enabled on Meta, though, is it? Know any wikis it's installed on so I can test that?