PHP 5.4 includes some pass-by-reference changes which apparently make
the '&' sigil necessary here.
Spotted by Mormegil <mormegil@centrum.cz>. Followup to Ie162535b.
Change-Id: I038fa7f8e1559c95dba7b9b498fc1d1f5eb76887
{{#special:}} should always return a usable title in NS_SPECIAL,
even when given an unknown special page title. Currently, it returns
"No such special page" text for such unknown names, which is
surprising.
Bug: 47449
Change-Id: I7f184956ec9d56c849f201f1230736fcedd0fadf
$wgRestrictDisplayTitle is intended to make it possible to simply
copy-and-paste the title text even if it requires some styling like
subscript or superscript. Using a <span style="display: none;" />
broke that expectation, as the text hidden in such way becomes
completely invisible and unselectable. This patch rejects such styles.
Also disallowed 'user-select' and 'visibility', since they both
prevent the user from selecting and/or copying the text as well.
Minor changes in Sanitizer:
* checkCss() was made to pass through values which consist of nothing
but a single comment, to allow this rejection to display some sort
of a notification to the user.
* encodeTagAttributes() was added as a counterpart to
decodeTagAttributes(), pulling some code out of fixTagAttributes().
Bug: 26547
Change-Id: Ie162535b6bcbebce4ee69f6dcc1957ccccc3c672
Previously, when parsing {{PAGESIZE:{{FULLPAGENAME}}}} or
{{ {{FULLPAGENAME}} }} (a self-transclusion), we used the
version currently in the db, which is outdated because
the moment we save the page there will be a new version.
This often causes confusion when testing templates that
often have examples of template use in the doc section
which would be one version out of date.
This change causes those variables to give results for
the most recent version of the page. For self-templates
that's done by reparsing the page after save. For
self page sizes this is done by taking the size
of the input to Parser::parse.
Note that {{subst:PAGESIZE:{{subst:FULLPAGENAME}}}}
will still yield previous revision like before.
bug: 39590
Change-Id: Idfac13de37d05317f65e4131534543e66cf74873
Introduced a new variable ROOTPAGENAME which has similar
content like BASEPAGENAME.
ROOTPAGENAME only contains the name of the topmost page without namespace, e.g.
for "User:Name/Article/Subarticle" it should be "Name".
BASEPAGENAME would be "Name/Article" here.
Update : fixed indentation in maintenance/fuzz-tester.php
Added to RELEASE-NOTES-1.2.2
Bug: 6747
Change-Id: I71ef0a15c95c9145462f3aa7fdb3ed11dac79265
CoreParserFunctions::anchorencode incorrectly returns false rather than
the empty string when passed an empty string.
A simple cast fixes it; this likely wasn't noticed before since PHP was
automatically doing the cast anyway when the return value was merged
into wikitext.
Bug: 46608
Change-Id: I97556dbc4dcc1f102f6fed499d43dada388cdc5d
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
Also moved the retrieval of the revision ID near the one of the
page ID so that the call of ParserOutput::addTemplate() is much
clearer than the actual one.
Change-Id: Ie71ee76e90cc131eac25c0f339d5250d5163ce2e
* Also normalized 0 => false for the rev ID parameter in some places.
* Broke some long lines and shorted a variable name in Skin.php.
Change-Id: I6645315699ec7670ae22aa1dbf787d75d6e6b7ec
Using the same regex like [[File:|]]
With heigth, the width inside the thumb link can be calculated, if the
height not fit in the width.
Change-Id: If188d923d6cd25ea6a5118098f3a513ca5135d43
Add a lang parameter to DateFormatter so it can work in any language instead of only the site content language.
(The memcached key is now per language code.)
Use by default parser->getTargetLanguage() so it is parsed in the page content language by default.
Also add some documentation and remove unneeded whitespace.
If needed, a parameter to {{#dateformatter}} can now be easily added, to specify the language to format in.
Change-Id: If61854920065f7c3b4170ab89e9aa66b299f9dd8
This reused the gender state of a user on a page. This is helpful for
special pages which shows the group name, because the each group name
used gender, which result in often use.
Change-Id: I8e816f54aaa100c3333e84e19299fd194323341d
Also add explicit Title::getPrefixedText() in
CoreParserFunctions::special, so that method does not rely on
Title::toString.
Change-Id: I1d041b11386bff15811e19de47a662e5ed7a2b07
* Introduced Parser::killMarkers() based on the concept from StringFunctions. Used it in cases where markerStripCallback() doesn't make sense semantically, namely grammar, padleft, padright and anchorencode. Used markerStripCallback() in other cases.
* Changed headline unstrip order as suggested by P.Copp on bug 18295
* In CPF::lc() and CPF::uc(), removed the is_callable(). This was a temporary testing hack committed by me in r30109, which allowed me to do differential testing against a copy of the parser from before that revision.
* Reduces the overly long code in r107002, and reduces code for {{#language:}}
* Fixes the language list in Special:Translate which contained languages that gave "invalid code" when selecting
* ParserOptions::getUserLang() will still return a string for compatibility, added ParserOptions::getUserLangObj() to get the object
* Added ParserOptions::newFromUserAndLang() and ParserOptions::newFromContext() to easily get a ParserOptions object when a context is available or when someone wants to force the language
* Updated OutputPage and Preferences to use newFromContext() and WikiPage to use newFromUserAndLang()
* ParserOptions::setUserLang() still accepts either a string or a Language object, but changed the calls to pass an object instead of a string
* Changed Parser::getFunctionLang() to return the Language object from ParserOptions when parsing interface messages rather than $wgLang directly and updated the documentation to say that $wgLang should not be used directly (as $wgUser, $wgTitle and $wgRequest)
to in both cases prevent the "A sortkey already was specified earlier in the page, yadda yadda" message and in the second case, also do not replace the sortkey
if one was already specified.
* Introduce $wgCanonicalServer, which should typically be a fully qualified version of $wgServer but in practice can be anything that you'd like to be used in IRC/e-mail notifs
** Default value is $wgServer, expanded to http:// if protocol-relative
** This means you can easily set HTTPS as the 'default' protocol to use in IRC and e-mail notifs by setting $wgCanonicalServer to https://example.com
* Introduce Title::getCanonicalURL(). Similar to getInternalURL(), including a hook for WMF usage (which will be needed as long as secure.wikimedia.org is used)
** Also add escapeCanonicalURL(). Due to some ridiculous accident of history, the other escapeFooURL() functions don't have a $variant parameter; I decided not to follow that bad example
* Reinstate the spirit of r44406 and r44412: instead of calling getInternalURL() (or getCanonicalURL()) and regexing the title parameter out, obtain the path to index.php using $wgCanonicalServer . $wgScript and append params to that. Sadly, we need to add a hook here to support the secure server hack for WMF, but that's the price of saner code in this case
* Introduce the {{canonicalurl:}} and {{canonicalurle:}} parser functions, which work just like {{fullurl:}} and {{fullurle:}} except that they use getCanonicalURL() instead of getFullURL()
* Use {{canonicalurl:}} in the enotif_body message, fixing bug 29993 (protocol-relative URLs appear in e-mail notifications)
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.
* MessageCache::singleton() calls wfGetMessageCacheStorage() directly instead of using $messageMemc, just in case this would be called before that variable is set
* Per TimStarling: also removed deprecated methods in MessageCache class: addMessages() and related, [get|set|enable|disable]Transform(), loadAllMessages(), loadMessageFile() and some others. Same for the legacyData stuff in LocalisationCache that was only used by MessageCache::addMessages() and related.
* Converted remaining extensions
* 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
** DISPLAYTITLE now parses the single-quote items of wiki markup (bold and italic).
** Remove UNIQ markers from the output due to people putting tags in there (nowiki, ref, etc.).
** Forbid hr and br elements from being in DISPLAYTITLE as well.
* Save a query by not using User::edits()
* Mark as an expensive function (it needs at least 1 query for each use)
* Use number formatting/raw option rather than pointless wfEscapeWikiText()
* re-add $wgRestrictDisplayTitle
* revert r49610
* prevent block-level and other such tags from being used in DISPLAYTITLE (while still allowing tags such as <sup> and <sub>)
Doesn't seem to be a compelling reason to add this special-case restriction at this time, and there appear to be ways to work around it anyway, so let's not play the arms race. :)
Behavior seems a bit hard to predict, as far as what's going to go in the header and what in the browser window etc. Pulling it back for further testing and discussion.
* Use wfMsg to show error message in user preference language. wfMsgForContent does not make sense
* Rename new message name to MediaWiki code standards. Use dash and not underscore
I don't really like this in general; the API isn't meant for the UI and there should be little to no call to link to it from body content.
Additionally, I believe we're trying to move all new parser functions to the convention of using the # prefix to avoid conflict with the template namespace.
This implements an mb_str_pad fallback function, but there is no mb_str_pad in PHP documentation, and the doc comments are really weird -- it says it returns an integer!
If this function is created from whole cloth and doesn't exist in PHP, it should be given a MediaWiki style name and not be done with a function_exists check as though it were a compat function.
