Last modified: 2013-03-13 12:41:54 UTC
Created attachment 11318 [details] The patch to add a new hook, 'ThumbnailBeforeProduceHTML', to ThumbnailImage::toHtml method, in order to permit the user to manipulate the image attributes before the HTML is rendered We ran into this when trying to ensure that the images get updated promptly when the user uploads a new file. Browsers tend to overcache, and MediaWiki seems to currently offer no facilities to address this, though there are come future plans to add file versioning. Our (Knowledge Management group at Vistaprint inc.) proposed solution is to add a new hook, 'ThumbnailBeforeProduceHTML', to ThumbnailImage::toHtml method. This would allow the user to edit the src attribute and append a timestamp parameter to it when the file's mtime changes. We have implemented and tested this solution internally, and it works as intended. The patchfile is attached.
You should also add some documentation for this hook to docs/hooks.txt
Created attachment 11319 [details] The documentation patch for the ThumbnailBeforeProduceHTML hook As requested, the patch for the docs/hooks.txt file.
I made a patchset for you https://gerrit.wikimedia.org/r/#/c/32189/ Please consider making an account on gerrit so you can do this yourself in future, it enables you to get code review faster. http://www.mediawiki.org/wiki/Developer_access
(In reply to comment #0) I already made a gerrit patch for you, but your patch seems to have some errors which I don't know how to fix. Please see https://gerrit.wikimedia.org/r/#/c/32189/
Created attachment 11468 [details] The FIXED patch to add a new hook, 'ThumbnailBeforeProduceHTML', to ThumbnailImage::toHtml method, in order to permit the user to manipulate the image attributes before the HTML is rendered I removed the cargo-cult wrap around the hook call. Due to the nature of the hook, no special processing is needed in case one of the hook calls fails.
Victor: Thanks for the updated patch! Did you have time / are you interested in getting developer access? See http://www.mediawiki.org/wiki/Developer_access
I already received commit privileges, but frankly I simply don't feel qualified to make commits directly yet. I will likely do so at some point in the future, but for now I feel it safest to let those far more qualified than I handle the logistics around getting the code into the codebase.
Victor: Gerrit is not about committing directly. It's also a review tool for patches, that's why I asked if you could put patches there.
(In reply to comment #7) > I already received commit privileges, but frankly I simply don't feel > qualified > to make commits directly yet. You don't have to be qualified for this, you won't be changing the code directly but putting up code for review for other "qualified" developers. Also not sure why this bug is now marked Unconfirmed
(In reply to comment #9) > Also not sure why this bug is now marked Unconfirmed There's nothing in the history about it, must've always been unconfirmed.
(In reply to comment #10) > There's nothing in the history about it, must've always been unconfirmed. New+enhancement sounds better to me.
I am not sure why it's a bug... it's an improvement. The functionality prior to this patch was not broken, merely absent. yea, new enhancement should be the proper classification for this patch.
Everything in Bugzilla is a 'bug', even when it's actually an enhancement request. :)
https://gerrit.wikimedia.org/r/#/c/32189/ was merged on December 23, 2012. Hence I'm closing this as FIXED as I cannot see anything left to do for this request. Please reopen if I'm wrong, and elaborate what's left.
