In T134469#10229805, @ShakespeareFan00 wrote:

The most recent example of doLevels weirdness...

https://en.wikisource.org/wiki/Page:UKSRO_1890.pdf/1065

Here I even rewrote/split the underlying template so that I could be more clear as to this being a an issue about whitespace, which did not solve the problem.

What happens on this page is that the final line is apparently placed in it's own paragraph in Page: namespace, despite it being part of the preceeding paragraph. This only seems to happen if the end template is in the footer. It cannot be as simple as Dolevels being confused by a <noinclude> can it?

In T376541#10213086, @Samwilson wrote:

I've updated the title, because it doesn't look like this is actually anything to do with VPNs.

In T376541#10213085, @Samwilson wrote:

I'm not quite sure what the solution is here. The above policy says that people "may freely use proxies until those are blocked", and in the case above the IP has obviously already been blocked. WS Export uses the globalblocks data from Meta, as a way to limit resource usage (there are lots of spam bots crawling links from Wikisources).

In T376541#10205706, @Aklapper wrote:

Wikimedia policy is not to block accessing content by anybody

@Ankry: Citation needed. Of course we block abusive traffic.

In T370304#10071856, @Ladsgroup wrote:

In a hacky way I made it wait a 1 second before every edit and it seems to work: https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-Cat-a-lot.js&diff=prev&oldid=912122056 It just needs get client caches purged and propagated.

This problem exists also with moving pages in the main namespace that are unrelated to ProofreadPage

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.

The problem seems to be not only PDF related. This djvu file shows the same effect:
https://commons.wikimedia.org/wiki/File:PL_JI_Kraszewski_Zygzaki.djvu
As a workaround, we uploaded the file directly to Wikisource:
https://pl.wikisource.org/wiki/Plik:PL_JI_Kraszewski_Zygzaki.djvu
It works. But should we stop using Commons?

This problem seems fixed now

In T348396#9233525, @Aklapper wrote:

@Ankry: Hi, I cannot follow. If I go to https://en.wikisource.org/wiki/Page%3AModern_Parnassus_-_Leigh_Hunt_(1814).djvu/50 , where to see page status widgets? Please include full steps to reproduce as a list of steps, including links (as requested in the bug report form). Thanks!

In T319258#8349895, @ssastry wrote:

Yes, any extension that deals with wikitext will need to implement functionality for Parsoid. See https://www.mediawiki.org/wiki/Parsoid/Extension_API#Parsoid_API_for_extensions ... We probably need a phab task for Pages that is a child task of T258838

Any decision what is the proper solution to remove <big> from Mediawiki-generated HTML5 code?

9 yers since it has been reported; very exciting pace of fixing this problem...

If there is no chance to fix the problem quickly in API, maybe a workaround in WS-Export may be introduced?

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.)

In T192199#7891265, @Samwilson wrote:

Since we've switched to OpenSeadragon for the image viewer, has this issue been resolved?

1. It was already suggested in T74525 to harmonize Page/Index namespace numbes across Wikisources
2. The current number used can be retrieved from configuration using the wgProofreadPageNamespaceIds parameter
3. The current list follows. It was extracted from the result of the script https://github.com/phil-el/phetools/blob/master/utils/gen_namespace.py

Please, remember that sourceswiki is also Wikisource (as "old" in the list below).

The problem appeared again today around 20:00 CET.
Maybe, it was a reason that there is much less number of files uploaded today than in previous days?
Special:Upload uploaded without any problem.

In T298417#7593773, @Ladsgroup wrote:

This patch and running it would fix some of the issues but not all. For "filearchive" table fixes I need to find a separate way. In the meantime, any file that has been undeleted and now has issue, just list it here and I run the script on it.

Page number is properly set, so this problem seems to be different to T298417

In T298417#7594875, @Ladsgroup wrote:

Don't worry on that, just make it top version and then let me know to run the script (until I make the patch merged and deployed)

In T298417#7593773, @Ladsgroup wrote:

