Page MenuHomePhabricator

1.35.0-wmf.4: Wikilove background image no longer displayed
Closed, ResolvedPublicBUG REPORT


Steps to Reproduce:
Visit the user page on a wiki with wikilove installed and mediawiki 1.35.0-wmf.4

Actual Results:
Wikilove link still included, but the image is not properly retrieved. Commons screenshot shown below - the element is still there and still works, and the image is still at the specified url (

Expected Results:
No difference from 1.35.0-wmf.3, in that the wikilove feature still works

Wikilove error.JPG (997×2 px, 301 KB)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DannyS712 triaged this task as Unbreak Now! priority.Oct 30 2019, 9:25 PM
DannyS712 moved this task from Unsorted to Reports on the User-DannyS712 board.

"Any open subtask(s) block the train from moving forward.This means no further deployments until the blockers are resolved."

Only patch to WikiLove in wmf.4 is 8319ddb82c029e2145c177c4d85a0e623b3d5dab, which would surprise me to break something like this. Pinging @Esanders, though I'm not sure I think this is an appropriate blocker for the train given the severity and impact.

This comment was removed by Esanders.

My sense is that this may or may not block tomorrow's promotion to group2, but probably does not warrant rolling back group1 at present?

I don't think it blocks group2, and it definitely doesn't need a group1 rollback.

Looks like WikiLove was already targeting the correct element (in that, it was not relying on the existence of <span> elements).

However, it was broken by an earlier commit in which Volker and I re-implemented the background images using 1px wide gradient. The background-size rule for that gradient is now applying to the WikiLove <a> element. Here is a screenshot of the tab bar with that rule disabled:

Screenshot 2019-10-30 at 18.01.49.png (1×1 px, 263 KB)

This rule could be disabled by WikiLove, but that would still mean that the separator line between WikiLove and watchstar will be missing.

Instead of that, we should probably do the long-overdue update to WikiLove to make it's icon logic match that of Vector, by using ::before instead to render the icon.

Change 547331 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/WikiLove@master] Fix vector icon after upstream change

Change 547331 merged by jenkins-bot:
[mediawiki/extensions/WikiLove@master] Fix vector icon after upstream change

Change 547361 had a related patch set uploaded (by Jforrester; owner: Esanders):
[mediawiki/extensions/WikiLove@wmf/1.35.0-wmf.4] Fix vector icon after upstream change

Change 547361 merged by jenkins-bot:
[mediawiki/extensions/WikiLove@wmf/1.35.0-wmf.4] Fix vector icon after upstream change

Mentioned in SAL (#wikimedia-operations) [2019-10-31T00:40:57Z] <jforrester@deploy1001> Synchronized php-1.35.0-wmf.4/extensions/WikiLove/resources/ext.wikiLove.icon.vector.css: T236958 Fix Vector icon after upstream change (duration: 01m 02s)

Jdforrester-WMF assigned this task to Esanders.

Fixed and deployed. Thanks, Ed.