This is a blocker for 1.39. The software cares more than ever about load order and the handling upsets a lot of internal MediaWiki systems.

It's built off $wgServer - which we updated for all wikis. However, it seems not Hub, as Hub's settings file was handwritten and has a non-standard indentation, so the find/replace didn't catch it.

Skizzerz has a nice little extension that uses debounce.io - a premium service with a minimal free tier that does disposable checks but also screens non-disposable domains to determine if bounces are likely.

Looks like there are a few upstream tickets to track related to this.

The current suspect is the query cache - we've seen far better results on bark than bellow though, perhaps due to better availability or lower cache?

Ooh, that's a new one... shall investigate.

I believe this should be resolved (as of ~20 hours ago, but you wouldn't know due to another issue) - apologies; forgot to pull the Composer dependencies on the new server.

Our hacks are now versioned in rECHO

Relevant API docs:

• Google Search Console
• Bing/Microsoft

My thinking for an implementation is to write this to hand off each of these to the job queue and have it fire these off whenever. Probably one job per search engine, as there will be auth tokens etc involved.

We've implemented a general set of functions so far that form the base of what this task requested. Closing this as resolved and further features can be added when needed or requested using the SWLib project tag.

Uhh. Deployed as of the end of the Wikimedia Hackathon 2022. Create any follow up issues as child tasks of this (unsupported skins etc).

This blocks a whole chain of things - job queue runners, HTTPS, GlobalPreferences, etc.

The Foundation's PHP jobrunner works and will be our go-to solution for the time being (we don't have the scale to implement the Foundation's current setup) - but, currently blocked by language subdomains. T332

Bellow was upgraded in March.

Resolved - I think?

Certificate issued for .shoutwiki.com - pending tweaks to global and individual settings to ensure everything is serving from the correct protocol.

I don't think this is something we actively want to support. In this instance, I'd suggest using one of the various webfont services, as it'll provide better support for the various browser/system combos and probably better load times.

So you're getting this on *.shoutwiki.com sites, but, not Hub or custom domain sites? That's a little odd.

Configuration changes require a support ticket. When you file that, please specify the actual user rights you want, not... whatever that is. Also - any config changes to inactive wikis will get blanked declined.

File a support ticket.

Pretty poor at taking notes in conversations I'm a part of in-person - Roan is going to file his own thoughts on (the upstream) ticket.

(To be filed upstream?)

Please file a support ticket for the config changes and I'll have a look at it next time I'm running through the queue.

Closing in place of your support ticket. tl;dr - it isn't a bug. It's a cookie or session getting stuck in your browser.

Removed as part of the 1.35 upgrade.

I expect it's the frontend cache and/or SSL terminator incorrectly handling the forwarded headers. We were still very much testing that and the mobile detection in the frontend at this time. Haven't seen a reoccurrence recently, closing until it needs reopening?

Thanks for the admin work. Really helpful.

Sorry - we're not importing wikis at present (and Phabricator wouldn't be the place to request this)

Closing this as a WONTFIX as this task seems to be more aimed at skipping 1.35.

So this cropped up a couple more times - primarily around monthly archiving before the cleanup. Ran into it again as dailies finally started being big enough to push us over that edge.

In T308#4613, @--miki-- wrote:

Special:Contact has been removed. Instead of it, you can contact staff by emailing support@shoutwiki.com.

A monthly cron is now run on the second day of every month to delete monthly backups older than a specified amount, currently set to 120 days. This regained approximately 180 GB of disk space on the manual run. This is currently called "monthlyBackupCleanup" pending commit to the repository and rework as a ... more robust script.

Update: Root cause is tracked down, we think it's fixed (confirmation of that at a later point, currently isolated so it won't do any harm until then) and we've liberated as much data as we can from the void.

In T298#4477, @Saftzie wrote:

So even the current revision of the article does not exist, although the article itself still does.

Is it time to lock the database yet? When was the last backup?

Merged these in because they're all the same underlying cause which is some sort of botched revision (MediaWiki internals "recently" had a huge overhaul) which is causing it to freak itself out a little. We highly suspect the culprit is CreateWiki, however, at this time a cause and fix is proving difficult to pin down.

In T142#4435, @--miki-- wrote:

Parsoid is now bundled with MediaWiki 1.35, as is VisualEditor. I suppose that will make it significantly easier to install.

So, for further information, I've hacked the automysqlbackup script to use pigz (it is enabled in the more recent version which seems to be buggy and also isn't provided by package - making life... more interesting)

You need to send an email to support@shoutwiki.com with your wiki subdomain.

In T288#4356, @dylan.west wrote:

Now I see the "CreateWiki disabled until 1.34.x release is stabilised - see here..." message. Should I be seeing this?

Completely forgot "normal users" don't just bypass the throttle check. My bad.

In T287#4341, @bergmann.lat wrote:

I think Rose-Biblio is one of the largest wikis in shoutwiki and you must earn some money with it by advertisement on my sites. Spending "a few hours" could be a little bit more! Working with singleupload is not acceptable for my needs.

Is this a side effect of the resolution to the following task: New wikis not created properly?

I believe this should be fixed?

Jack cleaned up the affected wikis, and I've turned off CreateWiki (ish) for the time being. New wikis before we get back to 1.34 are going to cause more issues than its worth.