Last modified: 2014-10-03 08:13:36 UTC
This was reported on mediawiki-l: https://lists.wikimedia.org/pipermail/mediawiki-l/2014-August/043248.html I'm able to reproduce it on MediaWiki 1.23.2 with both the 1.23 and master versions of dumpHTML. It looks like this was caused by a visibility change in https://gerrit.wikimedia.org/r/#/c/97371/
FileRepo properties have been changed to protected with by https://gerrit.wikimedia.org/r/97371 de6b4e7c which is in both REL1_23 and REL1_24 The extension needs to use the accessor instead: FileRepo->getThumbScriptUrl()
(In reply to Antoine "hashar" Musso from comment #1) > FileRepo properties have been changed to protected with by > https://gerrit.wikimedia.org/r/97371 de6b4e7c which is in both REL1_23 and > REL1_24 > > The extension needs to use the accessor instead: > > FileRepo->getThumbScriptUrl() DumpHTML doesn't read these properties, it writes them. https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FDumpHTML/0df55f1c89b8c802dcd162b918fbd5fb1c35ab9a/dumpHTML.inc#L1157
So I guess whatever *Repo class is used should pass the option 'thumbScriptUrl' which defaults to $wgThumbnailScriptPath , or override $wgThumbnailScriptPath . On initialization that would set the protected property FileRepo->thumbScriptUrl.
I know this will be regarded as a rhetoric question, still: Why not just revert the patch that introduced the bug?
(In reply to s7eph4n from comment #4) > Why not just > revert the patch that introduced the bug? I don't know why, but I'll note this question for dumpHTML is not new, it's several years old; see e.g. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/51857/match=dumphtml I'd trace the issue back to when it was split out of core :) (article.gmane.org/gmane.science.linguistics.wikipedia.technical/38065 ).
