* Parser now only adds the redirect source to imagelinks, like it does in pagelinks
* ImagePage now shows the file redirects in-line with the normal "The following pages link to this file:"
** Added message linkstoimage-redirect
** Removed the separate file redirects section and removed associated message redirectstofile
** ImagePage::imageLinks will first fetch image links to the file, determine which are redirects, and if there are fewer links than the limit, fetch the redirect target links.
Added notes about the 'extended' return values from some of the hooks, which seems to be undocumented but is vaguely similar to what is documented for parser function callbacks. It doesn't look like a very safe interface, and could stomp on internal variables if one isn't careful. Needs to be better defined and doc'd.
setTransparentTagHook() seems to have been largely undocumented and is only used by the 'geoserver' extension currently. Is this considered obsolete? Should it be simply replaced by use of the frame & recursiveTagParse goodies, or is it still needed for something?
* (bug 16129) Transcluded special pages expose strip markers when they output parsed messages
Also adding some related documentation during my travels around the code
Also make a few changes to the functions available. SpecialPageFactory::resolveAlias() now takes an optional subpage and returns array(<name>,<subpage>). Similarly merge getPage() and getPageByAlias(). There were many examples of (extensions particularly) making dubious assumptions about the presence or absence of subpages or canonical-ness.
I didn't deprecate SpecialPage::getTitleFor() as it's got over six hundred calls. I'm rather undecided on the best position of getPage()/executePath(). Although the latter needs cleanup anyway.
* (bug 14202) $wgUseTeX has been superseded by the Math extension. To re-enable
math conversion after upgrading, obtain the Math extension from SVN or from
http://www.mediawiki.org/wiki/Extension:Math and add to LocalSettings.php:
require_once "$IP/extensions/Math/Math.php";
This is an initial stab, and a few things remain to be cleaned up:
* messages need to be moved from core to extension
* MW_MATH_* constants should be moved to the extension from core
* old back-compat math names interfaces using those constants should be removed from message files
* classic edit toolbar's math button should be added from the extension (or else dropped) -- currently there's not a clean hook, but could do it by JS
* couple of things like the 'armourMath' function on Language & LanguageConverter may want to be redone just as an unconditional, if that's simpler.
Setting $wgUseTeX alone will no longer have any affect. The var's still there for the moment as a few bits still need to be fully moved out from core.
* Made FlaggedRevs specify files by sha1,timestamp to handle renames with no redirects. This makes them handled as well as templates in this regard. (bug 27836)
* Moved BeforeGalleryFindFile hook to proper place (don't trigger for non-NS_FILE titles)
* Removed unused mRevisionId field from ImageGallery
* Removed old hotfix from makeMediaLinkObj(); all the current callers would crash beforehand if the title was null anyway
* Updated hook docs (some prior params were missing)
* Broke some long lines and cleaned up some whitespace
* TODO: track file info in core rather than fr_fileSHA1Keys and ugly, duplicated, queries. This should be easy to do now.
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
The issue is, php strtolower() calls tolower(3), which is locale sensitive.
Eg. LC_ALL='pt_BR.ISO-8859-1' php -r'echo strtolower("ÉÁÇÚÍ");'
Adding a call to setlocale(LC_ALL,'C'); in Setup.php may be a good idea.
None of the 3 globals based on it changed if you set it in LocalSettings.
Note that all those !isset( $wgServerName ) in ApiTests were useless, since if not in LocalSettings it would be 'localhost', not null (as still are those !isset( $wgServer )).
sed -i 's/$wgContLanguageCode/$wgLanguageCode/g'
These are now the same, always. Per and since r15827.
$wgLanguageCode wins due to being the one set by LocalSettings.
$wgContLanguageCode definition at includes/Setup.php kept for now.
use the same parsercache entry for articles without <math> tags.
The cache key format is kept as a fallback so the old cached entries can be reused.
Should boost parsercache hits, but it also makes easier to pollute the parsercache by tag hooks that behave
badly, directly using $wgUser or $wgLang.
Extensions hooking PageRenderingHash now see !edit=0 and the !printable=1 bits.
Fixes bug 24714 - Usage of {{#dateformat: }} in wikis without $wgUseDynamicDates can lead to unexpected results
Builds upon r70498, r70498, r70501, r70517, r70651, r70653, r70765, r70780.
Now works (again?) in IE6. That didn't like getting non-legacy ID's on
redirects -- it doesn't interpret them as UTF-8, so anything non-ASCII
breaks. If this works in all the browsers I test in, I'll enable it --
it will produce *much* nicer-looking anchors for non-English wikis, and
also section names with English punctuation.
Follow up r48544. Init ParserOptions::mIsPrintable in initialiseFromUser()
Move the "No edit section it's printable" from Parser to Article.
This leaves getIsPrintable() unused. Left there for extensions (none seems to be using it, could be removed).
The "even if the user has them on" comment wasn't accurate. The user preference only controls them via CSS.
Anyway, it would work as expected now if it got moved into ParserOptions. The setEditSection() no longer set it to true.
Remove the quickUserCan( 'edit' ) which is just a hidden way of calling $wgUser from the Parser to be explicitely
done in Article to disable the editsection. This results in quickUserCan being called once instead of twice if $wgUseETag == true;.
This is html neutral, but helps the parser to realise that things should be broken there.
Fixes the tag nesting issues of the [ftp://|x||]] parser test.
Parser16 test still has its own tag bug.
In response to feedback by Phillipe Verdy on bug 164. Now if a bunch of
pages have [[Category:Foo| ]], they'll sort amongst themselves according
to page name, instead of in basically random order as it is currently.
This also makes storage more elegant and intuitive: instead of giving
NULL a magic meaning when there's no custom sortkey specified, we just
store an empty string, since there's no prefix.
This means {{defaultsort:}} really now means {{defaultsortprefix:}},
which is slightly confusing, and a lot of code is now slightly
misleading or poorly named. But it should all work fine.
Also, while I was at it, I made updateCollation.php work as a transition
script, so you can apply the SQL patch and then run updateCollation.php
and things will work. However, with the new schema it's not trivial to
reverse this -- you'd have to recover the raw sort keys with some PHP.
Conversion goes at about a thousand rows a second for me, and seems to
be CPU-bound. Could probably be optimized.
I also adjusted the transition script so it will fix rows with collation
versions *greater* than the current one, as well as less. Thus if some
site wants to use their own collation, they can call it 137 or
something, and if they later want to switch back to MediaWiki stock
collation 7, it will work.
Also fixed a silly bug in updateCollation.php where it would say "1000
done" if it did nothing, and changed $res->numRows() >= self::BATCH_SIZE
to == so people don't wonder how it could be bigger (since it can't, I
hope).
Not only should this have used setContainsOldMagic() instead of manually modifying the member,
the outdated magic reduced the caching time to one hour even if you just used something like
{{currentmonth}}, which is hinted to one day.
This is the only usage of old magic, we could remove it but perhaps it is used by some extension?
Pretty italics mean that italics go across links: ''Some [[Link|pretty ''italics'' and stuff]]! -> ''Some [[Link|pretty ''italics'' and stuff]]! -> <i>Some <a>pretty <i>italics</i> and stuff</a>!</i>
This also fixes bug 24093, where interface messages saying '''[[$1]]''' has been deleted/renamed/links here were being bitten by this feature.
The best resolution would be to make pretty italics still work inside alternates, feel free to do so, but doesn't seem worth at this point. The right solution should be to rewrite the quotes handling so it takes its scope into account.
Changed what used to be EXT_LINK_TEXT_CLASS to
define( 'EXT_LINK_TEXT_CLASS', '[^\]\\x00-\\x08\\x0a-\\x1F]' );
In plain English, do not allow control characters in description. We still allow tabs
there, since they may arrive from a paste.
We should probably make the space between the text and the description mandatory, it needs testing.
These tests only work with the Hash Preprocessor, since the DOM Preprocessor changes them into the
replacement character. Should we autolink an URL with a FFFD? That will require changing some regex
into unicode ones.
Like langlinks, this stores the interwiki prefix (as iwl_prefix) and full page title (as iwl_title), attached to the page doing the liking (as iwl_from -> page_id).
Unlike langlinks, there can be multiple entries stored per interwiki prefix.
Updater to add the table confirmed on MySQL, untested on SQLite but should work.
Someone may still need to add and test a PostgreSQL updater.
Refactored makeWhereFrom2d() out of LinkBatch to Database so it could be re-used for the similar mapping for the interwiki links, which need a string prefix rather than an int namespace key.
Also cleaned it up internally to reuse existing code for building where clauses from arrays. (Tim & Domas -- if the previous more verbose code was there to reduce function call and array processing overhead on very large link lists, feel free to unroll it again if the difference is measurable. Just swap the var names around from the old LinkBatch code and escape the base key value if it's not an integer, it'll be functionally equivalent.)
* Moved the responsibility for calling $wgOut->setPageTitle() from OutputPage::addParserOutputNoText() to the OutputPage/Parser caller. Previously, every call to $wgOut->addWikiText() (or any other message parsing function) was resulting in the title being reset to a converted version of $wgTitle, producing bug 23124. Moving responsibility to the caller seems to work fairly well, since there are apparently only two callers that really want {{DISPLAYTITLE}} etc. to work (EditPage and Article::view).
* Reverted data flow obfuscation in OutputPage::setHTMLTitle() from r64851, replaced by the above. The caller decides what overrides what.
* Reverted inappropriate, cache-polluting references to $wgUser and $wgRequest in Parser::parse(), introduced in r64819.
* Reverted incomprehensible boolean parameter to Language::convert() from r64851, reintroduced Language::convertTitle() instead. Gave it a simpler implementation than before.
* Fixed broken {{DISPLAYTITLE}} feature, was being unconditionally overwritten by the ParserOutput::setTitleText() call in Parser::parse(). Give {{DISPLAYTITLE}} precedence over autoconverted title, like we do for -{T|...}-.
* Tested extensively (perhaps not exhaustively)
Bug 22905. Patch based on one submitted by Solitarius. Basically, we
were assuming that anything matching <a.*?</a> was a link and ignoring
it so as to avoid nested links, but that matched the HTML from
<abbr>(fr)</abbr> ISBN 2753300917 [http://www.example.com example.com]
so the ISBN didn't work. Parser test committed, fails without the
Parser.php change.
* In MagicWordArray::matchStartAndRemove(), fixed the case where the length of localised synonym is not precisely the length of the magic word ID plus one
* Fixed the case where matchStartAndRemove() removes the entire string, send empty string not false
* Fix brace style
* Extended the return interface for tag hooks in a way analogous to the one for parser functions, allowing <nowiki> and <html> to specify that they want to be in the nowiki replacement array instead of the general replacement array.
* Removed ParserOptions::setUseTeX() and related. If <math> is going to be registered in firstCallInit(), then it needs to be stable across multiple parser calls and not change based on parser options. Only one extension caller.
In parserTests.inc:
* Fixed parser test failures due to $wgMathDirectory not being properly set up. The math directory of the host wiki was being used, leading to a parser test failure if it was not writable.
* Fixed message cache hack from r15502. Made parser tests not fail in the case where a tested message is overwritten by the local wiki. All tests now pass on my installation.
Renamed setting to $wgExperimentalHtmlIds, off by default, and updated
the code to enforce the much laxer HTML5 rules. Still needs testing in
various browsers.
