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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 23 2024
Sep 8 2024
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.
Sep 1 2024
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.
May 5 2024
May 4 2024
Looks like there are a few upstream tickets to track related to this.
Jan 15 2024
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?
Dec 28 2023
Ooh, that's a new one... shall investigate.
Dec 21 2023
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.
Dec 17 2023
Our hacks are now versioned in rECHO
Sep 7 2023
Relevant API docs:
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.
Aug 9 2023
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).
Aug 7 2023
This blocks a whole chain of things - job queue runners, HTTPS, GlobalPreferences, etc.
Jul 29 2023
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.
May 27 2023
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.
May 21 2023
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.
Apr 18 2023
(To be filed upstream?)
Apr 4 2023
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.
Apr 2 2023
Mar 24 2023
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.
Mar 21 2023
Removed as part of the 1.35 upgrade.
Mar 10 2023
Mar 5 2023
Feb 28 2023
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?
Jan 31 2023
Thanks for the admin work. Really helpful.
Dec 26 2022
Sorry - we're not importing wikis at present (and Phabricator wouldn't be the place to request this)
Dec 7 2022
Oct 16 2022
Closing this as a WONTFIX as this task seems to be more aimed at skipping 1.35.
Jul 22 2021
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.
Special:Contact has been removed. Instead of it, you can contact staff by emailing support@shoutwiki.com.
Jul 1 2021
Apr 22 2021
Apr 7 2021
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.
Jan 26 2021
Dec 8 2020
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.
Oct 21 2020
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?
Oct 20 2020
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.
Oct 9 2020
Parsoid is now bundled with MediaWiki 1.35, as is VisualEditor. I suppose that will make it significantly easier to install.
Aug 9 2020
Aug 3 2020
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)
Aug 2 2020
Jul 17 2020
Jul 14 2020
Jul 13 2020
You need to send an email to support@shoutwiki.com with your wiki subdomain.
Jul 10 2020
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.
Jul 6 2020
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.
Jun 28 2020
Is this a side effect of the resolution to the following task: New wikis not created properly?
Jun 25 2020
I believe this should be fixed?
Jun 14 2020
Jun 12 2020
Jun 11 2020
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.