This patch and running it would fix some of the issues but not all. For "filearchive" table fixes I need to find a separate way. In the meantime, any file that has been undeleted and now has issue, just list it here and I run the script on it.

An attempt to reupload (even the failed one) restores the metadata in Commons:
https://commons.wikimedia.org/wiki/File:Skibinski_pamietnik0001.djvu
But this does not restore the metadata in Wikisource:
https://pl.wikisource.org/wiki/Plik:Skibinski_pamietnik0001.djvu
so cannot be used as an ugly workaround

In T298417#7592558, @Umherirrender wrote:

In T298417#7592371, @Ankry wrote:

Same problem with unhiding a file version that was hidden in August 2021:
https://commons.wikimedia.org/wiki/File:PL_Miriam_-_U_poet%C3%B3w.djvu

This is affected by the missing split of big metadata for the filehistory (oldimage table).

The original task description is affected by the missing split of big metadata for the file archive (filearchive table)

The work was done as part of T275268, but the refreshImageMetadata.php only running for the current file versions

Same problem with unhiding a file version that was hidden in August 2021:
https://commons.wikimedia.org/wiki/File:PL_Miriam_-_U_poet%C3%B3w.djvu

One more example:
https://commons.wikimedia.org/wiki/File:PL_Kieszonkowy_s%C5%82ownik_j%C4%99zyk%C3%B3w_%C5%82aci%C5%84skiego_i_polskiego._Cz._1,_S%C5%82ownik_%C5%82aci%C5%84sko-polski.djvu
(this one has been deleted in 2018)

In T297339#7558451, @Inductiveload wrote:

Quick user-side fix for the non-toolbar vertical layout appears to be some CSS:

#prp-page-image-openseadragon-vertical {
	height: 100%;
}

In T296033#7521448, @Inductiveload wrote:

@Ankry OSD redeployed today along with a backport for this issue in the evening window (the first after the .9 deployment). Could you check and close if OK?

not working or the fix not deployed yet?

Works in production.

May it be related to moving the zooming tool outside of the "Proofread tools" submenu? It seems to be initialized regardless of the toolbar setting.
People also report that the tool zooming is less granular now (single zooming is much higher than it was previously). But this needs a separate bug.

It seems rthat this ProofredPage change may be responsible for unintended loading of wikiEditor:
https://github.com/wikimedia/mediawiki-extensions-ProofreadPage/commit/645dfcc92e5e41490ab724e79f0627aa928ca2ba
Can someone verify this?
Thanks to @PeterBowman for finding this.

In T296033#7515221, @MusikAnimal wrote:

Ankry, Do you have a Global Preference set for this? Check Specjalna:Globalne preferencje. This may be related to T296028: Unable to set a local override for some Global Preferences

No. The global preference for toolbar is also disabled.

Well that's a relief (for me). Upon further inspection, this doesn't appear to be related to the work we've recently done around Global Preferences. I can also confirm it appears to be unique to Wikisource, so I don't think it's an issue with preferences in general.

The problem was reported to me by other users, who also want the toolbar to be disabled as it is highly resource consuming

In T296033#7515187, @MusikAnimal wrote:

@Ankry Do you have a Global Preference set for this? Check Specjalna:Globalne preferencje. This may be related to T296028: Unable to set a local override for some Global Preferences

In T215558#7511187, @Xover wrote:

In T215558#7510911, @Legoktm wrote:

That said...the real problem is clearly that MediaWiki or Thumbor or Varnish is not able to purge all the thumbnails. If someone has an example from the past 7 days it might be possible to look through the logs to get an idea of where the failure is happening (or at least rule out some stuff).

I don't have any files where the thumbnails are currently wrong (maybe someone else subscribed here has?), but the file mentioned in the description returned a failure when purging through the API earlier today (it succeeds now); and I just tested with the file from T206190 and got a failure. Presuming we don't have stale noise hanging around from older operations tripping up the API, whatever fails should have generated a log message somewhere for these.

• c:File:Portland, Oregon, its History and Builders volume 1.djvu
• c:File:PL Jean de La Fontaine - Bajki.djvu

