The error can still be reproduced, you just have to set RecentChanges longer than 7 days.

Ah, okay. It was so quiet in the other tickets about fixing the current issue that I assumed nothing had been done. Closing as resolved.

Interesting stacktrace. You can tell what happened is that there were pages named Draft:_Foo before a namespace was added, but then when the Draft: namespace was added, the page is interpreted as a page named _Foo in the Draft NS. And nothing is supposed to begin with a space/underscore. It might be fixable by renaming the page, but since it's RecentChanges being broken, I wonder if it would continue to be broken after renaming for seven days.

That's really disappointing. I understand that incidents happen, and a lot of things are out of our control once it's started. But there were no actions identified to take in the future, which means Miraheze learned nothing from a week of partial downtime. I am now significantly more worried about the future of Miraheze than I was when I was getting 503 errors half of the time.

Everything works perfectly now, thanks for fixing!

Took me over a minute for an OAuth token to log in here. The wiki is seriously slow, if it works at all.

In testing, I set a custom policy on this page. If it's already covered by the namespace protection, how would I remove the custom policy? Set it to "everyone can access" to restrict it to administrators?

Okay, granted admin for a week. Good luck.

@Reception123 Going to the wiki shows

User account "Reception321" is not registered.

Yeah, let's try for then. Hopefully they'll give me something other than searching the whole document for <h2> tags at the end.

I do not believe it will break things. I thought I commented in some thread that they did not replace the hook with anything equivalent functionality; the proposed workaround is not yet implemented in Mediawiki or the skins -- except Skin:Minerva and we don't want to force everyone onto mobile. There's nothing wrong with using a deprecated hook, so I'd suggest going forward with this extension until equivalent functionality is available, or the hook is removed.

Thanks! Great work.

Fair enough. I've talked to another user and we were both confused on how this works; maybe it's just us. If this comes up again, we might want to implement the suggestion, but otherwise closing this request.

Yeah, just noticed. I guess this closes my first request, but it's kind of up to you guys if you think it would be good as default. I think it would be mostly harmless.

It doesn't really matter because security review took all of two minutes, this is a tiny extension that adds some CSS and simple JS.

Approved, bought a OVH Rise-1. This may be a little overkill for a file server, I'd like to see other services moved here too, at the very least the lizard master.

Approved by me, fairly simple extension, though somewhat overdesigned. FontAwesome itself is a really widely deployed package, so I didn't need to audit that portion. People much smarter than me have already looked.

I set up the payment agreement, so the charge should be taken automatically from Paypal.

Seems worthwhile to me. ES can consume a lot of resources.

Minor note: at least I got them to update their docs on sub accounts: https://www.name.com/support/articles/205934117-Creating-a-Sub-Account

until next year.

Unfortunately, I no longer have access to the name.com account that hosts our domain names. It appears that someone turned on 2FA, which means that I cannot access the sub account. I tried to talk to support, but they basically said no, because the account is in your name. If you'd like me to pay it, please disable 2FA or send me the code to access by google authenticator @Southparkfan

Crowncloud is cheap but the ToS worries me a bit. Get two DMCA takedowns, your account is terminated immediately. Host any content that educates about piracy, your account is terminated immediately. (???) For backups they're probably fine, but for any other service I'd start to worry. From their ToS, I think their business model is cheap because it's based on shutdown first, ask questions later.

More RAM for Redis sounds good. Approved.

