|Resolved||None||T122260 [GOAL] Promote related pages to production (on for everyone) on all wikis|
|Resolved||• jhobs||T123549 Blurry image thumbnails accompany article suggestions|
|Declined||None||T132132 PageImages should support other aspect ratios|
|Resolved||None||T132362 HTMLHorizontalRuleFieldTest::testCreatingFieldGivesExpectedStrings test failure|
Yep, they look nasty because they're blown up. The thumbnails requested are 53px, when the width of the div is 80px. Just request the 80px. Sure, that's 2kb extra per image, but they're loaded async and this is the desktop site, it's nothing compared to the weight of in-article thumbs.
What I see (53px):
What it would look like with 80px:
Interestingly, the PHP image in the middle is already 80px. I suspect some incorrect logic in how cropping is handled. If the image is in portrait mode, regardless of its height, 80px width is all you need for the thumbnail. If the image is in landscape mode, then I guess you want a bigger width than 80px.
Anyway, you can see that for yourself on https://en.wikipedia.org/wiki/Monkey_patch
@dr0ptp4kt I purposely pushed this in to I as it keeps being punted into next sprint and we've now had 2 reports on the beta features page. It's a small fix and I'll like us to get to it this sprint, given all the other tasks are large and it would be useful to have some smaller tasks for the team to work on when they have spare time to avoid burn out.
We are requesting pithumbsize = 80 and PageImages is returning images where the height is 80px but the width is less than 80px.
Ideally pithumbsize should either apply to both width and height or should allow us to specify which to use.
The patch has two issues
- What to name the parameter
- Whether it is acceptable to run transform twice for the % of cases it impacts or whether we should explore updating the transform function in includes/filerepo/file/File.php
Since there hasn't been much discussion on the patch in a while, I've changed the attribute to be named "thumbmode" and think that's a fair solution for now. If we want to eventually update the transform function, I can add in a FIXME.
As a short term measure, let's just request a larger thumbnail to reduce the likelihood of the image being too small.
I'm worried that every day we leave this, opinion of this extension is impacted and it's not clear if the overhead in the better solution is acceptable right now. I have captured the more generic problem in a separate task.