I found it as well, but it's different from the requested logo. I'm happy to use that svg, but I'm not sure whether that is desired.
@MF-Warburg I'd like to also ask for a SVG version of the logo. https://upload.wikimedia.org/wikipedia/commons/3/32/Wikipedia-logo-v2-skr.png cannot be used, because it is a) too small (the minimum is 270px * 310px, and we strongly prefer a SVG version) b) it doesn't have transparent background (so the logo would have a white background in the browser). Compare https://en.wikipedia.org/static/images/project-logos/cswiki.png and https://upload.wikimedia.org/wikipedia/commons/3/32/Wikipedia-logo-v2-skr.png in a google chrome (or any other browser that signalizes transparent background).
@MF-Warburg According to WMF Board's licensing policy (https://foundation.wikimedia.org/wiki/Resolution:Licensing_policy), any project with local uploads enabled needs to have an exemption doctrine policy, that describes under which conditions can non-free media be uploaded. Can you please link that policy as well (prepared either at incubator or meta), so we can review it?
I'll prepare initial config.
I'll prepare initial config.
Tue, Nov 24
Mon, Nov 23
@jrbs Hello, it just needs to be purged. Given votewiki is edited so infrequently, the automatic purge does not happen immediately. I made a null edit, and it's fixed.
Sun, Nov 22
Sat, Nov 21
Fri, Nov 20
Sorry @Krinkle, but reopening again. The test case mentioned in my reopening comment: https://cs.wikipedia.org/w/index.php?title=Wikipedista:Martin_Urbanec/P%C3%ADskovi%C5%A1t%C4%9B/3&oldid=19177452, is still broken. Both images exist at Commons, and none displays. Purging did not help.
Thu, Nov 19
I do not think that this got fixed completely, see https://cs.wikipedia.org/w/index.php?title=Wikipedista:Martin_Urbanec/P%C3%ADskovi%C5%A1t%C4%9B/3&oldid=19177452. It's a recently moved file, but it sounds very similar to this one. Reopening.
Wed, Nov 18
Possibly, I closed (and auto-claimed, which caused project to be auto-added by herald), and you then set the assignee to yourself. Anyway, no problem :).
(adding my personal project back so I can easily look up tasks that are important for me in the future)
I enabled the extension at metawiki beta. It will take a while to propagate, but it should work. Please reopen if it doesn't.
Did a second HTCP purge after Puppet propagated it everywhere, and it seems to work:
This is not within Operations scope. T&S should either grant themselves, or post a request at the steward request page.
Tue, Nov 17
Note it is not possible to create an account using an username that was in use previously. If user:Foo gets renamed to User:Bar, no one (but administrators) can register User:Foo. It was possible for a long time, and it is a relatively recent change, but it's not possible today.
Mon, Nov 16
Hey @Borislav, as you're still logged in, could you make an edit referencing this task, to confirm its authenticity? Thanks, Martin
We could, but people having the gadget enabled globally (via global.js) would have two links, which is not easily avoidable at this point. The best thing would be to fix the issue itself, and I created T267925 for that. I can look into that later today I guess.
Hello @patilise, thanks for creating this task! AFAICS, the sidebar link is inserted in onSidebarBeforeOutput. There's an if that short-circuits the hook, which requires $wgUrlShortenerReadOnly || !$wgUrlShortenerEnableSidebar to be false in order to insert the link. However, in Wikimedia production, wgUrlShortenerReadOnly is true at all wikis but metawiki (that is to make sure throttling works). For that reason, merely setting $wgUrlShortenerEnableSidebar to true would not help, given the sidebar link would display only at metawiki.
Sun, Nov 15
Stated rename got processed by the system. Note the job queue has variable speed, the more jobs MediaWiki submits, the slower renamings get. Give it some time to stabilize, please. If it won't fix itself after few days, please open a new task.
Happy to hear that @Yerpo
Well this one was easy, the account was created by Yerpo themselves, and apparently is a bot account operated by Yerpo.
Looking into this
Sat, Nov 14
Thanks for your prompt fix, as always :).
Fri, Nov 13
Fixed. Some images had a fix URL starting with new-web.wordpress.wikimedia.cz. Replaced that with wordpress.wikimedia.cz, which will always be accessible.
Thu, Nov 12
Thanks @Krinkle and everyone else who was involved in this!
That's because @Gilles did some logos optimization in T252108. As part of the optimization, the optimization part changed from plain optipng -o7 to a different set of commands, see https://wikitech.wikimedia.org/wiki/Wikimedia_site_requests#Change_the_logo_of_a_Wikimedia_wiki. It seems that this issue got introduced exactly because of the optimization, see T252108#6541194 for details. @Gilles Could you please have a look and investigate whether that is the issue?
@DannyS712 You already seem to be in #wikimedia-security. Feel free to join :-).
So, I just noticed this issue while debugging why I cannot log in to a newly-added wiki to WMCZ's wikifarm. The reason is that the actor table at the new wiki is empty, which makes User::newFromName() return an invalid user object.
Certified from my side, as I failed to spot anything else.
The redirect works fine for me - closing as resolved.