Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
When using interwiki data from the database the value for iw_wikiid and
iw_api maybe empty strings, because the database does not allow NULL
here.
Suppress the output of the attribute in that case, because there are not
useful.
This should not break clients, because using .cdb (like WMF wikis)
already missing these attributes in the result.
Change-Id: I60b97b4b58fdeaf699951544d418e5dc06e3830a
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
This enables factory functions to be registered for special
pages, as an alterative to giving a class name. This follows the
same rationale as Ieb85493a7765, which introduced factory functions
for API modules.
Change-Id: Ia2107dc5af7869187ba5dc02a1bef46d6801e138
Based on the code in Preferences::generateSkinOptions(). This should
probably be turned into a helper method one day…
Bug: 48953
Change-Id: Ib85a783bd19de8a59e7b81a4203a05b786e67772
You can't add or remove a group that doesn't exist, so don't claim that
it's possible on Special:ListGroupRights or the API.
Change-Id: I02d3f00142ca1cb0cdcbf30e79fecb3c96e96405
Interwiki::getAllPrefixes only sets the iw_local member in a response
row if $local is set to a non-null value. Under certain error
reporting conditions, the unqualified access to the array key leads to
warnings such as "message repeated 1471 times: [ #012Notice: Undefined
index: iw_trans in ...".
Change-Id: Ibf434dc9c362984cad76ae6bdb29de826974d81e
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
Strings like "5.6.99-hhvm" are not version numbers but merely
a way for HHVM to pass version checks. They should not be
displayed in the UI.
This affects Special:Version, the API (action=query&meta=siteinfo),
the installer welcome page, and the debug toolbar.
Follows-up d09ab9001f.
Change-Id: Ia99dca64779e9c4eaddf5f0e0101674d029b8d55
- use tab as indent instead of spaces
- Added space after closures "function"
- Added spaces around string_concat
- Added newline inside empty blocks
- Removed four spaces after comma
Change-Id: I4425b0c6a69b36f40acfea6511b8950cf09ce2b2
- Added/removed spaces around parenthesis
- Added space after switch/if/foreach
- changed else if to elseif
Change-Id: I99cda543e0e077320091addd75c188cb6e3a42c2
Works similarly to 'description' and 'descriptionmsg', but 'name'
is still required because of weird shenanigans Special:Version does.
(And would be a good idea anyway for backwards-compatibility with
older MediaWikis.)
The primary use-case is skins (which have already traditionally had
translateable names in MediaWiki, but weren't always shown on
Special:Version), but there's no reason why regular extensions can't
use this too.
Skins which already have a translated name for Special:Preferences
('skinname-<skin>' messages) can reuse the same message here.
Change-Id: Iae6f770a8fe1968670429c22aefc1ae55e8dba6f
$wgExtraInterlanguageLinkPrefixes holds a list of interwiki prefixes to be
treated as language codes if $wgInterwikiMagic is true.
To set the display text for the interlanguage links generated by this
code, you need to create MediaWiki:Interlanguage-link-foo, where "foo" is
the interwiki prefix. To provide a friendly site name for the link title
text, use MediaWiki:Interlanguage-link-sitename-foo. On the WMF cluster,
these messages could be set using the WikimediaMessages extension.
Information about extra language links (in the site language only) is
provided via the API in meta=siteinfo&prop=interwikimap.
Bug: 32189
Change-Id: I3d04760e2d9fb3320bb71e3d5ad115eed54a899c
Which type is used depends on the ApiModuleManager responsible for
the API module. There are two managers, one in ApiMain and one in
ApiQuery. Both contain a list of API modules they instantiate.
Both use $this as the first parameter in the constructors of the
individual modules. There is no other regular way to instantiate the
modules, so we know the type must either be ApiMain or ApiQuery.
The lists don't intersect.
I would have prefered the naming scheme $mainModule for ApiMain
modules and $queryModule for ApiQuery modules but since this
doesn't add much I left the shorter variable names untouched.
Change-Id: Ie6bf19150f1c9b619655a06a8e051412665e54db
This partially reverts r73950 which removed $wgServerName on the ground that it
was only used for {{SERVERNAME}}. When it was pointed out that $wgServerName was
also used by several extensions, the response was not to restore the variable, but
to proceed to remove it from extensions as well.
It is a useful variable to have, as the discussion on Id819246a9 makes clear
(see Tim's comment on PS12 and Timo's reply). So let's reintroduce it, and expose
it in mw.config and ApiQuerySiteInfo as well.
Change-Id: I40a6fd427d38c64c628f70a2f407b145443ea204
For browser testing, I need a reliable way to determine the branch in use
on a target wiki. One could parse the generator name forged when
querying the siteinfo, but that yields:
MediaWiki 1.24alpha instead of master
MediaWiki 1.24wmf2 instead of wmf/1.24wmf2
I am not really willing to reverse engineer the version to figure out
the branch, instead just expose it over the API.
Bug: 62509
Change-Id: If3db8f480ce0d590522741d40fb8e43b753efb41
action=query&meta=siteinfo&siprop=extensions calls
$gitInfo->getHeadCommitDate() to attempt to find the commit date, but
does not check whether that function returned false before using the
value. This resulted in displaying the current date for "vcs-date" when
the function failed.
Bug: 64821
Change-Id: Ic39a74abe5160b3b7fbfb7c15323328d6b317560
This was apparently a companion to $wgRightsPage, $wgRightsUrl,
$wgRightsText, and $wgRightsIcon, added in r3148.
But even then it was commented out as "not yet used", and appears to
have eventually disappeared without ever having been used.
Change-Id: I63f4393c22912f04e4ea690ebb1cd02bae65faab
This is needed by MultimediaViewer to show a relevant icon next to the foreign repo link to the description page
Change-Id: Id02743b036a2b88677d76613a73787874f5e448b
Mingle: Multimedia card #107
This would be used by MultimediaViewer to show an icon next to the
link to the description page (and probably makes sense to include
$wgFavicon if $wgLogo is there, anyway).
Bug: 59925
Change-Id: Ibdad9c3d2b515fbfdcd458db9b061f4d4d375180
Allow extensions to register a software license and present
this on the Special:Version page. A new $wgExtensionCredits
parameter has been introduced for this purpose: 'license-name'.
This will also automatically pick up the presense of additional
licensing and/or credits files. If ((AUTHORS)|(CREDITS))(\.txt)?
exists in the extension base directory a credits link will be
created. If ((LICENSE)|(COPYING))(\.txt)? exists a license link
will be created.
The API has also been updated to produce VCS information and present
links to the license/credits files.
Bug: 48418
Change-Id: I388f3b630462f1909f30751c987f7af585e98881
For languages with variants, we're already returning the list of variant
codes in meta=siteinfo&siprop=general. Clients may have use for the
variant's human-readable name too, and we can easily add it to the
datastructure.
Change-Id: I6c7ebf43a699a0b2346cb0fdeef6487217992f5c