Yes. Not permitted is the set of content ("erotic", "pornographic", extremist", "not deemed in good taste"). Therefore pornographic material is expressly prohibited, as are erotic writing and tasteless jokes.

The placement of erotic, pornographic, extremist material or material not deemed in good taste is not permitted.

I'm pretty okay with this idea. If this works out, we may want to move all of the file storage to another DC, so we don't get too much replication traffic. But static data would be fine to keep in another DC.

Encryption is one thing, but I meant bad from a performance point of view. It shouldn't take less time to round trip through your database than your cache. You want to put cache as close as you can to your application servers. Possibly even with read-only replicas running on the mw servers, if you can spare the memory.

Wait, if misc2 runs Redis, does that mean that our cache will be in a different DC than our app servers? This seems like a questionable idea.

I'm not sure at what level funds are lacking -- last I heard we were trying to buy a CVZ and RN NL didn't have one available. What sort of server are we looking at to resolve this?

Give it a shot. The current searches don't work well, either.

Sorry I've been somewhat jet lagged. Let's go ahead and do this.

All paid up now. Waiting for final transfer.

Initiated the domain transfer. Revi, you need to tell me how much we owe you. Can I get you the money by Paypal, or is there some other way you'd like?

I'm not really sure that we could install this. It needs a secret key, and we don't really have any provision to store per-wiki secret keys secretly. LocalSettings is a public file. So enabling this extension would be equivalent to allowing arbitrary HTML, with an additional security by obscurity layer.

I was waiting until we got to 60 days so we got a full extra year of renewal when I transfer the domain. And...

Retroactively approved. This is really my fault as I should be able to just give you a budget, and as long as you stay within it, everything should be fine. I did a budget last year, but no one ever looked at it, so I slacked this year.

If content was ever available under 3.0, it is always available under 3.0 until the copyright term expires. You should be able to continue to export content.

If John was going to steal Miraheze, he would have done it a long time ago, lol. But seriously, I don't really use the upgrade power, because I'm not really a sysadmin, that's only because I need to be able to get in and pay the bills.

Sure, I'm just going to authorize a net increase of $5 per month here, because I'm not really sure what you're planning to do. Tech:Cp4 has two different numbers, lol. Not really in a position to say which concern wins out, reliability or having less servers to maintain.

So we're better off than when we started the task, so we have a bit of time to discuss here.

Verified that a user emailed us this database, and that Miraheze did not use any form of scraper to retrieve this data. As such, there is no reason to halt this request at this time.

Nope, they don't allow it. That's why I disabled Extension:DonateBoxInSidebar.

IP address can be PII too, especially when tied to a user account. You'd have to get all IPs recorded for all edits from that user. And a list of all edits made by that user -- honestly not sure if we'd have to include the revision text or not.

I've read the GDPR, and found nothing that suggests this to be true. Closing as invalid.

Just FYI I'm reading the GDPR now.
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN

Approved. Go ahead and purchase it.

I'd assume that we try to move into compliance on our own first. It reduces billable hours.

No opinions in particular. I've heard of the GDPR, but I don't really know what, if anything, we'd need to do to come into compliance.

Maybe I need to find another way for people to pay first. But yeah, I noticed the large chunk of server cost this month, too.

I would like to know what I'm approving first, thanks. Is this 1GB SVZS to 2GB SVZS?

Sent a message upstream, looks like it's a corporate-managed git, so I sent an email to their security address.

Security review failed. I kind of feel bad because it would be the most obvious XSS to any admin, because people would probably notice a page title named Foo" onload="alert('hax!');, but so it goes. The whole extension could stand to be rewritten using the mediawiki Html class.

Extension looks good to me. Nothing to complain about, all modern looking code with appropriate stripping. Security approved.

Yes. Mainly I just didn't want to verify it worked, but I noticed that the issue I opened a long time ago closed.

Oh yeah, very simple. Security approved, go ahead and install.

Someone needs to run refreshLinks.php on allthetropeswiki. I would, but I've lost my sysadmin bit recently.

This is a WMF extension, and therefore bypasses the security review. I assume the Maps service is subject to the same privacy policy as is normal for WMF projects, so we don't really have issues with that, either. It's just a matter of installation and configuration, now.

Well, on-wiki kinda counts for me, as managing finances are a decent part of my contributions here. But not from an ops standpoint.

Approved by me.

Talked to Namecheap support. They said it wouldn't be possible for me to transfer funds into that account. While I can pay bills for the current domain, I can't add money to the account.

Remind me again why needing 2x more RAM counts as a software upgrade.

Note that the security review was already approved in T2247, so really what we need here is a sysadmin review, as to whether we can handle the additional queries.

Yes. The extension is almost misnamed, except for the function it serves. It can put literally anything in the sidebar, so long as you have access to the config files.

Yeah, approved. 16GB VDS looks like a good deal for us without changing too much on the billing side either. There's enough money in the RamNode balance to make the purchase, so go ahead whenever you're ready.

Note this extension creates three tables, so we probably want to push install until after we get a new db server set up.

It looks like @Samwilson's PR was merged, so we can go ahead and install this.

Extension:CustomSidebar is declined. There have been like 3 reports that it hasn't worked since at least Mediawiki 1.27, so I'm pretty sure it wouldn't work on Miraheze. That said, if anyone wants to make a git repo and update it, I'd be happy to entertain the extension. What there is looks safe enough. I'm sure it could be improved, as this is a slightly scary line:

Actually deferrable updates are not the job queue, it happens at the end of each request. https://www.mediawiki.org/wiki/Manual:Job_queue/For_developers Hm. Maybe a feature request for E:HitCounters would be in order.

Extension:TopTenPages is approved. However, it's not gonna work without Extension:HitCounters. This was originally WMF written, so the code is still in great shape. So this extension is approved as well, from a security point of view.

First of all, I really need to congratulate this extension's idea of security:

Ugh really are we asking me to review a Flash widget? It's a little hard to security review a binary, but I guess the PHP looks fine.

They're asking for renewal for this month, so are we going to use them or should I drop the service?