Last modified: 2012-07-19 14:49:23 UTC
r96617: "Apparently API exposes this, and adding it in wiki text produces a "blue" link indicating it exists." meta=siteinfo is showing a alias for an non-existing special page. The API is calling Language::getSpecialPageAliases() which does not check for existing of a special page and contains the alias of non-existing special pages. I am not sure, if it is the best, to add a exist check to the meta=siteinfo or Language::getSpecialPageAliases(), because I am not knowing if a caller needs this information or it is also a bug for other callers. The problem with the blue link is alreay fixed with 1.18, because SpecialPageFactory::exist resolved first the alias and than check the special page. Under 1.17 SpecialPage::exist is checking the canonical name and the aliases with a or and gives true for this case. A other way is, to fix this by loading the files the other way round and does not merge aliases into the array, if the canonical name is not in the english message file. Thanks.
My own inclination would be "don't add aliases for things that don't exist"... but there may be circumstances where this is legitimate, such as special pages that are conditionally registered but that need to be aliased from the locale files. But... conditional registration just seems like a bad idea. :) The case here seems to have been something that maybe got removed or something so not an actual 'live' page...
(In reply to comment #1) > but there may be circumstances where this is legitimate, such as special pages > that are conditionally registered but that need to be aliased from the locale > files. Like Special:Popularpages (see $wgDisableCounters). A wikilink under 1.17 is blue, but under 1.18 it is red, due to the changed exist check. That is ok. But under 1.18 it is exposed by the api, because it is defined in the message files and returned by Language::getSpecialPageAliases(). MediaWiki needs a existsCanonical (or similar) to do a cheaper exist check against a realname of a special page. This can than used by the api or Language::getSpecialPageAliases() or you are make array/object magic with SpecialPageFactory::getList() and the array from Language::getSpecialPageAliases()
siprop=magicwords shows also aliases for non existing parser functions like replace or UseLiquidThreads or translationdialog.
A patch to avoid listing nonexistent special pages is in Gerrit change #9865. (In reply to comment #3) > siprop=magicwords shows also aliases for non existing parser functions like > replace or UseLiquidThreads or translationdialog. A magic word is just a mapping from translations to an ID, according to [[mw:Manual:Magic words]]. Whether or not that magic word ID is mapped to a variable or a function is a matter for siprop=functionhooks or the nonexistent siprop=variables. For that matter, it seems easy enough to create siprop=variables; Gerrit change #9866 should do it.
Brad's change has been merged.
Reverted in https://gerrit.wikimedia.org/r/15903 due to bug 38464
https://gerrit.wikimedia.org/r/16001
successfully merged
