Also fixed a bug in ParserOutput when no option is used; otherwise getUsedOptions() will return false and throw warnings in ParserOptions::optionsHash().
* Fixed several obvious bugs in the $wgCiteCacheReferences helper functions, missed due to inadequate testing.
* Don't save complete Title objects to memcached, they contain cached data with a short lifetime.
* Fixed a doc comment.
* It was not necessary to preserve the $stripState->general->setPair() interface since it wasn't used by any extensions.
* Moved StripState to its own file.
* Refactored serialiseHalfParsedText() and unserialiseHalfParsedText() so that the bulk of the functionality is in the relevant modules, instead of using scary direct access to object member variables. Made it support the new StripState. It seemed like a lot of work to go to to support an "emergency optimisation" feature in Cite. Cite updates will be in a subsequent commit.
* Fixed spelling of serialiseHalfParsedText() and unserialiseHalfParsedText(), there is unavoidable interface breakage anyway, due to cache object versioning.
* Moved transparent tags to their own function, as requested in a fixme comment.
* Added documentation for markerSkipCallback().
* Removed OnlyIncludeReplacer, unused since MW 1.12.
Only used used when amenableparser is passed; the user can now define the page used for {{PAGENAME}} and related stuff instead of being hardcoded to "API"
Make it so that by default, the parser consdiers categories to have a sortkey of "" unless
specified otherwise. Before, the parser said the sortkey was the page name, and then in LinksUpdate
we reset the sortkey (prefix) to "" if it was the same as the page name.
This way, the parser uniformly outputs the sortkey prefix, instead of a mix between prefix or pagename.
It should be noted, this changes the output of api.php?action=parse for categories that do not have
a sortkey.
As noted in CR there are some issues where we're trading one set of weird behavior for a different, but previously unknown, set of weird behavior which breaks existing markup that works around the old behavior.
I'd recommend keeping this in store for after the 1.17 stuff calms down so unexpected parser changes aren't cropping up in the middle of things for people working with trunk.
If these are the right changes to make then great -- but they should be done after the consequences are better understood and folks can prepare for changes.
Creating a new title in transformMsg() in such case. Reverting r80987 (its revert), and r80898 (workaround).
Confirmed that now both the installer and extensions/Translate/scripts/sync-group.php work.
* Remove the hack from bug 529 which inserts a newline when the template text begins with any block character; this breaks many things in many exciting ways. I've left it in for now when the text begins with a wikitable, as that markup can't be mistaken for anything else.
* Instead, move the contents of a table cell onto a new line for parsing, so that linestart elements (including nested tables) will parse as normal.
This means that structures like
{|
| {{template-containing-wikilist}}
|}
Will still work, but for the right reason, and structures like
{|
| style="color:{{template-containing-hexcode}}" | Foo
| * Bar
| {|
| Look at me, I'm nested!
|}
|}
Will all now start to work. Structures like
* Foo {{template-containing-wikilist}}
Will now not, but honestly, should they?
The space is actually used inside extensions, such as Maps, covertly called as 'display_map' into
Validator, then converted into 'display map' by getName().
Registering a tag hook with < or > on its name resulted in a UNIQ marker.
Spaces, tabs or LF do work (CR fails due to the CR->LF transformation),
but it's easier to also forbid them, just as they are not allowed in other
markup languages.
For environments post r70783, they will need to rerender pages with __NOEDITSECTION__ or no headings (hopefully those will be simple pages).
There will be no extra parser cache misses for environments pre r70783.
Doing this allows skins to override doEditSectionLinks without poluting the parser cache or fragmenting the parser cache more.
As a side effect it eliminates the primary cause of user language based parser cache fragmentation.
Because this makes most old parser cache entries invalid $wgUseEditSectionTokens is provided so that large installations like Wikipedia can keep their old parser cache entries.
has a % sign in it, but interperted as a + if no % sign is present.
This changes how the parser interperts links slightly. However:
*I can't imagine anyone is relying on this behaviour
*Things should be consistent. a + sign shouldn't magically change meaning
if there is a % sign somewhere else in the link.
*Pages are allowed to contain % signs in their title, and + signs,
you should be able to link to such pages just by typing there name without
resorting to %2B.
*If you have a page named foo%+ having [[{{PAGENAME}}]] link to a different
page seems inherently wrong.
*The previous behaviour seemed accidental.
* Removed other usages of $wgUser in Parser stuff, as stated in doc
* Added mechanism to get an User object in Parser, based either on the object given in Paser::preSaveTransform() or the ParserOptions otherwise
