There are some extensions relying on global parser state to do their job by effectively creating pagewide globals. This openly contradicts the goals of the Parsoid team, however, they are popular and widely used nevertheless.
These extensions all want to do similar things:
- store arrays of some sort of data in the parser
- be reset onParserClearState
- be deep cloned whenever the parser is cloned
- mark the current parser frame as volatile whenever they are accessed, as invalid parsing results are produced otherwise.
- This is the only point on this list that might actually be hard to do at the moment. I'm still not entirely sure how to do so in general, or if this is even possible with the current MediaWiki core, but it would resolve so many inconsistencies with these extensions.
- maybe get the values of these information after parsing is finished (Variables does this, and it should be handy for Arrays as well.)
- hopefully somehow continue to work if the WMF is unifying MediaWiki-Parser and Parsoid. I didn't test it, but I think VisualEditor and these extensions aren't really compatible these days.
I think instead of implementing these functionality over and over, there should be a unified library used by these extensions providing all of this functionality instead, so they don't have to be updated individually when parser behavior changes and bugs can be fixed in a central place.
I currently have something like this in mind to be injected in the different main or Store classes of these extensions, so access would be controlled by these classes:
interface IParserStore {
// these allow you to access data directly. They are needed especially if you want to save all information somewhere.
public function getData() : array;
// these mirror functionality these extension use in some way or another.
public function getValue( string $key );
public function setValue( string $key ) : void;
public function keyExists( string $key ) : bool;
public function unset( string $key) : bool;
public function holdsData() : bool;
}Handling this finalized value functionality should be the task of an additional class however, that I didn't really think about yet. Plase note I expect MediaWiki HHVM support to be dropped before this reaches production wikis, so this is using scalar type hints.