In $wgAddGroups, $wgRemoveGroups, $wgGroupsAddToSelf, and
$wgGroupsRemoveFromSelf, boolean true in place of an array of groups to
allow adding/removing is shorthand for "all groups". Handle this
appropriately in action=query&meta=siteinfo&siprop=usergroups.
Bug: T135467
Change-Id: I6ae61ef14ac7932e3369155c56bad60a9d72060d
This aims to solve all the problems and fulfill all the use cases.
It allows the dialog to be configured for Wikimedia Commons without
hardcoding anything, and it should be flexible enough for third-party
use. The default configuration should be sane for any wiki.
The file upload dialog can be configured using $wgUploadDialog.
See DefaultSettings.php for documentation. Example configuration for
Wikimedia Commons: Id56370e2334c8fe34e88180356232b48c244b7c4.
Configuration is loaded using ResourceLoaderUploadDialogModule for
local uploads or using ApiQuerySiteinfo (action=query&meta=siteinfo)
for uploads to a foreign wiki. Custom localisation messages may be
loaded using action=query&meta=allmessages.
Renamed messages:
upload-form-label-own-work-message-local -> upload-form-label-own-work-message-generic-local
upload-form-label-not-own-work-message-local -> upload-form-label-not-own-work-message-generic-local
upload-form-label-not-own-work-local-local -> upload-form-label-not-own-work-local-generic-local
upload-form-label-own-work-message-default -> upload-form-label-own-work-message-generic-foreign
upload-form-label-not-own-work-message-default -> upload-form-label-not-own-work-message-generic-foreign
upload-form-label-not-own-work-local-default -> upload-form-label-not-own-work-local-generic-foreign
Deleted messages, moved to WikimediaMessages in Id2977e19330aeaf854157d4355cd17e5dc72f16a:
upload-form-label-own-work-message-shared
upload-form-label-not-own-work-message-shared
upload-form-label-not-own-work-local-shared
Bug: T118097
Bug: T120998
Bug: T121632
Bug: T121633
Bug: T127895
Change-Id: I3017b8f09c27625deb7a92d6f667895b71cc0637
meta=siteinfo gets a list of all configured central ID lookup providers
and which one is being used as the default, while meta=userinfo,
list=users, and list=allusers get the ability to return the IDs and
attachment status.
Change-Id: Iea15b6c22baac79b3f8ca6df0e20a6a4299507d2
This was originally made 'BCarray' to avoid breaking BC, but in this
case the nonstandard output is so rare it's probably best to just be
internally consistent.
Bug: T117022
Change-Id: I501c415f6170383c163110b00e54ac88c3dfec89
Paths to ./composer.lock is changed to ./vendor/composer/installed.json
and dependency information now is read from the installed.json file.
A new ComposerInstalled class has been declared and uses the class now
to access the getInstalledDependencies() method to read data
Bug: T106247
Change-Id: Ic216577bb19b4fc5832ba003fcbbe9195d707b41
This fixes a few shortcomings in the chunked uploader:
* Raises an error if offset + chunksize > filesize.
* Enforces a minimum chunk size for non-final chunks.
* Refuses additional chunks after seeing a final chunk.
* Status of a chunked upload in progress is now available with
'checkstatus'.
Bug: T91203
Bug: T91205
Change-Id: I2262db1bc8460616b069c564475d2e4148001768
Use message-per-value for message
apihelp-query+siteinfo-param-prop to allow smaller strings
for translation.
Each prop in a message also will show up a new parameter on the help
page without the adjust of the translation (but than in english instead
of fully skip it).
Change-Id: I458fddcaef1cc96656a87375eff9707c8ba0db94
The main change is that siprop=namespaces will output an array instead
of a numerically-keyed object with formatversion=2.
Various other properties also got the same treatment, but in those cases
the intention was always array and possible non-array output was due to
array_unique or odd indexes in config variables.
Bug: T102645
Change-Id: I486131ac0d6763c3fe40fa45bcee472fe1b46fd6
Since T98757 is talking about changing this (whether by default or not),
we should probably make it accessible via the API.
Change-Id: I8cd08b214171866208a65181f772de9f2e315cd9
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
