Page MenuHomePhabricator

Long score overlaps with statement box and edit button
Closed, ResolvedPublic3 Estimated Story Points


When entering a long notation in a statement with the new datatype musical notation, the result is displayed out of the statement area and overlaps with the edit button:

Screenshot from 2019-03-13 11-06-00.png (305×1 px, 18 KB)

Tested on beta and test

We should probably make sure that the score breaks to a new line while staying in the define zone of the interface.


  • use lilypond line-width configuration with 3in for Wikibase
  • configure the line width using a configuration variable wgScoreLineWidthInches

Event Timeline

The only way I know of making the score narrower is to set the page size of the score (e.g. #(set-default-paper-size "b6"); I used this in an article).

A possible CSS workaround:

.wikibase-snakview-value .mw-ext-score img {
    max-width: 100%;
    object-fit: scale-down;

But depending on how much scaling is necessary, this can make the score unreadable, so a solution at the LilyPond level (as suggested by @Jc86035) is probably better.

I've tried testing the scores from the linked Wikipedia article at Q405798 on beta. The page resizing seems to work, although a different size might be better.

The code of the last score (which I modified slightly to reduce the character count) doesn't match the rendering with <score>, as the entire score is duplicated on wmflabs but not on enwiki, so something might be wrong with it. The difference occurs because the original has a line break before \layout { indent = 0 }. Wikibase does not allow line breaks in strings.

Addshore triaged this task as Medium priority.Mar 13 2019, 11:09 AM
Addshore moved this task from Incoming to Ready to estimate on the Wikidata-Campsite board.

Considering that the mobile site has a column width of 280px for wikibase-statementgrouplistview and the desktop site's wikibase-snakview-body is 417px wide at maximum, using a zoom as well as a page size might be appropriate. (Alternately, the mobile site could use a different page size, but that might open a few cans of worms.)

(I used Vector and Minerva in Firefox on a Mac to get those values. It's somewhat surprising to me that Wikibase on desktop still doesn't have any sort of responsive design, but I digress.)

.wikibase-snakview-value .mw-ext-score img {
    max-width: 100%;
    object-fit: scale-down;

or use overflow-x: auto, like mobile site does when content is too big and it cannot be sure it is easily resizable.

@TheDJ I’m not sure exactly what CSS you mean, but overflow-x: auto on its own doesn’t seem to do anything on my system, and in combination with max-width: 100% it only scales one axis, distorting the aspect ratio.

.wikibase-snakview-value .mw-ext-score {
    max-width: 100%;
    overflow-x: auto;

In Minerva, this is the noresize rule. It overrides minerva's default of responsive images, for situations where responsive images just don't work (for various reasons, think image composition maps, railway diagrams etc).

Ideally this would have some sort of interactivity indicator when an area like this comes into view (think a slide animation or something), as MacOS and iOS and some Android browsers no longer show scrollbars before you interact with the scrollable area.

Addshore set the point value for this task to 3.Mar 19 2019, 4:08 PM

Change 498094 had a related patch set uploaded (by Alaa Sarhan; owner: Alaa Sarhan):
[mediawiki/extensions/Score@master] shorten score line width on wikidata

Change 498660 had a related patch set uploaded (by Alaa Sarhan; owner: Alaa Sarhan):
[operations/mediawiki-config@master] Add wgScoreLineWidthInches to labs config

Change 498661 had a related patch set uploaded (by Alaa Sarhan; owner: Alaa Sarhan):
[operations/mediawiki-config@master] Add wgScoreLineWidthInches to config

alaa_wmde updated the task description. (Show Details)
alaa_wmde updated the task description. (Show Details)

configure the line width using a configuration variable wgScoreLineWidthInches

that sounds like it will also affect scores on the same wiki outside of statements :/

@LucasWerkmeister aha so we do have scores outside statements in Wikidata? If that's the case, then we need to change how it's done indeed. One config variable won't work

In Wikimedia, certainly, that’s why the Score extension exists :) in Wikidata, nothing stops me from creating them (example), though I’m not sure if they’re really used anywhere (perhaps in WikiProject Music)?

Okay, apparently you can find scores with Special:PagesWithProp/score. Not that many uses at the moment.

I see .. well if that's not the main use case (themes) I think it isn't that undesirable for the width in statements to be generalized to the entire wiki. @Lydia_Pintscher ?

If we want to distinguish, then I'd go with a hybrid solution that combines @Ebe123 suggestion to use an arg on the <score> tag and make a the global config a default value holder for wikibase statements for now, and probably name it then wgWBDTMusicalNotationLineWidth

Yeah so ideally we have one width for statements on entities and another width for everything else on Wikidata. If this is more than say 3h of work then it's probably not justified spending time on that part atm though. In this case I'd set everything to the width we need for statements.

Yeap I can make both in ~3h for sure.. won't include much refactoring then but can be done.. lemme try

Change 498094 merged by jenkins-bot:
[mediawiki/extensions/Score@master] shorten score line width on wikidata

Change 498660 merged by jenkins-bot:
[operations/mediawiki-config@master] Add wgWikibaseMusicalNotationLineWidthInches to labs config

planned to deploy this in the mid-day swat today

Change 498661 merged by jenkins-bot:
[operations/mediawiki-config@master] Add wgWikibaseMusicalNotationLineWidthInches to config

Mentioned in SAL (#wikimedia-operations) [2019-04-16T11:18:09Z] <hoo@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Add wgWikibaseMusicalNotationLineWidthInches to config (T218191) (duration: 00m 52s)

Moving to the “stalled” column, since I don’t think we’re doing anything here at the moment – it’s just waiting for 1.34.0-wmf.1 to reach group1 (currently blocked on several tasks, see T220726: 1.34.0-wmf.1 deployment blockers).

The fix already seems to be live on you can see it, for example, on Q198557. Unfortunately, it looks like you need to actually edit a musical notation statement for the change to take effect – purging the page apparently doesn’t remove the rendered LilyPond PNGs. That might become a problem…

Also, it seems that if you change it back to the original, the old thumbnail is reused.

Is there a way to reset all of Wikidata's LilyPond images?

I was able to do it locally with the following code:

$b = Score::getBackend();
$imagePath = 'c/u/cuyqryp5dkc9pf7nytn4wve93hwed0a/cuyqryp5.png'; // this will vary by image, of course

$b->delete( [ 'src' => $b->getRootStoragePath() . '/score-render/' . $imagePath ] );

Afterwards, the page needed to be purged in order to regenerate the image with the new configuration.

This requires that we find the image paths of all the scores that were already rendered on Wikidata (real and test). FileBackend also has a getDirectoryList() method that we could presumably use to list everything below score-render/, but the score storage is shared with all other wikis, so that would disrupt them as well (we’d need to purge pages across hundreds of wikis).

Might be worth wrapping this up in a maintenance script:

  • list all properties with “musical-notation” datatype
  • for each property, list all pages in entity namespaces that link to that property
  • for each page, find the image paths (ideally that’s somewhere in some metadata, otherwise grep the HTML, I guess)
  • delete those images from the backend
  • purge the page

I think a complete reset could require looking at every diff that links to the properties as well, since I've definitely edited some of the relevant statements more than once.

Yes, all scores can be purged by changing CACHE_VERSION:$40

I'm fine with incrementing it for this.

Change 504931 had a related patch set uploaded (by Ebe123; owner: Ebe123):
[mediawiki/extensions/Score@master] Invalidate score cache

Change 504931 merged by jenkins-bot:
[mediawiki/extensions/Score@master] Invalidate score cache

Dropping a note about T67252: Rendered score image overlaps scan image on Wikisource here which could possibly benefit from however the current issue gets solved.

@Ebe123 the CACHE_VERSION bump was merged and should have been deployed for a while now, but purging Q11980 from the parser cache (I tried both action=purge and purgePage.php) doesn’t seem to fix the issue. Any ideas why?

Pinging @Ebe123, did you have chance to look into the issue described above (i.e. T218191#5180154)? It's been a while since the cache version has been bumped, but the score still does look wrong on Any ideas what could be an issue there?

Sorry, I have been looking as to why the cache bumping does not work, as it should be part of the hash. I have not determined why it fails. For Q11980, I added a useless character to re-generate the image, although that shouldn't be necessary.

Since this task seem to have fixed the issue for new scores, and old ones except (are there any others? is there a way to check that even?), I'd like to close this task.

If that's fine by you @Ebe123, I'd first create a separate task to follow on the Version/caching issue and close this then. sounds good?