⚓ T299521 PDF file has 0x0 image size in Commons after uploading a new version while the page number is correct

⚓ T299521 PDF file has 0x0 image size in Commons after uploading a new version while the page number is correct
Page Menu
Phabricator
Create Task
Maniphest
T299521
PDF file has 0x0 image size in Commons after uploading a new version while the page number is correct
Open, Needs Triage
Public
BUG REPORT
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
None
Authored By
Ankry
Jan 19 2022, 1:52 PM
2022-01-19 13:52:38 (UTC+0)
Tags
MediaWiki-extensions-PdfHandler
(Backlog)
MW-1.42-notes (1.42.0-wmf.23; 2024-03-19)
All-and-every-Wikisource
(Backlog)
Referenced Files
F34933396: T299521, ok after upload.png
Jan 27 2022, 7:36 PM
2022-01-27 19:36:00 (UTC+0)
Subscribers
Aklapper
Aleator
Ankry
Arcorann
Balajijagadesh
Candalua
Ciridae
View All 27 Subscribers
Description
After uploading a new version of this file to Commons:
it has 0x0 image size. (The initial version reported non-zero size at the moment)
Note:
0x0 size is a SYMPTOM that can have many causes (something failed while reading the uploaded file). This ticket specifically deals with a recurring case on WIKIMEDIA, where (not consistently) after upload the size becomes 0x0.
Reverting to the previous version fixed the problem just for few minutes, and then its image size was zeroized as well and reappeared again after an hour.
No problem with this file after upload to test Wikipedia:
Note: this does not seem to be duplicate of
T297942
as unlike
this file has correct page numbers.
Details
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
Improve logging for Pdf's retrieveMetadata.sh
mediawiki/extensions/PdfHandler
master
+20
-4
Customize query in gerrit
Related Objects
Mentions
Duplicates
Mentioned In
T390603: Error recognizing pages in uploaded PDF, creating PDF thumbnails and passing it to Wikisource for creating Index pages
T420077: Images are vertically squeezed when editing in the Page namespace
T406479: PDF preview partly broken?
T382824: Cache problems with new Index pages in Wikisource
T364445: DJVU file generated is apparently 0x0 pixels
T371621: ApiUsageException: Could not normalize image parameters for [file].pdf.
T362502: I can't capture error with {{#iferror}}
T333746: After overwriting PDF file, "Failed to initialize OpenSeadragon, no image found" error
T301291: PDF and Djvu files on Commons failed to be processed (no thumbnails, zero pages) but otherwise valid
Mentioned Here
T333746: After overwriting PDF file, "Failed to initialize OpenSeadragon, no image found" error
T420341: PDF file has 0x0 image size in Commons
T297942: Specific PDF on Commons has no image thumbnails, dimensions shown as 0x0 pixels
T298417: Undeleted djvu files show incorrect metadata: 0x0 size, no page number info
Duplicates Merged Here
T315171: PDF file with good resolution appears as 0 x 0 pixel and page preview is not being shown
Event Timeline
Ankry
created this task.
Jan 19 2022, 1:52 PM
2022-01-19 13:52:38 (UTC+0)
Restricted Application
added a subscriber:
Aklapper
View Herald Transcript
Jan 19 2022, 1:52 PM
2022-01-19 13:52:39 (UTC+0)
Ankry
added a comment.
Jan 19 2022, 1:54 PM
2022-01-19 13:54:12 (UTC+0)
Comment Actions
Page number is properly set, so this problem seems to be different to
T298417
Bugreporter
closed this task as a duplicate of
T297942: Specific PDF on Commons has no image thumbnails, dimensions shown as 0x0 pixels
Jan 19 2022, 2:34 PM
2022-01-19 14:34:24 (UTC+0)
Ankry
renamed this task from
PDF file has 0x0 image size in Commons after uploading a new version
to
PDF file has 0x0 image size in Commons after uploading a new version while page number is corect
Jan 19 2022, 2:49 PM
2022-01-19 14:49:15 (UTC+0)
Ankry
renamed this task from
PDF file has 0x0 image size in Commons after uploading a new version while page number is corect
to
PDF file has 0x0 image size in Commons after uploading a new version while the page number is correct
Ankry
reopened this task as
Open
Ankry
updated the task description.
(Show Details)
Aklapper
added a project:
MediaWiki-extensions-PdfHandler
Jan 19 2022, 4:04 PM
2022-01-19 16:04:17 (UTC+0)
Yann
subscribed.
Jan 27 2022, 1:50 PM
2022-01-27 13:50:36 (UTC+0)
Comment Actions
Another file:
Yann
added a comment.
Jan 27 2022, 5:19 PM
2022-01-27 17:19:54 (UTC+0)
Comment Actions
All files in this category are concerned:
Yann
added a comment.
Jan 27 2022, 7:36 PM
2022-01-27 19:36:00 (UTC+0)
Comment Actions
file is ok just after upload
Yann
added a comment.
Edited
Jan 31 2022, 8:45 PM
2022-01-31 20:45:50 (UTC+0)
Comment Actions
Finally, I tried deleting all versions except the last one, but it didn't work. So I deleted everything, and I reupload the file, and it shows fine. The bug still exist through. And it doesn't show properly on Wikisource.
Bugreporter
mentioned this in
T301291: PDF and Djvu files on Commons failed to be processed (no thumbnails, zero pages) but otherwise valid
Feb 9 2022, 1:10 AM
2022-02-09 01:10:05 (UTC+0)
JimKillock
subscribed.
Edited
Aug 20 2022, 5:55 PM
2022-08-20 17:55:58 (UTC+0)
Comment Actions
I'm getting a similar problem with this PDF:
at
Commons it is fine
at la Wikisource
it is 0x0px
at en Wikisource
it is 0x0px
at en Wikipedia
it is also 0x0px
(currently it is broke just on la.ws, as I reverted to an old version.)
Ankry
added a comment.
Aug 21 2022, 1:11 AM
2022-08-21 01:11:36 (UTC+0)
Comment Actions
In
T299521#8170862
@JimKillock
wrote:
I'm getting a similar problem with this PDF:
at
Commons it is fine
at la Wikisource
it is 0x0px
at en Wikisource
it is 0x0px
at en Wikipedia
it is also 0x0px
(currently it is broke just on la.ws, as I reverted to an old version.)
An administrator can try to upload this file locally. This sometimes works as a workaround, but hides the problem.
JimKillock
added a comment.
Aug 21 2022, 11:30 AM
2022-08-21 11:30:06 (UTC+0)
Comment Actions
In
T299521#8171112
@Ankry
wrote:
,snip>
An administrator can try to upload this file locally. This sometimes works as a workaround, but hides the problem.
Are you able to give me some instructions or tips on how this is done so our administrators can assess if it is easy to try or not?
Reedy
subscribed.
Aug 21 2022, 11:47 AM
2022-08-21 11:47:50 (UTC+0)
Comment Actions
In
T299521#8171295
@JimKillock
wrote:
In
T299521#8171112
@Ankry
wrote:
,snip>
An administrator can try to upload this file locally. This sometimes works as a workaround, but hides the problem.
Are you able to give me some instructions or tips on how this is done so our administrators can assess if it is easy to try or not?
Download the file from Commons. Visit Special:Upload on your wiki and upload the file, telling it to continue anyway (I think it will complain it exists on commons)
Reedy
added a comment.
Aug 21 2022, 12:04 PM
2022-08-21 12:04:56 (UTC+0)
Comment Actions
Just as a general comment... While it's helpful if you report these issues, if you revert these uploads several times, while only linking to the general File: page, it makes it hard for anyone to try and debug the issue, as they can't necessarily find which is the "broken" version of the PDF...
JimKillock
added a comment.
Edited
Aug 21 2022, 12:28 PM
2022-08-21 12:28:37 (UTC+0)
Comment Actions
@Reedy
Yes I see that. I'm afraid I was trying to brute force solve this problem, but all of the attempts failed. I'll remember to link to file versions in future.
As it goes the current version is still broken on LA WS, and I won't be moving it again as I am hoping an administrator will move a copy onto the wiki as per your instructions.
Samwilson
mentioned this in
T333746: After overwriting PDF file, "Failed to initialize OpenSeadragon, no image found" error
Apr 5 2023, 1:28 AM
2023-04-05 01:28:51 (UTC+0)
D6283
subscribed.
Jan 5 2024, 1:56 AM
2024-01-05 01:56:23 (UTC+0)
Comment Actions
I went through a similar issue while overwriting this PDF file:
It works fine at Commons, but is shown inconsistent at other wikis.
For example:
Wikipedia-en
and
Wikisource-ko
TheDJ
merged a task:
T315171: PDF file with good resolution appears as 0 x 0 pixel and page preview is not being shown
Mar 2 2024, 9:31 PM
2024-03-02 21:31:58 (UTC+0)
TheDJ
added subscribers:
Balajijagadesh
Aleator
Huji
and
5 others
TheDJ
subscribed.
Edited
Mar 2 2024, 9:40 PM
2024-03-02 21:40:03 (UTC+0)
Comment Actions
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.
Both would be silent errors when they occur.
Another option is that the file that boxedcommand creates with the output of the metadata, is not available for the MediaWiki app server for some reason. This too would be a silent error.
D6283's comment indicates that this is still happening. If all pdfinfo work is now a boxedcommand and running in kubernetes, then this indicates that some hosts either don't have pdfinfo, or that there are occasional issues with the output of the command. A race condition with the file flush?
Ankry
added a comment.
Mar 5 2024, 11:17 PM
2024-03-05 23:17:40 (UTC+0)
Comment Actions
In
T299521#9593621
@TheDJ
wrote:
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.
Both would be silent errors when they occur.
This generally happens on large PDF files. Maybe there is a memory/time/other limit that pdfinfo execution exceeds?
TheDJ
added a comment.
Mar 6 2024, 12:25 PM
2024-03-06 12:25:15 (UTC+0)
Comment Actions
@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.
The file gets uploaded, written to the main file server, then the metadata reading starts and the file is not there at all, or not yet completely written to the location where the metadata is trying to read that file from (a replica server).
gerritbot
added a comment.
Mar 15 2024, 11:49 PM
2024-03-15 23:49:29 (UTC+0)
Comment Actions
Change 1011371 had a related patch set uploaded (by TheDJ; author: TheDJ):
[mediawiki/extensions/PdfHandler@master] Improve logging for Pdf's retrieveMetadata.sh
gerritbot
added a project:
Patch-For-Review
Mar 15 2024, 11:49 PM
2024-03-15 23:49:30 (UTC+0)
TheDJ
added a comment.
Mar 15 2024, 11:52 PM
2024-03-15 23:52:45 (UTC+0)
Comment Actions
The patch should make any errors more verbose so that we can collect more information about these failures.
gerritbot
added a comment.
Mar 18 2024, 5:23 PM
2024-03-18 17:23:38 (UTC+0)
Comment Actions
Change 1011371
merged
by jenkins-bot:
[mediawiki/extensions/PdfHandler@master] Improve logging for Pdf's retrieveMetadata.sh
Maintenance_bot
removed a project:
Patch-For-Review
Mar 18 2024, 5:30 PM
2024-03-18 17:30:42 (UTC+0)
ReleaseTaggerBot
added a project:
MW-1.42-notes (1.42.0-wmf.23; 2024-03-19)
Mar 18 2024, 6:00 PM
2024-03-18 18:00:34 (UTC+0)
Ninovolador
subscribed.
Mar 21 2024, 5:34 PM
2024-03-21 17:34:01 (UTC+0)
Comment Actions
I guess this is related, but I had never experienced this bug before, and yesterday I uploaded a lot of books, and at least 5 had this issue
a mix of large and small PDFs. They look fine at my notebook, and also reads well when downloaded from Commons. Can't reupload because it's identical to the one at Commons.
Ninovolador
added a comment.
Mar 21 2024, 5:43 PM
2024-03-21 17:43:10 (UTC+0)
Comment Actions
&action=purge seems to solve this issue. Can we search for other PDF files that have this issue?
Ninovolador
added a comment.
Mar 29 2024, 2:27 PM
2024-03-29 14:27:22 (UTC+0)
Comment Actions
Can confirm:
that the problem is present both at Commons and every local wiki
?action=purge on a local description page (e.g. Spanish Wikisource Archivo:Filename.pdf) solves the problem locally, but only after '?action=purge'ing the Commons description page.
Ninovolador
mentioned this in
T362502: I can't capture error with {{#iferror}}
Apr 15 2024, 4:31 AM
2024-04-15 04:31:08 (UTC+0)
Xover
subscribed.
Apr 15 2024, 9:17 AM
2024-04-15 09:17:28 (UTC+0)
Comment Actions
In
T299521#9635282
@TheDJ
wrote:
The patch should make any errors more verbose so that we can collect more information about these failures.
@TheDJ
Based on buzz around various places this problem seems to be markedly more prevalent currently, and has been for anything from around the last week to a couple of weeks (guesstimate based on how long it usually takes such issues to bubble up to catch attention).
We're mostly seeing this for Index:-namespace pages, possibly because 1) they are nearly always depending on multi-page files (vs. plain jpegs), 2) they actually always need the page numbers and other extended metadata, and 3) they are very often created shortly after the file is uploaded.
Anecdotally (and I verified in one case), the file on Commons looks fine, the file on the local wiki looks broken (no thumb), and the Index: page displays the above error. Purging the file on Commons has no effect, but purging the non-existent local file description page fixes it. This last is different from previous problems that looked similar in that no amount of purging of anything seemed to have an effect in those cases, except maybe exceptionally and randomly (so we're probably talking a cluster of similar problems).
But that it appears significantly more prevalent right now means something changed somewhere in the stack and combined with the extended logging it may be possible to pinpoint the cause.
Arcorann
subscribed.
May 20 2024, 6:20 AM
2024-05-20 06:20:15 (UTC+0)
Loman87
subscribed.
Jun 3 2024, 8:17 AM
2024-06-03 08:17:47 (UTC+0)
Comment Actions
I don't know if this could add something to the discussion, anyway on my mw installation (MediaWiki 1.40.0; PHP 8.3.7 (apache2handler); ICU 70.1 ; MariaDB 10.11.8) I am having the same issue. If I try to generate the thumbs of a pdf via script, I get this:
Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/mediawiki/thumb.php on line 362
Xover
added a comment.
Jun 3 2024, 9:04 AM
2024-06-03 09:04:12 (UTC+0)
Comment Actions
In
T299521#9853712
@Loman87
wrote:
Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/mediawiki/thumb.php on line 362
Passing
null
to
strlen()
was deprecated in PHP 8.1, but this is probably just a symptom. Whatever is being passed to
strlen()
should presumably not be null and is so because something failed earlier in the process.
This "something" could be anything, including datacenters being out of sync, JobQueue jobs timing out, DB queries timing out, pathological data that makes Ghostscript spit out something the PDF handler doesn't handle.
For example, it looks like
FileRepo\ThumbnailEntryPoint.php
mostly sanitizes what it passes to
strlen()
(using null coalescing), but in one instance, when trying to generate a
Content-Length
header, it passes
$content
directly so that if it fails to get the thumbnail data it'll throw that error.
TheDJ
added a comment.
Jun 3 2024, 9:11 AM
2024-06-03 09:11:03 (UTC+0)
Comment Actions
In
T299521#9853925
@Xover
wrote:
In
T299521#9853712
@Loman87
wrote:
Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/mediawiki/thumb.php on line 362
This "something" could be anything, including datacenters being out of sync, JobQueue jobs timing out, DB queries timing out, pathological data that makes Ghostscript spit out something the PDF handler doesn't handle.
Well in this case it is
So thumbproxyurl is null. This was fixed with null coalescing in a patch release of 1.40
TheDJ
updated the task description.
(Show Details)
Jun 4 2024, 2:17 PM
2024-06-04 14:17:19 (UTC+0)
TheDJ
mentioned this in
T371621: ApiUsageException: Could not normalize image parameters for [file].pdf.
Aug 1 2024, 5:30 PM
2024-08-01 17:30:50 (UTC+0)
Uzume
mentioned this in
T364445: DJVU file generated is apparently 0x0 pixels
Aug 11 2024, 12:20 PM
2024-08-11 12:20:38 (UTC+0)
AntiCompositeNumber
mentioned this in
T382824: Cache problems with new Index pages in Wikisource
Jan 2 2025, 5:37 PM
2025-01-02 17:37:01 (UTC+0)
Uzume
subscribed.
Jan 4 2025, 2:02 PM
2025-01-04 14:02:49 (UTC+0)
Likibp
awarded a token.
Mar 23 2025, 5:00 PM
2025-03-23 17:00:12 (UTC+0)
Likibp
subscribed.
Candalua
subscribed.
May 6 2025, 9:57 AM
2025-05-06 09:57:46 (UTC+0)
Comment Actions
This issue (or something closely related) has been causing problems at Wikisource projects for a long time now. Basically, every single file that is uploaded for use at Wikisource has this issue, and needs to be purged after the upload. This is very confusing and frustrating for new and inexperienced users, because they just can't understand what is going wrong, and they don't know how to purge the file to solve the problem.
Please, is it possible to do something to solve this issue?
If purging the file solves the problem, is it possible, at least as a temporary measure, to just force an automatic purge after every upload of a PDF or Djvu file?
RoyZuo
subscribed.
May 11 2025, 9:15 AM
2025-05-11 09:15:38 (UTC+0)
Comment Actions
In
T299521#9672937
@Ninovolador
wrote:
Can confirm:
that the problem is present both at Commons and every local wiki
?action=purge on a local description page (e.g. Spanish Wikisource Archivo:Filename.pdf) solves the problem locally, but only after '?action=purge'ing the Commons description page.
i just tried this method on
. doesnt seem to work.
Ankry
added a comment.
Edited
May 11 2025, 9:36 AM
2025-05-11 09:36:55 (UTC+0)
Comment Actions
In
T299521#10809738
@RoyZuo
wrote:
In
T299521#9672937
@Ninovolador
wrote:
Can confirm:
that the problem is present both at Commons and every local wiki
?action=purge on a local description page (e.g. Spanish Wikisource Archivo:Filename.pdf) solves the problem locally, but only after '?action=purge'ing the Commons description page.
i just tried this method on
. doesnt seem to work.
Strange that the problem appears only in nlwikisource; the file info is properly visible here:
Ankry
added a project:
All-and-every-Wikisource
May 11 2025, 9:47 AM
2025-05-11 09:47:15 (UTC+0)
Ciridae
subscribed.
Jul 2 2025, 4:03 PM
2025-07-02 16:03:59 (UTC+0)
AntiCompositeNumber
mentioned this in
T406479: PDF preview partly broken?
Oct 6 2025, 1:57 PM
2025-10-06 13:57:41 (UTC+0)
KTT-Commons
mentioned this in
T420077: Images are vertically squeezed when editing in the Page namespace
Mar 14 2026, 2:08 PM
2026-03-14 14:08:00 (UTC+0)
KTT-Commons
subscribed.
Edited
Mar 17 2026, 5:32 AM
2026-03-17 05:32:23 (UTC+0)
Comment Actions
I've found the problem re-occurred for some files again. In
Index:Sabah, Sarawak and Singapore (State Constitutions) Order in Council 1963.pdf
, all page thumbnails just won't appear after page 1 of the index (
example
). Similar problems happen for
this another file
When entering the affected pages on Wikisource, it displays "Failed to initialize OpenSeadragon, no image found." OCR is also disabled. Purging the Commons and Wikisource description pages are useless.
I would be grateful if someone can look into this problem, thank you.
Samwilson
added a comment.
Mar 17 2026, 5:39 AM
2026-03-17 05:39:53 (UTC+0)
Comment Actions
On Commons for
that page
the error is:
Error creating thumbnail: Invalid thumbnail parameters or TIFF file with more than 1,000 MP
TheDJ
added a comment.
Edited
Mar 17 2026, 7:04 AM
2026-03-17 07:04:09 (UTC+0)
Comment Actions
@KTT-Commons
Seems like a separate issue to me as it doesn’t say 0x0 for the metadata. Please file a separate ticket
Yann
added a comment.
Mar 17 2026, 11:23 AM
2026-03-17 11:23:16 (UTC+0)
Comment Actions
I has happened twice to me recently. I uploaded a dummy file, and reverted to the original, and it fixed the issue.
Yann
added a comment.
Mar 17 2026, 12:18 PM
2026-03-17 12:18:01 (UTC+0)
Comment Actions
It happened again, so this seems to be systematic and reproductible. I have opened a new report:
T420341
KTT-Commons
added a comment.
Mar 17 2026, 12:23 PM
2026-03-17 12:23:22 (UTC+0)
Comment Actions
In
T299521#11717083
@TheDJ
wrote:
@KTT-Commons
Seems like a separate issue to me as it doesn’t say 0x0 for the metadata. Please file a separate ticket
I came here because of a merged ticket (
T333746
) that ultimately ended up here. Do I really need to file a new ticket?
TheDJ
added a comment.
Mar 17 2026, 12:33 PM
2026-03-17 12:33:03 (UTC+0)
Comment Actions
In
T299521#11718169
@KTT-Commons
wrote:
I came here because of a merged ticket (
T333746
) that ultimately ended up here. Do I really need to file a new ticket?
Yes it's a separate problem with differing symptoms and even a different result
Ankry
added a comment.
Edited
Mar 18 2026, 10:22 PM
2026-03-18 22:22:24 (UTC+0)
Comment Actions
Another file with this problem:
(but after a fresh upload, not reupload)
mxn
subscribed.
Mar 20 2026, 6:16 PM
2026-03-20 18:16:41 (UTC+0)
Comment Actions
I also encountered this problem recently with the initial upload of
. This PDF is very large and has its own page numbering system with front and back matter. Purging the Commons file description page had no effect. However, I went to a local wiki (Wikidata), and purging there did fix the size both there and on Commons.
Hakimi97
subscribed.
Tue, Apr 14, 5:24 AM
2026-04-14 05:24:50 (UTC+0)
Vladis13
mentioned this in
T390603: Error recognizing pages in uploaded PDF, creating PDF thumbnails and passing it to Wikisource for creating Index pages
Mon, Apr 20, 12:01 PM
2026-04-20 12:01:10 (UTC+0)
Log In to Comment
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct.
Wikimedia Foundation
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits