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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 14 2020
Jun 12 2020
Jun 11 2020
Jun 10 2020
It looks like it fixed itself.
Jun 9 2020
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?
Could not reproduce, no indication of continued issue
Chirp upgraded, Vertex decommissioned
Vertex decommissioned and replaced by Utter.
May 19 2020
Current blocker/extensive consideration required: T273
May 4 2020
May 3 2020
As this is bundled with MediaWiki by default now, I don't see any huge issue with enabling it globally - we'll probably roll this with MediaWiki 1.34
Got the same just now. Does that mean that there is no way to create a wiki for a unforeseen time?
May 2 2020
Got the same just now. Does that mean that there is no way to create a wiki for a unforeseen time?
May 1 2020
Apr 29 2020
Apr 25 2020
It is entirely intentional. Language subdomains are a blocker for our HTTPS rollout, so we're actively removing the ability to create new ones and are in the process of clearing up as many of them as we can. When we get a better idea of how many we need to keep, further details will be provided to existing wikis.
Apr 24 2020
Feb 12 2020
BTW, there appears to be no such thing as a #security tag in this phabricator ....
Feb 7 2020
Jan 19 2020
I remember getting a similar error. I think this is - at least partly - because page imports are currently disabled (they were apparently being abused, so they're working on a new, more manageable system, last I heard).
Jan 16 2020
I remember getting a similar error. I think this is - at least partly - because page imports are currently disabled (they were apparently being abused, so they're working on a new, more manageable system, last I heard).
Jan 13 2020
The extension is unmaintained upstream, and we'll be dropping it as soon as it causes a security issue or no longer works.
Jan 12 2020
Jan 6 2020
Dec 30 2019
Dec 26 2019
Fixed this hours before I saw this ticket...
Dec 14 2019
Nov 17 2019
Oct 10 2019
Sep 20 2019
Aug 11 2019
Jul 31 2019
Jul 29 2019
Okay, this rather harsh and unfriendly communication from a staff member already painted a bad picture. Now, we have this, which is totally unacceptable and amounts to global users with "superpowers" overriding a local community/admin action. That's two strikes. One more and I leave. This is not the behavior that I expect from the staff team from a service like this.
But... while all RevDel leaves a trace, there are two levels of RevDel. The "lower level" can be restored by anyone with the deletionrevision right, which by default is assigned to the sysop group (as on Wikipedia). The "second level" can only be restored or viewed by users with the suppressrevision right, which is what the WP:OS is.
No. Oversight is the group that remains at Wikipedia assigned the RevDel permissions. Oversight was an extension that used to leave no trace that was replaced by RevDel. All RevDel now leaves a trace and can be restored, all this information is on the WP:OS page you linked - however, this does not matter as we are not granting that right to users.
I'm sorry, but they are not the same thing.
They're the same thing. They use the same feature. We're not giving out rights to them, and we won't be "cleaning up" logs and history in future, unless there's a leak of personal information or libel as stated in the system message for RevisionDelete.
@jack thanks for the response.
ShoutWiki is indeed not consensus-operated and individual wikis' settings generally speaking need consensus only from the existing community (if any); "global consensus" just isn't something that's a thing over here.
Jul 27 2019
@jack bump!
Jul 25 2019
Been deployed for a number of months now with no issues.
So I played around with a few headers today, after giving Varnish most of Utter's RAM to play with. Pages at /wiki/ are currently cached for 10 minutes (we ought to maybe change this to be a little more namespace specific and/or exclude Special: pages?) and images for a month.
Jul 24 2019
Utter is now serving requests on all ShoutWiki sites. Will close task assuming no issues reported within the next few days.