Deprecating RevisionStore::getQueryInfo() and cleaning up a lot of code
Also removing a brittle test that wasn't really testing anything.
Bug: T344971
Change-Id: Ifd690dc8f030f86e3567a717eaeb830cb6dc703b
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
Followed by some manual review to make sure I'm not changing too much,
omitting some changes that looked too complicated and anything that
caused test failures, and some whitespace fixes.
Change-Id: Ie78be1c614985d7c2964156e454cc9266515dc18
Easier to translate
There is no visible change for example on
Special:ApiHelp/query+watchlist
Bug: T285545
Change-Id: I536fa3e07a951f3ff98870678ffdbc294a3c7bc0
For pst on parse/compare/editstash/(all)revisions/(all)deletedrevisions
Do not show the IP when IP masking is enabled,
instead show a previous aquired temp name or a placeholder on preview.
MediaWiki itself used this for the ajax preview on GUI's action=edit
Cannot acquire a new unsaved temp user as api parse does not persist
the global session (each request results in a new id)
and it would require a db write on a read request.
Bug: T331397
Change-Id: I74bb4d655f371bd99e3b618d1a0ac45d730c746c
This may seem a bit weird but anything else related to actor is already
under user/ including ActorCache, ActorNormalization, ActorStore and
ActorStoreFactory.
Bug: T321882
Change-Id: I7072b374bba7a0cd9d905e399c822bf30bd5c0d8
30+ API modules had nearly identical code to split and validate
the value of the 'continue' parameter.
Introduce the ApiBase::parseContinueParamOrDie() method and use it to
replace most usages of ApiBase::dieContinueUsageIf(). A few remain in
modules with more complex continuation handling.
Inline most single-use variables that remained after validation was
moved into the new method.
Change-Id: I66bd59ecd4ad16e2039e90f7d66cfa276e6c1c2a
Builds a condition comparing multiple values, for use with indexes
that cover multiple fields, common when e.g. paging through results
or doing batch operations. Can also be to generate a simple comparison
without writing raw SQL (see T210206).
Update a few manually constructed conditions to use this method.
There are more maintenance scripts and API classes that use the
same patterns, but this is a start.
As you can see by the code I'm replacing, there are many ways to do
this. I picked the one used by maintenance/TableCleanup.php, since
I found it the easiest to understand.
Change-Id: Ic368a87fb5ce4c13608b03206cd68518ec9732d4
This covers all occurrences of /onfig->.*get( '/ in includes/.
Undoubtedly there are still plenty more to go.
Change-Id: I33196c4153437778496f40436bcde399638ac361
Make phan stricter about array keys
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T304887
Depends-On: I3105a5fd4826f8667b5232834defc5ec93be32a1
Depends-On: Ie9610a6e83731468311edb3ed17f80fc509de385
Change-Id: I701f12ab94478c3b8e7fd82110ade74a8e6b04ef
Introduce a new schema migration stage in which rev_actor is used
directly and the revision_actor_temp table is no longer needed. This
becomes the new "new" stage whereas the previous situation is now
termed SCHEMA_COMPAT_TEMP.
Introduce migrateRevisionActorTemp which copies data from
revision_actor_temp to rev_actor. The code is similar to
migrateImageCommentTemp.php except that it doesn't delete from the old
table.
Partial revert of c29909e59f. That change removed direct
references to $wgActorTableSchemaMigrationStage and made queries
involving revision_actor_temp be unconditional. Such changes need to be
reverted to make the use of revision_actor_temp be conditional again.
In ActorMigrationTest, I compacted provideGetJoin() and
provideGetWhere(), removing most of the duplication between expected
values. I gave all the stages a short name, and mostly used the name in
providers.
Bug: T275246
Change-Id: I7498107dd6433ab7de5bf2e7b3fe2aa5e10e345d
All classes extending ApiQueryRevisionsBase, for searching:
ApiQueryAllRevisions, ApiQueryAllDeletedRevisions
ApiQueryRevisions, ApiQueryDeletedRevisions
Including services for the ApiQueryRevisionsBase class
Bug: T259960
Change-Id: I001a9d39355becacab2e34a00027d04ddf7602b5
Replaces calls directly to PermissionManager with calls to
the Authority object available from Context or the
GroupPermissionLookup service.
This patch does not address use of PermissionManager for
blocks.
Deprecations:
- ApiBase::checkUserRightsAny deprecated passing optional
User parameter
- ApiBase::checkTitleUserPermissions deprecated passing
LinkTarget as first parameter, takes PageIdentity instead
Bug: T271462
Bug: T271854
Change-Id: I5d7cac1c28a37e074750c46cda03283980a07fca
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
The query for revisions include fields from the page table,
so use it with Title::newFromRow and pass it to the revision store.
If missing the revision store is using Title::newFromId for each row
For prop=revisions the page must always selected
Change-Id: I31d85bcdcfcd29892e91bf4fe1d7ec27bd61e593
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
Field rev_text_id will no longer be populated once the legacy
schema is disabled, so joins against it will not work.
Remove all usages of the 'text' flag in calls to both
Revision::getQueryInfo() and RevisionStore::getQueryInfo()
so that these joins are no longer attempted.
Bug: T198342
Change-Id: I9be6a544c6f68555d4ea856f949f0040d05eac0f
The revision_actor_temp table has denormalized copies of rev_page and
rev_timestamp to support the actor indexes equivalent to
`actor_timestamp` and `page_actor_timestamp`. But to get these to be
used, we need to have the WHERE and ORDER BY use the denormalized fields
instead of the main revision-table fields.
We can take generally advantage of the fact that "ORDER BY field" uses
aliased field names before the names in the actual table, but WHERE
conditions do need to explicitly vary.
Bug: T204669
Change-Id: I992aa50f02c35d76e91a5a28e05c870f8a32f858
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
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
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
Several classes have a "selectFields()" static method to tell callers
which fields to select from the database. With the recent comment table
change and the upcoming actor table change, this pattern has become too
simplistic as a SELECT will need to join several tables to be able to
retrieve all the needed fields.
Thus, we deprecate the selectFields() methods in favor of getQueryInfo()
methods that return tables and join conditions in addition to the
fields.
Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
Undo traces of a practice we carried over from past projects and
existing examples that is neither universal nor actively encouraged in
the MediaWiki codebase.
Bug: T139301
Change-Id: I5c9c89b72a45a44aa4264a5e57b003c1a86cdf6e
Co-Authored-By: Brad Jorsch <bjorsch@wikimedia.org>
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
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I49e2a10350a328a8572fcedd44012751a29e1068
This will allow extensions to inject into the query to implement
"xxshow" parameters, and to add additional properties to the output
data for "xxprop" parameters.
Also, call these new hooks from ApiQueryRevisions, ApiQueryAllRevisions,
ApiQueryUserContributions, and ApiQueryRecentChanges since I701e8e19 is
going to be wanting them.
Bug: T143614
Bug: T143616
Change-Id: Id6b42c7f2eb53a6f659d0d61383287f41d96ca00
Some generators (e.g. generator=recentchanges) in their default mode of
operation are particularly prone to not generating the same result set
on subsequent requests due to intervening activity on the wiki adding
new entries to the start of the list. We can mitigate this effect by
allowing such generators to provide "non-continuation" data to be used
if the generator isn't being continued.
ApiQueryRecentChanges and ApiQueryAllRevisions are updated to set this
new property. Other generators can easily be updated in the same way as
needed.
There isn't anything we can do about generators prone to having entries
added at random positions in the list rather than the beginning,
unfortunately.
Bug: T146176
Change-Id: I8308d6aa2c89fd2a85e74c7dd8a0a2a9ec927490
