Parser cloning - MediaWiki-l

18 Jun 2013

Recently I encountered what I thought was a bug in my code, but it turned out to be
something much more interesting.

First, some background:
Here at Vistaprint we have a number of custom extensions written for our
internal-documentation wiki. One of those categorizes articles programmatically - you call
it from the code and it will auto-categorize the page. Something along the effect of:
       $c = new Categorizer;
      $c->addToCategory( 'my-message-key' );

Whenever this code was called it broke the Cite extension. Specifically, anything defined
with <ref></ref>  would not show up in the <references /> section below.
Doing some digging I found this issue:

1.       Our custom extension parsed a message in the middle of a page (while the page was
being parsed in the code)

2.       Parsing a message called MessageCache::parse, by way of wfMessage() and the
Message object

3.       The MessageCache object clones the global parser and parses the message

4.       Parsing the message means that the (cloned) parser calls Parser::clearState

The problem is that calling Parser::clearState() on the cloned parser object (a property
of MessageCache) also clears the state of the global parser object. This might be due to
two things:

1.       PHP makes shallow-copies of objects when cloning and not deep-copies [1].

2.       When the Cite extension inserts itself into a parser it sets up a callback to the
'ParserClearState' hook. When this callback is run, because of #1 (no
deep-copying) it effectively gets run for all clones of the parser.

This is arguably a bug in MediaWiki: cloning a parser does not create a totally separate
object with its own state. I have found a number of bug-reports that seem to be related to
this issue [2][3][4]. Before I go off and submit a bunch of code, I'd like the input
from the community.

Thoughts?
-Daniel       ( User:DanielRenfro )

References:
[1] http://php.net/manual/en/language.oop5.cloning.php
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=34589
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=32368
[4] https://bugzilla.wikimedia.org/show_bug.cgi?id=47291