Page MenuHomePhabricator

Enable PageImages by default for Wikisource and Wikibooks
Closed, ResolvedPublic

Description

In InitialiseSettings.php, the PageImages extension is enabled by default everywhere, and then disabled for Wikisource and Wikibooks, with a reference to T68455: Thumbnails for search results don't make sense for most projects. That task is from 2014 and obviously from a "different reality" than today – now Vector-2022 is default everywhere (or just about), and its search widget assumes PageImages is enabled. The result is that for Wikisource and Wikibooks projects, all search results (in the typeahead search) will just get the default "no image" thumbnail, and there may be ramifications for search engine display too.

There have been two requests to enable PageImages for Wikisource (T416800: Enable PageImages extension in bnwikisource and T362851: Enable PageImages extension in hewikisource), and there would probably be more if more communities knew about the possibility.

So I suggest just removing the disabling of PageImages for those projects entirely, which would have the bonus of simplifying the config for wmgUsePageImages in InitialiseSettings.php as well.

(convenience link to IRC logs)

Event Timeline

This task follows up a discussion I had during this morning deployment window for backports & config patch. PageImages is a lightweight extension and I think it should be enabled on all wiki projects.

If there are no images hosted, the extension has little use, then it does no harm either. On the other hand any project that could have a use for it needs to do the full process of filing a task, getting community consensus, waiting a week, creating a config change and having it deployed.

I think we should address that once for all wikis and save everyone some time. I don't know how to reach out to the Wikibooks and Wikisource communities but we certainly have a way to do that (via Tech news?). I will ask inside the WMF.

(I would tag PageImages' code stewards on this task for their information, but FWICS from mw:Maintainers & mw:Extension:PageImages, PageImages doesn't even have a documented 'last resort' code-steward at the moment. So ccing @Jdlrobson-WMF in lieu of adding a team-tag)

This task follows up a discussion I had during this morning deployment window for backports & config patch.

(convenience link to IRC logs)

Thank you @A_smart_kitten , specially for the to the IRC log. I have added PageImages

My usual internal WMF contact to reach out to our user is in vacations currently. I have send an internal email to all of engineering (link to private Slack thread) to find out:

  • What is the impact of enabling PageImages on all Wikibooks and Wikisource
  • How to involve our users in the decision and have them informed of the change

I will ping here after a few days when I get an update

I will ping here after a few days when I get an update

@hashar Just curious if you received any information about this :)

I don't see any issues with adding the extension on all wikis, but note it might not work as expected and since nobody is actively maintaining it, it's unlikely that anything will change in the software to support that.

Note details around how the image is selected is at https://www.mediawiki.org/wiki/Extension:PageImages#Image_choice
The wikis may need to modify their content to get it to work if it doesn't work as expected.

One thing to bear in mind, is it may require further configuration tweaking on other projects - for example one side effect of enabling this is that ALL search suggestion results will show the page image by default.

I didn't find this task before, but here is my grain of salt:

What is the impact of enabling PageImages on all Wikibooks and Wikisource

The impact is that when I send a link to a proofread book, my proud result from the last several week's work, to my friend, it won't look like a sketchy bare link and maybe he will click it.

How to involve our users in the decision and have them informed of the change

Just enable the extension, as it is very much better than not having the extension, and inform the communities that this was due to mere negligence for years.

I find very concerning that the disabling of the extension was done without any consult to the communities, by a single decision made in a rush one day in 2014. Just revert!!!

Change #1271862 had a related patch set uploaded (by Ignacio Rodríguez; author: Ignacio Rodríguez):

[operations/mediawiki-config@master] Restore PageImages functionality to Wikisources and Wikibooks

https://gerrit.wikimedia.org/r/1271862

Just enable the extension, as it is very much better than not having the extension, and inform the communities that this was due to mere negligence for years.

The extension doesn't work with Wikisource according to T323570: PageImages does not consider Wikisource page covers when selecting image. PageImages is not compatible with Wikisource book covers. From my read of the history, it seems like it was disabled because it didn't work as expected across multiple pages. In the interest of moving forward, I think this is fine as it helps surface the bugs better. Just want to ensure there is not an expectation that https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1271862 will be a silver bullet that magically fixes the issue with search... it may make things more confusing by showing unexpected images in search.

Note, the search on Wikisource and Wikibook can be configured to not show thumbnails via $wgMinervaTypeahead and $wgVectorTypeahead. I'd recommend you also set these as part of your change to allow further testing.

The extension doesn't work with Wikisource according to T323570: PageImages does not consider Wikisource page covers when selecting image. PageImages is not compatible with Wikisource book covers.

This is very much not the case. T323570 was open in 2022. PageImages has been disabled in all Wikisources (including en) since 2014. In fact, I suspect it is in reality a duplicate of this very ticket, the root of the problem being that the extension simply wasn't enabled, and not that it is incompatible and can't find the covers.

Note, the search on Wikisource and Wikibook can be configured to not show thumbnails via $wgMinervaTypeahead and $wgVectorTypeahead. I'd recommend you also set these as part of your change to allow further testing.

bnwikisource, which currently has the PageImages extension enabled, show very reasonable thumbnails.

image.png (804×881 px, 202 KB)

Change #1271862 merged by jenkins-bot:

[operations/mediawiki-config@master] Restore PageImages functionality to Wikisources and Wikibooks

https://gerrit.wikimedia.org/r/1271862

Mentioned in SAL (#wikimedia-operations) [2026-04-20T23:32:21Z] <jdlrobson@deploy1003> Started scap sync-world: Backport for [[gerrit:1271862|Restore PageImages functionality to Wikisources and Wikibooks (T417538)]]

Mentioned in SAL (#wikimedia-operations) [2026-04-20T23:34:01Z] <jdlrobson@deploy1003> jdlrobson, ignaciorodrguez: Backport for [[gerrit:1271862|Restore PageImages functionality to Wikisources and Wikibooks (T417538)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-04-20T23:40:08Z] <jdlrobson@deploy1003> Finished scap sync-world: Backport for [[gerrit:1271862|Restore PageImages functionality to Wikisources and Wikibooks (T417538)]] (duration: 07m 47s)

Jdlrobson-WMF claimed this task.

I've backported the change.

It's working on https://en.wikibooks.org/w/index.php?title=Ada_Programming&action=info and https://en.wikisource.org/wiki/A_Young_Volunteer_in_Cuba?action=info

https://en.wikisource.org/wiki/A_Young_Volunteer_in_Cuba/Chapter_15 has an image other than the cover so that's a bit weird.. but an image does show.

I think all pages need to be edited (action=purge) for them to get images. I haven't checked other pages in other namespaces, but if you find any issues you'll need to file new bugs. To set expectations: the PageImages extension does not currently have any code steward so it is unlikely they will be worked on.