User Details
- User Since
- May 31 2014, 9:14 PM (511 w, 2 d)
- Roles
- Administrator
- MediaWiki User
- Lcawte [ Global Accounts ]
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.
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
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
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
Completely forgot "normal users" don't just bypass the throttle check. My bad.
Jul 6 2020
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.
Jun 1 2020
May 26 2020
So we now run a find command which pipes to xargs to delete directories under /path/to/settings/deleted that haven't been modified in 30 days. This gives us enough time to hopefully notice we've deleted the wrong wiki or for someone to appeal a deletion (not that we have a formal appeals process) while not hoarding deleted wikis forever.
So this turned out to be surprisingly difficult to actually fix. For some reason, the server keeps throwing me either old or 503ing CSS...
No longer deployed in favour of SemanticBundle.
No longer deployed in favour of SemanticBundle.
@jack Did this ever get fixed?