Have you heard ? I'm not part of WMF, never have been.
- Open Source dev since 2001
- Wikipedian since 2005
- Wikipedia admin 2008-2019
- Commons admin 2010-2015
- MediaWiki dev (+2) since 2009
Uses Safari most of the time (because someone has to)
Have you heard ? I'm not part of WMF, never have been.
Uses Safari most of the time (because someone has to)
In T358738#9640913, @seav wrote:Is there a way to use your shell trick to determine which images would need purging?
mass message is now ooui and wikilove is codex/vue
I think we can call this resolved.
It seems codfw is now also in sync. Still kinda curious why there is no last-modified header on some of these responses now.
ping @akosiaris Ideas on why codfw is out of date and won't correct ? Is it out of rotation or something ?
K. I included the 3888px width size in my own page, then purged the image with action=purge. Now most centers seems up to date except for codfw
for d in codfw drmrs eqiad eqsin esams ulsfo; do echo -n $d: ; curl -sI --resolve upload.wikimedia.org:443:$(host -t a upload-lb.$d.wikimedia.org | awk '{print $NF}') https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/San_Isidro_Town_Plaza_%28Nueva_Ecija%29_21.jpg/3888px-San_Isidro_Town_Plaza_%28Nueva_Ecija%29_21.jpg | grep last-modified done; codfw:last-modified: Tue, 03 Oct 2023 04:13:36 GMT drmrs:last-modified: Sat, 02 Mar 2024 09:44:36 GMT eqiad:last-modified: Sat, 02 Mar 2024 09:44:36 GMT eqsin:last-modified: Tue, 03 Oct 2023 04:13:36 GMT esams:last-modified: Sat, 02 Mar 2024 09:44:36 GMT ulsfo:last-modified: Tue, 03 Oct 2023 04:13:36 GMT
@Xmityy please don't take offence, but you have never contributed to MediaWiki and your wiki account also has 0 contributions. I think it is a bit ambitious to state that you will have this fixed end of week. Maybe you can introduce your self ?
The patch should make any errors more verbose so that we can collect more information about these failures.
@Ladsgroup I don't think this is what the intent was right ?
Thus used lib is: https://github.com/endroid/qr-code
Created a follow up task, because several people implied that they would still appreciate a working version of this.
This was a temporary problem due to changes to https://commons.wikimedia.org/wiki/Template:License_template_tag
I think this sometimes happens when you changed the color after you made a preview. The image gets cached for a day with the old state, and it takes a day or so before you see the new static image.
In the last couple of weeks it has failed every time. It doesn't fail with other pages that are not part of Wikimedia.
The FB sharing debugger notes:
Can confirm there is definitely something wrong.
Is this only the eu.wp links ? Or all language versions ? What have you tried ?
In T359413#9624623, @Theklan wrote:Anyway, having more than one og:image is not a standard protocol: https://ogp.me/
Suspicion is that there is something different in the runjobs php entry point (order of operations ? different config context?) compared to the other entrypoints that allows this to be triggered only in this situation.
In T359176#9601441, @Ladsgroup wrote:T28741: Migrate file tables to a modern layout (image/oldimage; file/file_revision; add primary keys) will be picked up next Q so buckle up. For now, can we just move the files? (sorry If I sound stupid, I haven't managed to get my head around this yet). I can ask the community to try it.
This requires hooking into resources/mw.FormDataTransport.js, progress event.
@Ankry That would be something that points more to the second possibility. A race condition with the file not yet being available to the process trying to read the metadata.
In T334940#9605612, @Msz2001 wrote:There are also downsides of it, as it would either clutter Commons with many versions of the same graph or people would need to ask for autopatrol specifically to edit graphs. An extreme example would be during the covid pandemic when the graphs were updated weekly or more frequently. In order to reupload a photo uploaded by someone else, an autopatrol right is needed, which is likely not to be given 'just to edit graphs' if person is not very active on Commons otherwise.
In T334940#9604875, @Bawolff wrote:we are at the more philosophical point of wondering at the point of it all, and what sort of failure analysis could avoid such events in the future.
This is not going to get me any friends here, but the real problem was a communication one not an action problem. People were given false hope. The action plan was never clear. Nobody was willing to call a spade a spade publically. I suspect a large source of the frustration is the community feeling they were lead on, only to be dumped at the end, and quite frankly its hard to blame them feeling this way. Telling people no may be a bitter pill, but it is much less bitter than telling people yes (including yes by omission) when the answer is actually no.
Isn't this a simple case of changing ?
I've made a quickfix patch, but am honestly slightly inclined to simply remove the entire beforeunload handler, as the whole mediainfo editor would have to be rewritten to make proper use of onbeforeunload.
Not 100% sure this is it (but i think it is). I too noticed that when i got this warning, when i afterwards switched to the commons data view that one of the properties was in a half completed loading state, where an editor was open. Then it finished loading and the editor was no longer in the editor state.
I've stepped through the logic a bit with some of the reported files, and pretty much the only reason this can happen, is because pdfinfo is not defined/executable/incorrect, or $wgPdfHandlerDpi being 0/undefined.
In T304788#7809008, @De728631 wrote:Apparently the upload process is also affected by this bug. While patrolling new files at Commons I just found https://commons.wikimedia.org/wiki/File:Hanshin_Amagasaki_Station220326.jpg which did not have any visible image content but just the description page although the upload log seemed to be valid. Deleting and undeleting fixed the display though.
I'll also note that Commons can easily add {{Negative boosted template}} to any page, or template used on such pages, if they want these images to show up lower in the rankings.
@Bawolff i suspect this particular issue is fixed now, but i noticed "Concatenation is finished by around line 607541 of the debug log, but it tries to stash again at line 607674." which seems like it might be related to some of the issues you have been chasing. If you are aware and think this is no longer in play and not related to what you were looking at, then I think we can close this.
Special:UploadWizard, subclasses Special:Upload. It then reimplements the entire execute, part of which is to include a 'dumb' special:upload uploadform. The execute however doesn't reimplement most of the functionality that Special:Upload provides and this includes loading the defaults for that upload form. Specifically, it doesn't run loadRequest(), which parses all of the request parameters that Special:Upload can provide. As a SIDE-EFFECT of that parameter parsing, Special:Upload also sets the default for the mComment variable (because it depends on the value of mReUploadFor). This brings up several interesting questions:
I don't see why? This is not a value that most people should ever need. the use case of people checking sha-1's seems extremely niche.
is this stil an issue ?
Chrome doesn't support in-browser viewing of tiff files. https://en.wikipedia.org/wiki/Comparison_of_web_browsers#Image_format_support
which linter, the editor one, or the one that parses the page when you submit to save ?
This is correct, it finds them, it does not import what it has found.
Calling it closed as this was deplooyed
They look ok to me …
Likely due to https://gerrit.wikimedia.org/r/c/wikimedia/portals/+/982921 which moved the logo, so that might have broken a selector somewhere.
hmm, the page is doing a lot of absolute and relative positioning. Someone should just converter it the portal to use proper flex box and then this will be much more predictable.
We don't need to list every file with this issue in the ticket. It's known that this is broken for a considerable subset of files.
In T6740#9571340, @Winston_Sung wrote:I think the problem is the existing table header usages are in different ways.
(we're not talking about which one is better, as we can't really prevent/block something [ File 2 ] happend in wikitext typed by users)
@bvibber any idea where the logs for webtranscode end up these days ? videoscaler.discovery.wmnet is awfully silent since monday.
The vast majority of these peaks of thousands are: 'Cannot read property '0' of null'
In T354501#9569421, @Iniquity wrote:The same problem with ogg files but in Chrome.
https://commons.wikimedia.org/wiki/File:Research_Project_X-15_-_development_of_the_X-15_rocket_plane.ogg
Ah, no that definitely doesn't have anything to do with this.
This change already went out early feb, so i would be surprised if a bug like that went unnoticed for that long. Please open a separate/new ticket with details and label as Regression!
In T15303#9563751, @Nikolay_Komarov wrote:Dear Andre @Aklapper, please help me bring someone's attention to put in into a sprint or escalate priority. These ugly URL-encoded strings should not be parts of Wikipedia.
This might become a very noisy neighbour in terms of i/o and cpu usage. It might be sensible to think of ways to reserve some k8s nodes to async payloads like this one, that don't need low latency.
In T222807#9561360, @aliu wrote:What's the status of this? It's been two months and a half without any updates or public progress done.
In T356984#9553943, @Tacsipacsi wrote:All this because of obscure reasons like “serious potential operational consequences”.
In T352010#9551950, @Ladsgroup wrote:Awesome. I gently recommend unsubscribing from this ticket :D, we are not even 30% done.
In T352010#9551564, @Ladsgroup wrote:Can you try again?
Someone’s reporting that quarry is throwing errors for Commons