Mon, Nov 30
Yes. And the image should not replace it. The lilypond code should be still available in some way in the newest page version.
So, if it is updated, the image may also be updated.
The second link is an ogg file. Maybe you could move to midi or musicxml as editable format?
Anyway, my proposed solution was just meant as a quick and dirty hack so Wikipedia end users for the time being can at least see the scores that are currently in lilypond. These scores are usually small examples anyway, not full pieces, but they are important for end users trying to learn from Wikipedia. Once the lilypond security issue is solved, it could be reverted back to <src> (the src could actually be kept as a comment or deactivated somehow). Some scores in Wikipedia are already in image format, so I guess it wouldn't be that bad (for end users).
Making a dirty hack is better than doing nothing. If lilypond cannot be executed on WMF servers, it may be executed on an external server, in specially prepared secured, chrooted environment, and the image uploaded/updated by a bot.
Sun, Nov 29
Sun, Nov 15
Sat, Nov 14
Sep 6 2020
Just another user hit by this problem:
Aug 14 2020
Jul 15 2020
Broken on all wikis, no workaround, multiple complants from users on IRC. Maybe the change that introduced the bug should be reverted if no chance for quick fix deployment?
Jul 8 2020
Jun 11 2020
Apr 19 2020
Apr 15 2020
Just a recent example OTRS ticket related to this problem:
Apr 9 2020
Mar 4 2020
Feb 16 2020
I'd like to note that adding a newline between any pages will break other things. Eg. when an image is added on a separate page inside a paragraph:
- page1: start of paragraph text
- page2: image (as a <div>)
- page3: end of paragraph text
If a newline is inserted between pages, parser will end the paragraph before the image, inserting an extra </p> there and the actual paragraph becomes split. This is not an expected behaviour.
Feb 9 2020
Jan 22 2020
Jan 13 2020
Jan 11 2020
Jan 10 2020
Jan 3 2020
Jan 2 2020
Dec 10 2019
Nov 24 2019
The current behaviour tends to cause problems and mislead users, see
Nov 21 2019
Nov 11 2019
Oct 31 2019
Sep 25 2019
Sep 20 2019
Sep 19 2019
Sep 14 2019
This does not seem to be deployed to "all wikisource". sourceswiki is a wikisource project and partial blocks are not available there.
Sep 2 2019
@Peteforsyth It seems that there was a misplaced tie in the Lilypond code. After this fix:
it works fine.
Aug 25 2019
Aug 21 2019
- it works only with multipage scores (well, on an inlined score image the extra spacing is not expected, but if the midi player is added the spacing is still needed)
- it adds extra space not only before the player, but also between pages (well, in most cases it does not hurt, but see below)
- the space is in em (current context font-size dependant). And this can sometimes give unexpcted results.
I would suggest the extra space to be in px, added only after the last page and only if the player is present.
Maybe just put the player into an extra div with non-zero margin-top?
Jul 17 2019
Jul 11 2019
Just notifying wiki users about this need.
Pages need to be purged in order to display new namespace name in page title.
Jul 9 2019
This is probably a side effect of T227590.
Jul 8 2019
I think, this interaction between ProofreadPage and WikiEditor toolbar cannot be fixed inside ProofreadPage. The search and replace tool incorrectly assumes that all raw content of the wikicode is provided to user
Jul 7 2019
Jul 6 2019
As suggested by @Urbanecm I also tried Special:MergePages with a strange result:
Source page: File:T173070Ryde Tesco pedestrian walkway.JPG Destination page: File:Ryde Tesco pedestrian walkway.JPG
Jul 4 2019
@Peteforsyth, I quite often encounter this problem while uploading a new version of a multi-page file with thousands of thumbnails (generally files with >500 pages). See eg T206190 or T214759 .
I know 3 workarounds to deal with this problem in Wikisource (when this already happen):
- change scan with in index after upload a new version (if they are 1px wider/narrower new thumbnails must be generated
- use js to replace thumbnails for specific pages with thumbnails with other names; see example in pl.ws MadiaWiki:Commons.js :
(useful for few already existing pages)
- upload the file locally
From my experience, the outdated thumbnails seem to disapear after few weeks to half a year.
Jun 30 2019
Jun 2 2019
@Ladsgroup Are thre any tickets describing what are the script problems that this task should depend on?
May 26 2019
High resolution thumbnails from the file, like:
look poor and exhibit artifacts likely resulting from scalling-up jpg image with lossy compression
May 25 2019
OK, after some delay the file works.
May 24 2019
$ qpdf --check Mueller_letter_to_Barr_2019-03-27.pdf checking Mueller_letter_to_Barr_2019-03-27.pdf PDF Version: 1.3 File is not encrypted File is not linearized No syntax or stream encoding errors found; the file may still contain errors that qpdf cannot detect
Now, qpdf does not detect errors, but thumbnails are still not generated.
May 15 2019
Is this really fixed? I still get strange Content-Type for the thumbnail from description (however it is not [text/html] already:
$ wget -S https://upload.wikimedia.org/wikipedia/commons/thumb/5/57/Status_iucn3.1_LC_cs.svg/200px-Status_iucn3.1_LC_cs.svg.png 2>&1 | grep Content-Type Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK Date: Wed, 15 May 2019 07:04:15 GMT Content-Type: application/x-www-form-urlencoded Content-Length: 8100 Connection: keep-alive Etag: b485920910bc973c3fad353a9b809944 Server: ATS/8.0.3 X-Object-Meta-Sha1Base36: s73fklaf49dfygd9oug7c9kbjy5wu6h Last-Modified: Mon, 03 Apr 2017 12:50:01 GMT X-Timestamp: 1491223800.69668 X-Trans-Id: txc11c43e2ea804120a6f6f-005cd50dde X-Varnish: 265855185 200635104, 101450013, 151146220 113949253 Via: 1.1 varnish (Varnish/5.1), 1.1 varnish (Varnish/5.1), 1.1 varnish (Varnish/5.1) Age: 8574 X-Cache: cp3038 hit, cp3038 hit/77 X-Cache-Status: hit-front Server-Timing: cache;desc="hit-front" Strict-Transport-Security: max-age=106384710; includeSubDomains; preload X-Analytics: https=1;nocookies=1 X-Client-IP: 2a00:6d47:10:b95:dad:beef:baba:dead Access-Control-Allow-Origin: * Access-Control-Expose-Headers: Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache, X-Varnish Timing-Allow-Origin: * Accept-Ranges: bytes
Mar 29 2019
I have recently implemented in plwikisource a LUA based solution of this problem.
Feel free to use this concept elsewhere;
However, this is still a "work in progress" so undocumented, etc.
Mar 28 2019
It seems that this problem is fixed by https://gerrit.wikimedia.org/r/499801
It seems that this fix fixed also T219371
So they were related...
Mar 20 2019
I think, this still needs some maintenance to regenerate broken score images, created while the wrong configuration was active.
Mar 18 2019
Jan 28 2019
the problematic version restored after revi's delete and history merged on-wiki.
Is there still any phabricator-related issue here?
This is probably related to the problem described in T214759.
Jan 26 2019
Well, I think I have found some correlations.
- The 503 error is likely accidental here; it appered once or twice, I cannot reproduce it.
- The problem concerns many (maybe all?) djvu files with a lot of thumbnails (likely much more than 1000).
Maybe also related to T206190 as there are thousands of outdated thumbnails related to this file.
Jan 21 2019
Jan 20 2019
Please note: PDF rendering is critical for Wikisources where users dgitize books. Providing an OCR layer instead of real page images is misleading contributors who may interpret OCR errors as print errors. Please advice about urgent fix.