Tgr added a comment.
I can see two approaches: - encode the information in the thumbnail URL (similar to how e.g. the thumnail URL of a low-quality JPG would be something like `qlow-123px-Example.jpg`) - encode the information in Swift headers Encoding in the URL has the benefit that - it works in vanilla MediaWiki (which stores thumbnails in a file so it cannot store headers) and thus works on third-party installations and is easier for Wikimedia developers to work with locally; - there is no need to invalidate old thumbails; - there is no state stored outside MediaWiki that could get out of sync and cause hard-to-debug errors; - the code interfaces for it are well-established; - and it also naturally enables overriding these parameters on a per-thumbnail basis (which I guess you can see as a good or bad thing depending on how much you worry about it getting misused) and providing different settings for e.g. in-article thumbnails vs. MediaViewer vs. download. Using Swift has the benefit that you don't need to worry about old not-relevant-anymore thumbnails littering Swift and possibly requiring a custom cleanup script. Also, changing image properties could have an instantaneous effect, if you go the extra effort and purge the old thumbnails from Varnish; if not than the URL-based approach will be the more testable one (as you can change file properties and then purge some HTML page to update it to the new URLs, which is something editors already know how to do). On the whole, I'd go with URLs. If you go with URLs, it would look something like this: - Provide an interface in MediaWiki core for structured image metadata, as core cannot depend on the WikibaseMediaInfo extension. It also needs to be able to access Commons structured data on other wikis which use a Commons file (ie. the ForeignApiRepo and ForeignDbRepo classes no to handle fetching the data from Commons). A similar example is how the GetExtendedMetadata <https://www.mediawiki.org/wiki/Manual:Hooks/GetExtendedMetadata> hook was created so core does not have to depend on the CommonsMetadata extension. This is not a small task but very valuable beyond this specific use case - e.g. it would allow replacing CommonsMetadata (which is an ugly pre-Wikibase hack where Commons templates output metadata as HTML and the file handling logic extracts it), and it's also needed for T213585: Images (on articles, on file/category pages, and in the media viewer) should default to use their structured data alt text when available <https://phabricator.wikimedia.org/T213585> - In JpegHandler & co modify the `makeParamString()` method to access this data and add it to the URL, and modify `normaliseParams()`, `validateParam()` and `parseParamString()` to expect this parameter. Preferably make the default implementation use the new parameter (e.g. have `JpegHandler::transformImageMagick()` pass the appropriate option to ImageMagick) although this is not strictly required. - Optionally define a magic word for the parameter and add it to `getParamMap()` - this will allow overriding the value in wikitext on a per-thumbnail basis. - Update Thumbor to do the same string decoding as `makeParamString()` and modify the output appropriately. If you go with headers, your plan sounds right, with the caveat that there might be many thumbnails for a given file (maybe unlikely but certainly possible) so purging them might need to be an async operation (maybe? I have no idea how fast it is to do mass deletions in Swift; in any case this is also needed for image deletion or reupload so the mechanism probably already exists). I once tried to add Swift file headers based on some MediaWiki property (but did not go through with it in the end), maybe that's useful although the code is pretty old now: T167400: Disable serving unpatrolled new files to Wikipedia Zero users <https://phabricator.wikimedia.org/T167400> T66214: Define an official thumb API <https://phabricator.wikimedia.org/T66214> would be nice but it's an entirely orthogonal problem. TASK DETAIL https://phabricator.wikimedia.org/T253280 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Vlad.shapik, Tgr Cc: Tgr, hnowlan, GFontenelle_WMF, AntiCompositeNumber, Aklapper, 26081981, Astuthiodit_1, karapayneWMDE, Invadibot, Lalamarie69, maantietaja, Y.ssk, FRomeo_WMF, Muchiri124, CBogen, ItamarWMDE, DAlangi_WMF, Nintendofan885, Akuckartz, WDoranWMF, EvanProdromou, Nandana, JKSTNK, jijiki, Jony, Lahi, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Agabi10, Taiwania_Justo, Scott_WUaS, Pchelolo, Susannaanas, Ixocactus, SBisson, Wong128hk, Fuzheado, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Daniel_Mietchen, El_Grafo, Dinoguy1000, Ricordisamoa, Wesalius, Lydia_Pintscher, Raymond, Gilles, TheDJ, Steinsplitter, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
