Profile picture is CC0.
Hm, something I thought of when suggesting this on another wiki farm was to make the signature global, but only if "use wikitext" wasn't checked. Maybe that would help here?
It works fine on Firefox because they fixed it (https://bugzilla.mozilla.org/show_bug.cgi?id=1510862), so its just Chrome, which is still a lot of users. Also, I believe the patch was only intended to be done temporarily until browsers patched it, which Chrome still hasn't done.
$wgFlaggedRevsNamespaces is seemingly at fault
Probably means we need to drop $wgFlaggedRevsNamespaces from the top of the file
However note that in the event that your browser can't support TLS v1.3, you won't be able to view the page at all
Hey, my browser supports it, because I did these steps:
- visit chrome://flags/#tls13-variant
- select one of the "Enabled" options
Yeah I checked, but it seems that I wasn’t BCCed? Unless the headers/my clients don’t show BCC I guess.
@Reedy that might be a good idea, since I'm now getting email that's being spoofed (eg, it says it's to email@example.com but I somehow got the email).
It looks like the content is blacked out via site css, maybe due to the protest about Article 11 and Article 13 happening today?
If this isn't going to be changed/fixed in core MW, then the preference label should be changed from "Prompt me when entering a blank edit summary" to something like "Prompt me when entering a blank edit summary (excluding undo)".
"(This loads the base style for the watchlist. Please do not disable this option.)" in enwiki's gadgets is probably a good candidate for moving into the codebase too.
That only shows up when creating an account.
Isn't $wmf* better than $wgWMF tho?
That depends. The Config abstraction layer in MediaWiki maps logical names (e.g. "ArticlePath") to a global named $wgArticlePath. If we used "wgWMF", these variables could (in the future) be managed through the same system, interacting with $wgWmfRealm as "WmfRealm".
Anyway, that's a later step. We can at least standardise first on one of the two patterns we already use (wmf* -> wmg*).
I could reproduce for a minute but then it worked. It's because that file is large.
So i would call that expected behaviour. Just need to wait for it to open :)
huh, now its happening again on https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/443881/2
@TerraCodes The ones we've seen for the recent blackout, as I was saying. Itwiki had more ore less three days to decide for a blackout, and there has been some uncertainties until one hour before the effective blackout. Other wikis have had even less time, and in order not to be late they opened short polls (we're talking of a matter of hours, not days), for instance cawiki. Some wikis actually ended up with nothing done because of not enough time left to vote, for instance elwiki. In such a situation, where time is really crucial and should be spent in reaching consensus, communities should have a quick way to enforce their decision. At any rate, this is the classical situation that you can't actually foresee, and for which we need to be ready, no matter how rare such situation could be.
Tho I'm suddenly unable to reproduce this now?
What emergency situation(s) would require a blackout of a whole wiki?
Actually it can be something like:
Re-introduce superlock which locks these css and js pages.
Let those pages be edited by the staff usergroup only, or whatever.
Can "Deployment servers" be checked off since the two tasks next to it are resolved?
Was this the vandal that changed the names of tasks into gibberish? And unsubscribed AKlapper?
Just for a note, why not add a button at Phabricator to enable reverting to an earlier state?
maybe also round up MinimalPasswordLength from 8 to 10?
Kinda interesting that they base64 encoded a page and used that as their comment on tasks.
I explained in T191182#4103647 why I think this is wrong. So I am reopening this task. If Differential has no future in Wikimedia development then projects should get migrated and it should be turned off. Leaving yet another lingering system around just adds to technical debt, confusion, fragmentation.
I think this might have been mentioned above, but JS/CSS review would also be a good idea to add. Might also be a good time to go through all of the css and js pages and see if anything can be removed or added to the core.
@MarcoAurelio is your on-wiki count still at two, or has it changed?
whoops, not decommissioned yet
Since the tasks are marked as done, I think these servers are able to be checked off.
Looks like its an issue with the site, rather than this extension, because when I looked in my console, I found this error:
I suggest we either prevent users exceeding the number of edits set in const EDITCOUNT_THRESHOLD = 100000; to request a rename using the form
Then whats stopping them from using the wiki page(s)?
prevent stewards/global renamers to perform them using the Queue.
Wouldn't that make it so that then the rename couldn't be done when there's a sysadmin around to do it?