array_fill_keys() was introduced in PHP 5.2.0 and works like
array_flip() except that it does only one thing (copying keys) instead
of two things (copying keys and values). That makes it faster and more
obvious.
When array_flip() calls were paired, I left them as is, because that
pattern is too cute. I couldn't kill something so cute.
Sometimes it was hard to figure out whether the values in array_flip()
result were used. That's the point of this change. If you use
array_fill_keys(), the intention is obvious.
Change-Id: If8d340a8bc816a15afec37e64f00106ae45e10ed
Add the `expiry` wlprop to get the timestamp with the
TS_ISO_8601 format. If the item doesn't expire, the
value is set to false.
Bug: T263796
Change-Id: I73f378f11662934255da4a41af9d1bc3d7b45030
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
Notably:
* In ApiManageTags, I used a switch instead of a dynamic function name,
so that the call graph will be correct.
* In ApiImageRotate, checkTitleUserPermissions() has always returned
void, this was an error introduced in 4e6810e4a2
Change-Id: Iea22616b8e7e2e0cc804619a54f8690898b2cb82
This brings significant modularization to the Action API's parameter
validation, and allows the Action API and MW REST API to share
validation code.
Note there are several changes in this patch that may affect other code;
see the entries in RELEASE-NOTES-1.35 for details.
Bug: T142080
Bug: T232672
Bug: T21195
Bug: T34675
Bug: T154774
Change-Id: I1462edc1701278760fa695308007006868b249fc
Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
When converting a Title object into a string for user or user talk
namespace the gender information are needed.
This patch set improves performance on wikis with gender distinction
like dewiki or ruwiki by combining the fetch of the information into one
query and avoids a query per unique user name.
It also avoids false results for request with apihighlimit, because the
apihighlimit with 5000 is higher than the query max limit of the
GenderCache with 1000
Bug: T200238
Change-Id: Ibe0561b210dbeb654117dad777e839640f51b4e4
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
MCR deprecated the Revision class in favor of the broadly similar
RevisionRecord, and more interestingly added the concept of multiple
content "slots" to revisions.
Thus, prop=revisions, prop=deletedrevisions, and so on gain a parameter
to specify which slots are wanted. When this new parameter is not
specified (and any content-related props are specified), a warning about
the legacy format will be issued.
The rest of the modules just needed to call methods or use constants on
RevisionRecord instead of Revision. ApiQueryDeletedrevs wasn't touched,
since it has been deprecated since 1.25 anyway.
This also updates a few non-query modules that don't depend on details
of editing, diffing, or viewing MCR revisions that haven't been figured
out yet.
Bug: T200568
Change-Id: I1327d1784f5cedb006cd74df834cf9a560a77a5d
This allows CommentStore to be added to MediaWikiServices
without the need of an aditional Factory.
This change includes a compatability layer to allow the behaviour
from 1.30 to continue to be used while deprecated.
CommentStore::newKey has been deprecated.
Keys are now passed into the public methods of CommentStore
where needed.
The following CommentStore methods have had their signatures changed
to introduced a $key parameter, but when used in conjunction with
CommentStore::newKey behaviour will remain unchanged:
* CommentStore::getFields
* CommentStore::getJoin
* CommentStore::getComment
* CommentStore::getCommentLegacy
* CommentStore::insert
* CommentStore::insertWithTemplate
Change-Id: I3abb62a5cfb0dcd456da9f4eb35583476ae41cfb
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
- mostly auto fixes
- some too long lines fixed
- ignore amp space in one case passing by reference
Change-Id: I6472f83bc3cbf4bd629d83050cc3319b19ec465c
Stuff like passwords and CSRF tokens shouldn't be in the logs.
The fact of being sensitive is intentionally separated from the need to
be in the POST body because, for example, the wltoken parameter to
ApiQueryWatchlist needs to be in the query string to serve its purpose
but still shouldn't be logged.
Bug: T125177
Change-Id: I1d61f4dcf792d77401ee2e2988b1afcb2a2ad58f
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
The pre-WatchedItemQueryService code used ApiQueyrBase::addWhereFld()
which filters out empty arrays. WatchedItemQueryService doesn't do that.
Bug: T153733
Change-Id: I3416b5a05c9751303b5c28a8b6d9cb746a101f73
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
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
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
This moves generating of a complex Watchlist and RecentChanges
related query to a WatchedItemQueryService class.
ApiQueryWatchlist class no longer contains any database-related
code.
Bug: T132565
Change-Id: I5a5cda13f8091baa430ac1a8e2176e0efd1ae192
It's currently showing all relevant revisions from pages with at least
one unread revision, where it would be more sensible for it to show just
the unread revisions. Something similar applies to wlshow=!unread.
Bug: T125729
Change-Id: I552901efb98081af9a1a677f4403a2a1a73bd94f
This comes from ApiQueryWatchlist, which calls
ChangesList::isUnpatrolled with recent change row entries.
Since If71af587, rc_log_type is now needed along with rc_patrolled.
Bug: T123542
Change-Id: If6507121e59c53df925998f383c9bdf8f2936e37
This is part of a chain that reverts:
e412ff5ecc.
NOTE:
- The feature is disabled by default
- User settings default to hiding changes
- T109707 Touching a file on wikisource adds and
removes it from a category... Even when page
has no changes.... WTF? See linked issue,
marked as stalled with a possible way forward
for this patch.
@see https://gerrit.wikimedia.org/r/#/c/235467/
Changes since version 1:
- T109604 - Page names in comment are no longer
url encoded / have _'s
- T109638 & T110338 - Reserved username now used
when we can't determine a username for the change
(we could perhaps set the user and id to be blank
in the RC table, but who knows what this might do)
- T109688 - History links are now disabled in RC....
(could be fine for the introduction and worked
on more in the future)
- Categorization changes are now always patrolled
- Touching on T109672 in this change emails will never
be sent regarding categorization changes. (this
can of course be changed in a followup)
- Added $wgRCWatchCategoryMembership defaulting to true
for enabling / disabling the feature
- T109700 - for cases when no revision was retrieved
for a category change set the bot flag to true.
This means all changes caused by parser functions
& Lua will be marked as bot, as will changes that
cant find their revision due to slave lag..
Bug: T9148
Bug: T109604
Bug: T109638
Bug: T109688
Bug: T109700
Bug: T110338
Bug: T110340
Change-Id: I51c2c1254de862f24a26ef9dbbf027c6c83e9063
Mysqli is returning SELECTed ints as strings rather than as ints, I'm
guessing to avoid problems with 64-bit int types on 32-bit systems. PHP
mostly doesn't care, but it causes API JSON output to have strings
instead of ints all over the place.
This also fixes ForeignAPIFile::getUser( 'id' ) returning the user
*name*.
Bug: T98276
Change-Id: Ie6591d72b3ac40172f8176a8ca8b6fad8e9275a5
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
This allows for extensions to format their log entry parameters, and
keeps the code for formatting API log entry parameters in the same place
as for other formatting.
This also takes the opportunity to rearrange the output format slightly
to avoid conflicts like what's happening in T73020.
Bug: T35235
Bug: T73020
Bug: T91466
Change-Id: I6846ce09322eb404c506b5a51780a44ce9279fe2
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
Querying via ApiQueryRecentChanges and ApiQueryWatchlist did not
pass if a particular log entry was a legacy log entry.
Ultimately CheckUser should stop writing legacy style log entries
too but we can at least behave properly when we hit them.
Bug: T91466
Change-Id: I1564ec7e599e2f9d78775e63e06eca84db497a43
