Is there any easy way (via extension) to modify the "src" attribute of images on wiki pages?
I see hooks for modifying href values - LinkBegin and LinkEnd. But I don't see something similar for images, whose URLs seem to be produced via File::getUrl().
Purpose: I want to add a querystring parameter onto the ends of the URLs, turning <img src="foo.jpg"/> into <img src="foo.jpg?timestamp=xxxxxxxxxxx"/> to aid with caching.
Thanks, DanB
On Wed, Oct 31, 2012 at 6:53 AM, Daniel Barrett danb@vistaprint.com wrote:
Is there any easy way (via extension) to modify the "src" attribute of images on wiki pages?
I see hooks for modifying href values - LinkBegin and LinkEnd. But I don't see something similar for images, whose URLs seem to be produced via File::getUrl().
Purpose: I want to add a querystring parameter onto the ends of the URLs, turning <img src="foo.jpg"/> into <img src="foo.jpg?timestamp=xxxxxxxxxxx"/> to aid with caching.
There's not a great hook point for this I think, but you could probably add one in.
ThumbnailImage::toHtml() in includes/media/MediaTransformOutput.php is the function that actually produces the <img> tag. You could probably stash something there, or on the constructor for the class, to modify the URL.
-- brion
31 Октябрь 2012 г. 21:34:25 пользователь Brion Vibber (brion@pobox.com) написал:
On Wed, Oct 31, 2012 at 6:53 AM, Daniel Barrett danb@vistaprint.com wrote:
Is there any easy way (via extension) to modify the "src" attribute of images on wiki pages?
I see hooks for modifying href values - LinkBegin and LinkEnd. But I don't see something similar for images, whose URLs seem to be produced via File::getUrl().
Purpose: I want to add a querystring parameter onto the ends of the URLs, turning <img src="foo.jpg"/> into <img src="foo.jpg?timestamp=xxxxxxxxxxx"/> to aid with caching.
There's not a great hook point for this I think, but you could probably add one in.
Custom hooks are quite hard to get into "master" repository, unless one is a Wikimedia programmer. I had one custom hook in EditPage, used by my extension; however it wasn't possible to include it into core.
ThumbnailImage::toHtml() in includes/media/MediaTransformOutput.php is the function that actually produces the <img> tag. You could probably stash something there, or on the constructor for the class, to modify the URL.
I use the following trick to get thumbnail html (albeit with surrounding div's)
if ( $wgParserConf['class'] !== 'Parser' ) { die( 'Extension:PrettyPhoto cannot override non-default Parser' ); } $wgParserConf['class'] = 'PrettyPhotoParser';
class PrettyPhotoParser extends Parser {
function makeImage( $title, $options, $holders = false ) { return PrettyPhoto::apply( parent::makeImage( $title, $options, $holders ) ); }
} /* end of PrettyPhotoParser class */
Where extension's own PrettyPhoto::apply() method modifies content of generated image html via DOMDocument / xpath.
What bothers me, how much reliable parser class override is.
However, if another class "factories" were as flexible as Parser factory, one could imagine something like this: $wgDefaultClass['ThumbnailImage'] = 'MyThumbnailImage';
class MyThumbnailImage extends ThumbnailImage { function toHtml( /* args */ ) { $html = parent::toHtml( /* args */ ); ... } }
I wish PHP has "monkey patching", so classes could be manipulated and extended dynamically but unfortunately it does not. __get(), __set(), __call() are optional and quite slow. Dmitriy
Also I wish it was possible to extend (and perhaps to define) classes via variable values:
class $myParser extends $wgParserConf['class'] { ... } $wgParserConf['class'] = $myParser;
Such way, multiple extensions could nest (override) default class. Even monkey patching is not so much needed then. Should probably be possible via eval(), however eval() is a hacky way. Perhaps a great idea for PHP 5.5. Dmitriy
Also I wish it was possible to extend (and perhaps to define) classes via variable values:
class $myParser extends $wgParserConf['class'] { ... } $wgParserConf['class'] = $myParser;
Such way, multiple extensions could nest (override) default class. Even monkey patching is not so much needed then. Should probably be possible via eval(), however eval() is a hacky way. Perhaps a great idea for PHP 5.5. Dmitriy
On 01/11/12 06:37, Dmitriy Sintsov wrote:
Also I wish it was possible to extend (and perhaps to define) classes via variable values:
class $myParser extends $wgParserConf['class'] { ... } $wgParserConf['class'] = $myParser;
Such way, multiple extensions could nest (override) default class. Even monkey patching is not so much needed then. Should probably be possible via eval(), however eval() is a hacky way. Perhaps a great idea for PHP 5.5. Dmitriy
We have one eval in MediaWiki for doing something like that. (tests/phpunit/includes/parser/MediaWikiParserTest.php)
If properly argued, it _should_ be simple to get a new hook added, though.
3 Ноябрь 2012 г. 2:00:47 пользователь Platonides (Platonides@gmail.com) написал:
On 01/11/12 06:37, Dmitriy Sintsov wrote:
Also I wish it was possible to extend (and perhaps to define) classes via variable values:
class $myParser extends $wgParserConf['class'] { ... } $wgParserConf['class'] = $myParser;
Such way, multiple extensions could nest (override) default class. Even monkey patching is not so much needed then. Should probably be possible via eval(), however eval() is a hacky way. Perhaps a great idea for PHP 5.5. Dmitriy
We have one eval in MediaWiki for doing something like that. (tests/phpunit/includes/parser/MediaWikiParserTest.php)
Interesting, thanks for the path.
If properly argued, it _should_ be simple to get a new hook added, though.
Monkey patching or dynamic class names (if were properly available w/o eval) probably will have better performance than adding more hooks. Also I wish another classes would be instantiated as fiexible as Parser, via $wg* setting. Dmitriy
wikitech-l@lists.wikimedia.org