@Paladox I would like to procedurally reopen this task, and we can possibly mark it as stalled, if that's desired, as clearing one's entire cookies every 24 to 72 hours doesn't seem like a viable long term solution. Plus, we still have the recurring connection refused and connection timed out errors, which didn't occur with the previous VisualEditor-related issue to SameSite. As I think @Void mentioned elsewhere, likely in a Discord channel, I do suspect this is like due to one or two possible issues:
- Issue with the way our wiki farm manages the setting of cookies; and/or,
- Some sort of internal timeout limit with the Parsoid or RESTbase server.
Mon, Nov 23
Sat, Nov 21
Fri, Nov 20
Wed, Nov 18
@Reception123 Excellent, and even the request ID will redirect correctly, which is perhaps how these special page alias redirects work in that they incorporate any parameter specified in the special page for which they are aliasing in the redirect. For your efforts, I have awarded this, for the first time ever, the Mountain of Wealth token, rather than the usual thumbs up, cup of coffee, or haypence. :)
Sun, Nov 15
Great, @Universal_Omega. Will advise if any issues, but this was a good update rather than changing the default RC setting for everyone.
@Losira Copying my reply from Meta: Thanks for your reply. In the "Add action" box, you just need to select "Change project tags," typing "MediaWiki," and then select "Move on workboard" and select "Maintenance script run." I have done this for you this time, though, so not a problem. What the [[system administrators]] ''will'' need is for you to export an XML dump from Fandom. To do this, you need to be a <code>bureaucrat</code> on the wiki, which I assume you are, then go to Special:Statistics, and "request dump." This will generate an XML file for you to upload to the Phabricator ticket. You then need to manually download every image on your wiki, zip them up, and upload the zip file to the Phabricator ticket. Once that's in place, a system administrator will process it for you.
Fri, Nov 13
Assuming DPL is DynamicPageList, I noticed this issue yesterday on another customer wiki and @Paladox ran the trace. I'll try and post the trace results later today
Moving this to features board, but feel free to change to bugs if desired.
Thu, Nov 12
Related error, which is persistent, on metawiki related to DiscussionTools:
@John It may not be related to the recent closures, but do we know why this was inadvertently marked as closed? That's my concern. Is there some sort of activity that is not being counted correctly, such as our script only checking for Recent Changes in (Main) namespace?
Thanks, @Zppix, for reopening this ticket. I wondered if this task was appropriately closed.
Wed, Nov 11
Related error `Error contacting the Parsoid/RESTBase server: (curl error: 28) Timeout was reached`` just encountered again on community noticeboard on metawiki`. Seems to be some sort of internal limit restricting Parsoid, perhaps?
@SCVSlalom Just a general friendly tip, a best practice is to let Herald add subscribers automatically. There are some exceptions to this, when a certain system administrator's advice or review would be helpful, but just in general, let Herald take care of that.
This error has been fairly common on cp9 of late for me the past few days...
Error 503 Backend fetch failed, forwarded for REDACTED, 127.0.0.1 (Varnish XID 188680355) via cp9.miraheze.org at Tue, 10 Nov 2020 00:22:54 GMT.
@RhinosF1 Oops, sorry, we Phabricator edit conflicted.
Resolved by @Paladox on Discord
Upstream task per @RhinosF1's find is here. Re-closing this as declined. We'll have to look into what MW version this was fixed in, I think, or if Wikimedia locally deployed a patch/configuration hack to temporarily fix the issue locally. Perhaps we can replicate that, if that's the case?
Can we leave this open until investigated, possibly with a lowered priority?
@RhinosF1 Can you link the upstream task on this request? Also, I just checked this deleted revision. They're on MW 1.36, I think, yes, but I am 99.98% positive the URL displayed that way when they were in MW 1.35.
Tue, Nov 10
@Universal_Omega I could be wrong, but when I saw that @Southparkfan assigned this Phabricator ticket to you, he might have been suggesting for you to pick an extension in the queue for @Naleksuh to review, perhaps, and that, though the final approval decision of @Naleksuh as a security reviewer would rest with @Southparkfan and the Site Reliability Engineering team (who, in practice, essentially defer to Southparkfan with regard to such matters), he values your input and would give it a great deal of weight in the approval decision. On the other hand, I may have read too much into him handing off this Phabricator ticket to you, and be completely wrong, which is totally fine.
Mon, Nov 9
@Paladox Thanks...what was the issue? Can you paste the trace here for future reference purposes?
Can probably escalate this to high priority as it's a database / production error
Sun, Nov 8
Per my comments on Discord, I have no objections to raising the maximum RC length; my only quibble is with changing the default RC length, which, as I understand it, isn't changing under this proposal. This will just allow users to specify, via [[Special:Preferences]] or [[Special:GlobalPreferences]], an RC length period longer than the current default period as established on that wiki.
This should be able to be done in Special:ManageWiki/extensions, probably with either the Widgets extension or with the Timed Media Handler extension. If you need assistance with either of these extensions, you can join us on our Discord server (preferred) or, failing that, ask on community noticeboard. Hope this helps.
@Calnation This has now been fixed, except the prefix has to be simple as sw is the international standard (ISO) language code for the Swahili language. Thus, it was set up to resolve to Swahili Wikipedia, rather than Simple English Wikipedia.
Fri, Nov 6
Exact error given when using Extension:DiscussionTools is Error contacting the Parsoid/RESTBase server: (curl error: 28) Timeout was reached (link).
Mon, Nov 2
Okay, fair enough. Thanks! :)
I wonder if this is related to @Reception123 running the rebuildAll.php maintenance script this morning? I did request that to see if it could possibly resolve an unrelated problem with Special:ListGroupRights displaying incorrect information. Reception123 didn't think it likely would resolve that issue, but agreed it possibly couldn't hurt. Nevertheless my reason for saying this is I don't know how rebuildAll.php works, but I'm wondering if the way the script is currently configured, it's set to unpatrol, rather than patrol, revisions? Can we not set the script to mark all Recent Changes as patrolled? It seems to me this could well be the cause of these issues, and would make a lot more sense to configure the script to patrol, rather than mark as unpatrolled, such recent changes
Adding @John to this ticket as review and input would be much appreciated
Changing this to stalled, as that status seems appropriate, as ultimately we do want and need to implemented protection levels with Flagged Revisions as that extension was never intended to be used on every page always. It is designed to work with a protection level. If we need to use protection levels instead of restriction levels, that's fine, but we definitely need to do something.
Wed, Oct 28
@Paladox advises tracing as:
2020-10-28 16:54:27 mw4 testwiki: [40efa62fed357a2642baf5f1] /wiki/Special:Block/2A00:23C7:5601:3700:F14E:4497:B31C:3520 Error from line 340 of /srv/mediawiki/w/extensions/DiscordNotifications/DiscordNotificationsCore.php: Cannot access protected property MediaWiki\Block\DatabaseBlock::$mReason
Oct 21 2020
This gets a doubloon, but you have to share it with @Paladox, as it seems only fair. :P
Oct 20 2020
This seemed like the most appropriate token for completing this task.
Oct 19 2020
I'm personally okay with this. NetEase is a large Chinese Internet game and web portal developer (https://en.wikipedia.org/wiki/NetEase). This would be limited just to their Minecraft gaming website, and just to load forum avatars (presumably we could limit this to .jpg, .png, .gif, and maybe one other common image file format)
Thank you, @Reception123. :)
Re-opening per discussion with @Reception123 on Discord. No, they actually did update the URL to "travelguidesworld.miraheze.org," but when CreateWiki created the wiki, it used the former URL and database name of "travelguidemira.miraheze.org" and "travelguidemirawiki". Per my latest comments as a condition of approval, the wiki was to be renamed, hence why the URL was notionally updated in RequestWiki to "travelguidesworld.miraheze.org." But if you'll check his CentralAuth, the URL is still showing as "travelguidemira.miraheze.org" and the database name as "travelguidemirawiki". Thanks.
Triaging as normal for now.
@CircleyDoesExtracter Can you clarify this just a bit more, Noting that Geoshea's profile is showing as "create source," has Geoshea and Cuddly Rainbow Guardian recreated their profiles on Circleyverse wiki since it was deleted and recreated? If not, since the page titles are the same as before, I'm wondering if this might a caching issue, with the old pages still cached on our cache proxies?
Oct 18 2020
@Naleksuh may be interested in following this ticket
Oct 14 2020
Oct 13 2020
Oct 9 2020
Oct 3 2020
@Reception123 Just giving you a courtesy ping to this request and also to note the important note at the top. Pine/Matsu and Lois are active in translating, and I'm eager to prepare our TestWiki policy pages for translation, so they can start doing that, but rather wait until this cleanup is done.
Oct 2 2020
Updating status for @Universal_Omega now that it's back on the board pending a review, as time permits.
@Universal_Omega Thanks. Yeah, I realize that you wouldn't necessarily review all Wikimedia wikis' Special:Version pages to see if it's installed, but I do wonder how up-to-date all the pages on MediaWiki.org are kept, especially for smaller extensions. I'll try and do some digging. At any rate, if this isn't used by a Wikimedia wiki, then yeah, I do appreciate you being willing to consider giving this extension a security review, time permitting. Don't feel like you need to complete the security review in a given timeframe. Historically, security reviews can take months, so if this took a few weeks to a month before you got to it, that'd be no big deal.
@Universal_Omega I'm not sure if we should decline this so quickly. Is this not an extension used by one or more Wikimedia project wikis? The fact that it hasn't had recent commits may not, in and of itself, indicate the extension's maintenance status is necessarily problematic. For example, some simple extensions are so simple, they don't regular maintenance or updates; they just work and are compatible with the core MediaWiki software. Looking through the approved extensions we have on Miraheze, we have had quite a few "beta" and "experimental" extensions approved, so I think this is may be at least worthy of a security review, if I'm being perfectly honest. So I'm bumping this thread, to have a second look be taken, as I just want to make sure we're not rapidly closing tasks in an attempt to triage and manage Phabricator.
@Universal_Omega Noting @Void's comment in [[T3900#76880]], it seems like the decline was solely related to a service or submodule that we were missing, so perhaps we should investigate if we now have this submodule or service? Perhaps this was originally declined prior to Miraheze's upgrade to MediaWiki 1.34, so we may now have the required dependencies.
Sep 25 2020
I guess I can't award another token, so I will just say thanks @John. :)
@Reception123 @Krisrs1128 I just tested this on TestWiki by setting TestWiki:Request permissions to the Mainpage in MediaWiki:Mainpage. Initially, the wiki still loaded Main Page; however, on purge-ing the page cache at both /wiki/ and /wiki/Main Page, I was able to get TestWiki:Request permissions to load as the main page. You can verify this by clicking on the Public Test Wiki logo.
@Reception123 I think a MediaWiki hard redirect to the Main Page is sub-optimal in this situation. I thought the whole point of MediaWiki:Mainpage was to specify a page title that represented the wiki's main page, no? If that's not working, then we may have a systemic configuration issue, I think.