Currently, a user who wants to set a page's language must use the
Special:PageLanguage interface. However, this is not easy for bots and
scripts to use. The addition of action=setpagelanguage to the API makes
this process easier for such users.
Bug: T74958
Change-Id: I42e74ed3bcd0bfa9ec0c344ba67668210450c975
First step in refactoring the search results page. Pulls out widgets
to render our two styles of search result, Full and Simple.
Bug: T150390
Change-Id: If78cb0c29ae394f16e465c15a8e8246c1b56dcea
This has been in Wikibase since 2012, but is not at all
specific to Wikibase, and doesn't even require Wikibase
to be enabled.
Having this in core will make it available to more people
and without the hassle of having to clone Wikibase to
use the script.
Bug: T114577
Change-Id: Ib521a65e616bdc4b81206a084289cb4750f0d1f5
This will allow for checking passwords against the wiki's password
policy from the account creation and password change forms.
Bug: T111303
Change-Id: I0de281483bd83e47d80aa1ea37149d14f2ae5ebd
This makes the code for processing JSON files with
grammar transformations reusable by different languages
and applies the same logic to Russian and Hebrew.
It will be done to other languages in further patches.
This patch is not supposed to change any functionality,
and the tests are intact (except a comment in the test
for Hebrew - the class doesn't exist any longer).
PHP:
* Move the JSON grammar transformation data processing logic
from LanguageRu.php to convertGrammar() in Language.php.
By default all these data files are supposed to be
processed identically, so the code should be common.
If there is no JSON data file, nothing new happens.
* LanguageRu's own convertGrammar() method is removed.
* The LanguageHe class is removed, now that all its functionality
is handled by generic JSON data processing in the Language class.
LanguageHe.php file is removed from the repo and from autoloading.
JavaScript:
* Move the JSON grammar transformation data processing logic
from ru.js to mediawiki.language.js.
* JavaScript grammar code files he.js and ru.js are removed
from the repo and from Resources.php, because all the data
is in JSON, and the default logic in mediawiki.language.js
works for both languages.
Bug: T115217
Change-Id: I5e75467121c3d791bb84f9e6fdfcf07c1840f81a
This allows us to put other requirements more easily into extension
registration, such as skins and/or extensions.
Bug: T117277
Change-Id: I3ec1b28b6af380621585cd61b38e5ebb8be9f9c7
This is useful when IMaintainableDatabase methods are needed
for foreign wiki connections to things like external store.
Also:
* Set visibility for ExternalStoreDB methods.
* Cleaned up various type hints and comments.
Change-Id: Ie35b1ff21032cc4e78912dc499486da23aeba041
We already throw around some exceptions that are localized
(ErrorPageError and its subclasses, MalformedTitleException), but
there's no standard way to recognize them. Let's change that.
Then let's use them in the API to be able to have internationalized
errors when such exceptions are caught, instead of wrapping the
English-language version.
Change-Id: Iac7c90f92a889f8de9dae373547c07b884addaea
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
Previously, logic to validate extension.json files was in two places:
validateRegistrationFile.php maintenance script, and the
ExtensionJsonValidationTest.php structure test. This caused duplication
as validation became more complex (e.g. usage of spdx-licenses library).
A generic ExtensionJsonValidator class now handles most of the
validation work, while the maintenance script and test case just wrap
around it for their output formats.
Change-Id: I47062a4ae19c58ee1b1f2bb4877913259bf19c8b
This moves and refactors the ConsistentReadConnectionManager
from Wikibase into the core rdbms lib.
The refactoring also creates a generic ConnectionManager.
This relates to Iff20a22f9f2bc7ceefd6defc0ed9a494a6fe62c0
which introduced a DB factory / connection manager in
an extension revealing the need for this in multiple places.
Change-Id: I0c58e15aed5bed88323d18cb95e5008f8d3381c5
* do not warn if something is overwritten with an identical value
(happens a lot with 'ip')
* move to LogstashFormatter so we can check for the value
* instead of spamming errors, just add a flag to the logstash data
Bug: T145133
Change-Id: I31caee865cd60c785126478ac75c9aefce78eaaf
The class keyword should work in all reasonable working php installations,
as far as I know. In this way, the php version check does not rely on a
set of global functions. It also should make maintaining the different
checks a bit easier.
Change-Id: I73ee098a8cf931ca4df6263c6e0a3e215555b612
In order for an extension to add data to ApiQueryWatchlist, we need to
provide a way to allow it to manipulate the database query made by
WatchedItemQueryService. We also need some hooks in ApiQueryWatchlist to
handle the marshalling of data to and from WatchedItemQueryService.
To better handle hooking, this also moves some of the continuation logic
from ApiQueryWatchlist to WatchedItemQueryService.
Bug: T147939
Change-Id: Ie45376980f92da964a579887b28175c00fd8f57e
The conversion of SpecialNewpages to HTMLForm seems to be half-finished.
It's not using HTMLForm to read in the request query, which means we have
to roll our own logic. Kind of defeats the purpose of using HTMLForm in
the first place.
When ProtectedPages is converted to HTMLForm (T117722), it can use this new
field type.
Bug: T12817
Change-Id: I069609fbb37b18c3df25156779ad7ac7cd5d6813
Dependency-inject the MediaWiki-specific parts into a CryptHKDF
instance, which MWCryptHKDF wraps around.
Change-Id: Idff18635cfd8a3d93ea2ca8d56cdbd11eb4d3b2b
Literally every function in this class depends upon MediaWiki, so it
does not make sense to be included in the utils/ directory.
Change-Id: If6c6b75dc11b49b75f649d56eaeb9c96ef54b787
* The later resides in /libs with related files.
* Explose MimeAnalyzer as a service.
* Keep MimeMagic::singleton() as a b/c alias.
* MimeMagic::applyDefaultConfig() will bootstrap the service
with all of the old config, extension hook handler, and
detector command shell-out behavior.
Change-Id: Ie2695a52e7a3bcfda9f7fa83659a9ff31b372bc3
As an alternative to using magic links, PMID was added to the default
interwiki list.
RFC already existed, but the URL in the default list was pointing to
rfc-editor.org, not the tools.ietf.org view like the RFC magic link or
Wikimedia interwiki map are.
Updating the default lists in maintenance/interwiki* only affects new
installations, so a post-database update maintenance script adds and
updates the two interwiki prefixes.
Bug: T147536
Change-Id: I5a2c2c9b0f989da62a4395c9516d880c7d923444
