We really need tests to pass when all wmf extensions are installed together. That is preventing us from progression toward the HHVM migrating. Raising priority to High.

Sounds like those tests are too rigid. Maybe they could use some sort of DOM parsing and then check only for the elements which are actually used by the Cite extension, instead of trying to match the exact HTML.

As a more fragile but simpler solution, just replace the parts between <ul>...</ul> with .*? and do a regex match.

A bit more detail.

The MultimediaViewer extension registers ThumbnailBeforeProduceHTML , which injects additional elements to the thumb <img> element such as:

data-file-width="1941" data-file-height="220"

Cite on its own has now knowledge about that.

A hack would be to have Cite parser tests to clear up registered ThumbnailBeforeProduceHTML hooks and restore them after. I am wondering whether that sounds acceptable, should I raise the issue on wikitech?

I found out ProofReadpage inserts additional data that badly interact.

A test result with most WMF extensions installed can be found at https://integration.wikimedia.org/ci/job/mediawiki-core-extensions-integration/65/testReport/

Modifications to the parser like this will most likely never be supported in Parsoid, and they also make html output less consistent between wikis, and its imho a bad practice anyway.

I'd recommend finding another way to communicate this data or justify its general usefulness and put it in mediawiki-core.

If that's too complicated for the short term, the test could be simplified by either using a regex for the html output (with wildcards for additional attributes), as implementing a DOM tester is fair amount of extra overhead that requires research/implementation that is unlikely to be devotes to such a minor thing.

Unregistering the hook should be a last resort as it is effectively the same as not running the tests with extensions installed, which is exactly the opposite of what bug 67216 tries to achieve. Such change should leave a FIXME comment and file a bug.

• Bug 68649 has been marked as a duplicate of this bug. ***

Lets rephrase the bug. The MultimediaViewer extension register a thumbnailBeforeProduceHTML hook which ends up breaking other extensions parser tests because the HTML is altered.

We can make parser tests to support regex and adjust the expected HTML with some wildcard regex.

Change 151833 had a related patch set uploaded by Hashar:
Support regex to match parser tests output

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

Ehm, how about we just add:

!class_exists( 'ParserTestResult' )

around the block that adds these elements in to DOM ?
It's what I've been doing locally for a while now, because I'm so annoyed by them.

Or use the ParserTestParser Hook to flip a switch on a variable for the extension.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

Is this still breaking things?

Is it still a high priority?

In T69302#1669113, @Jdlrobson wrote:

Is it still a high priority?

Yes, unless T69216 suddenly stopped being a goal and/or MultimediaViewer stopped being something we want to test.

@Nemo_bis MultimediaViewer does get tested, just not alongside all other extensions on Jenkins, so your comment doesn't make sense to me in that respect.

I cannot comment about whether T69216 is still a goal - @hashar is this something the Release Engineering team is pushing for this quarter? MultimediaViewer is not a focus for Reading web in this quarter, but I can make sure this gets attention if T69216 is a focus.

In T69302#1690220, @Jdlrobson wrote:

I cannot comment about whether T69216 is still a goal - @hashar is this something the Release Engineering team is pushing for this quarter? MultimediaViewer is not a focus for Reading web in this quarter, but I can make sure this gets attention if T69216 is a focus.

It's an unfunded goal, if that makes any sense :) IOW: it's not on our Q2 plan, per se: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Goals/201516Q2

We still are, however, constantly striving for improvement there and along other vectors, eg: T87781 and others.

I still don't think this is MediaViewer's problem. Extensions should not assume exact output in their tests. The Cite test is failing on the exact same output it will produce in the WMF cluster. What is the point of testing all WMF extensions together if not testing what output they will produce on the cluster?

In T69302#1695544, @Tgr wrote:

I still don't think this is MediaViewer's problem.

It's a problem in that it makes its testing harder. :-)

Extensions should not assume exact output in their tests.

Well, they do, and core does too. This is a general problem, see http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077481.html

T69216 is on stall since January 2015. Mainly because I am distracted with a lot of other things. But we should probably resurrect it with a limited scope such as only extensions deployed on Wikimedia.

In theory the job could fetch the list of deps from mediawiki/tools/release/make-wmf-branch and use that as a list of repo to clone and branches to fallback to.

As this task is 2 years old, and hasn't been touched since October 2015, it will be closed. Please (politely) re-open the task if it remains an issue. :)

I think it makes sense, it catches the tasks which have long been fixed / made invalid but nobody noticed. But yeah, this is not one of them.