In T192866#7489510, @TheDJ wrote:

From memory, the Xml is needed to figure out the w x h of each page and how many pages there are... and to get the text of each page.

In T192866#7470114, @Xover wrote:

c:File:A_Latin_Dictionary_(1984).djvu shows up with the right dimensions, thumbnails, etc.

s:File:A Latin Dictionary (1984).djvu shows up with 0x0 dimensions, no thumbs, etc.

Interesting. I've just reuploaded this file (for unrelated reasons) and now the previous revision is showing up on Commons with 0x0 pixel dimensions (but still 245MB file size). The current revision now shows up fine on Commons (as the previous did at the time it was uploaded) with dimensions and size, but when viewed from enWS it's broken (0x0) and PRP still chokes on it.

This seems to be fixed already by @Candalua . Am I wrong?

Whatever the underlying pronlem was, the file renders now.

Just FYI: this is not a newly uploaded file, but a new version overwriting the old one (and the old version has been deleted due to copyvio)

Fixed using thump.php thumbnail regeneration

One more page with the same problem:
https://upload.wikimedia.org/wikipedia/commons/thumb/5/5b/Ada_sceny_i_charaktery_z_%C5%BCycia_powszedniego._T._3.pdf/page5-627px-Ada_sceny_i_charaktery_z_%C5%BCycia_powszedniego._T._3.pdf.jpg

Can this be a side-effect of FlaggedRevs?

more examples:
https://pl.wikisource.org/wiki/Na_Laskowski%C3%A9m_polu_%C5%82%C4%85czka_niesieczona
https://pl.wikisource.org/wiki/A_w_niedziel%C4%99_rano
https://pl.wikisource.org/wiki/Moja_pani_matko

Well, this error appears quite often, almost on any non-tiny score, in most cases immediately after request, and often multiple times if retrying.

In T287165#7233544, @Legoktm wrote:

@Inductiveload this looks fixed to me with lilypond 2.22.0 now, can you confirm?

In T257066#7233536, @Legoktm wrote:

https://test.wikipedia.org/wiki/Score/plwikisource/3 isn't working for other reasons besides #UP I think, so that probably merits a dedicated task?

In T257066#7229715, @Inductiveload wrote:

Adding a cache-busting "." to the title of https://en.wikisource.org/wiki/Abide_with_Me_(Illustrated_Victorian_Songbook) causes a parse failure:

https://test.wikipedia.org/wiki/Score/enwikisource/1

First testing results:

If the thumbnail generation cannot be requested asynchronously, to avoid delay in presenting current page HTML code to user (and utilize the time when the page is being downloaded / rendered by the browser for thumbnail generation), then (IMO) it is better to request the next thumbnail generation from some javascript code which would be invoked after the page is already displayed in the browser. This is the way that current pl.ws/it.ws gadgets seem to utilize.

The main goal here is to perform server-side page thumbnail generation in advance. If this can be made without preloading, it is OK. I am not sure if prefetch would provide this.
Thumbnail generation process has been identified to be the most time-consuming part of the "next page" loading process. So making the next thumbnail ready server-side is the main goal.

In T257066#7206936, @Ankry wrote:

In T257066#7206899, @Legoktm wrote:

In T257066#7206860, @Ankry wrote:

https://pl.wikisource.org/wiki/Strona:Pro%C5%9Bba_dziewcz%C4%99cia.djvu/3

I used Special:ExpandTemplates to get the underlying generated <score> tags for that page and saved them on https://test.wikipedia.org/wiki/Score/plwikisource where it looks like they all work.

Well, it is not eactly the final code generated by LUA, but, I think, the final one would not need more features.

In T257066#7206899, @Legoktm wrote:

In T257066#7206860, @Ankry wrote:

https://pl.wikisource.org/wiki/Strona:Pro%C5%9Bba_dziewcz%C4%99cia.djvu/3

I used Special:ExpandTemplates to get the underlying generated <score> tags for that page and saved them on https://test.wikipedia.org/wiki/Score/plwikisource where it looks like they all work.