This query was correctly excluding expired items from RC, but it
was failing to include them when the unwatched filter was set.
This is a follow-up to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/602211
Bug: T252136
Change-Id: I5d43d746df21cc3674eb2e92c3f604b7c87b7d1a
This isn't really user visible, but the algorithm for ensuring there
are no conflicts in automatically-generated parser test class names
had a number of issues which led to inconsistent naming.
Change-Id: I50ff5b72381332c77f0d99af08e689796019a7af
Page titles used in URL paths, such as the Location header returned
after a page was created, must use the correct encoding for spaces and
pluses.
Bug: T258606
Change-Id: I75e91ac8f8da4eb183a9c8f1a682ea08c2225227
It caused a 20% latency regression by unconditionally parsing extension.json
files on every single load instead of using the existing caching
infrastructure. There are further problems with the use of parsing/loading
extension.json files in a method that is incompatible with the existing
architecture.
This primarily reverts commit 46eabe275c.
Also needed to revert 16381261ae and 7c72347ec1.
Bug: T258664
Change-Id: I34a783c3f0df0447876a26441bb2d12e02368871
Use a unique key to assign handlers registered via
scopedRegister(). Using unique keys instead of
array indices ensures that handlers registered in other
ways previously (e.g. via global hook registry or via
HookContainer::register() won't be removed).
Remove the temporary hook for AlternateUserMailer
as the ticket it references is for a class that
no longer exists
Bug: T255056
Change-Id: I491f281e60511a5bdd695ac123611e408324ccff
This causes RevisionStore to use FallbackContent instances to represent
content for which no content handler is defined.
This may happen when loading revisions using a model that was defined
by an extension that has since been uninstalled.
Bug: T220594
Bug: T220793
Bug: T228921
Change-Id: I5cc9e61223ab22406091479617b077512aa6ae2d
Extensions have the ability to inject their own idea of what
a contribution is into the ContribsPager query resultset (via
the ContribsPager__reallyDoQueryHook). Because of this,
stable chronological ordering of ContribsPager results
becomes virtually impossible
For the purpose of the User Contribution REST endpoints, we will
restrict the resultset to ONLY mediawiki revisions for now.
This patch renames 'revisions' to 'contributions' and adds the
'type' field to future-proof work on adding different kinds of
contributions to the User Contribution REST endpoints.
Bug: T257838
Change-Id: I1e6de1c14a5f47e0310df86325fa6d791833addb
For some use cases (e.g. UserContributions endpoints (T235073) )
we do not want extensions to be able to inject their own
contributions into the result set of ContribsPager.
This is because extensions may not be adding revisions, but
other types of 'contributions'. With the hook enabled,
we are unable to reliably enforce strict chronological
ordering of contributions. (See T200259 for explanation).
Disabling the hook provides a consistent set of revisions for the
User Contribution endpoints.
Bug: T257839
Change-Id: I239395c572d4cb32a4d9ee871ffa02accfdce837
Previously null edits were not properly marked in EditResult objects
provided by the PageUpdater. This change should fix it, by ensuring
the original revision ID is always set on the EditResultBuilder if
the edit is a null edit.
I've also added some code to test this, so we hopefully don't
encounter an issue like this in the future. :)
Bug: T257766
Change-Id: I04bb058c64483967617958d86aa40a67c31071cb
Add a new tooltip message that displays the remaining watch period of a
page, if it is being watched temporarily. The tooltip message remains
the same if it is being watched indefinitely.
Bug: T250215
Change-Id: Ic9d1301427d477de71fb6f63fe77554a33684cd1
Based on the patch that introduces manual revert detection, this is
to create a software-defined change tag that will be applied to all
edits that restore a page to an exact previous state. This is also
for consistency with mw-undo and mw-rollback that will make a
"reverted" tag appear on reverted edits in the future.
Note about the REST API tests: in the next patch in this chain
I encountered even more issues with comparing returned changed tags
with expectations, so I decided it'd better if we just checked the
change tags applied manually in these tests. Otherwise we can run into
nasty race conditions, as the reverted tag is processed after sending
the response to client in the deferred update. It also makes the test
hard to maintain.
Bug: T256001
Change-Id: Ic367886f39faedcb823222b7d63bf4d5cb236ae9
Create a method in UserFactory to instantiate an anonymous
user with an optional IP address.
Bug: T257464
Change-Id: I557620f9bcd4b646288b4a76b26c4730fccbc3d8
The links use {{FULLPAGENAMEE}} magic word which would resolves to
'Special:Undelete' on the diff page, therefore giving wrong target
title for the logs
Bug: T196669
Change-Id: Ibcd58cea23dbca8e24b638c6f6ee5e764f32ff26
This is a follow-up for Ifcf0bc4.
I checked the callers of this method. The majority of them does not
care about these numeric values, only about the language codes. Most
callers even do an array_keys() immediatelly. The only effect I could
find will be visible in the ApiQueryUserInfo API module. Example:
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&meta=userinfo&formatversion=2&uiprop=acceptlang
In this response, the numbers are currently reported as strings, but
will be reported as floats. I would argue this counts as a bugfix and
doesn't need anouncement.
This patch also splits the responsible regular expression pattern for
improved readability, utilizing the /x extended mode. No change is
made to the pattern.
Change-Id: I42de46f56d7544f9781b02a2f0ed49ef85ee44a1
All titles that contain a colon followed by a number cannot, currently,
be accessed via the Rest endpoint.
For example https://en.wikipedia.org/wiki/3:33 is a valid title/article
on English Wikipedia and can be accessed there the index/api.php entry
points. But the rest endpoint will fatal:
https://en.wikipedia.org/w/rest.php/v1/page/3:33/history
The exception is thrown in Uri constructor of GuzzleHttp library
if parse_url() failed to parse the request URL. But parse_url() has
an open bug of failing to parse URLs that contain the above pattern.
The function returns false in such cases, (it previously raised warning
see I2715607);
To make our titles with this pattern accessible, we have to forestall
this exception.
Bug: T256831
Change-Id: Ib829afc7b33419b01e69ababa147d33b30c0fbcb
This creates the infrastructure we want to use later to test
improt and export of multiple slots.
Bug: T220525
Change-Id: I8e02927bd5532fe9cee0694d48a4c7d9ec060ba1
The code for manual revert detection is ran when building the
EditResult and the edit was not marked as a revert yet. It's
based on a SELECT looking for recent edits that match the new
revision's SHA1. There is no index over rev_sha1 field, so we
limit the search to N most recent edits, in order not to cause a
full table scan.
I think this shouldn't break any extensions by setting the
originalRevisionId in situations that weren't expected, almost no
extension uses that anyway:
https://codesearch.wmflabs.org/search/?q=%5C%24originalRevId&i=nope&files=&repos=
Bug: T256001
Change-Id: I4e38b382391b42e252cb66584be1e174cdfe348c
This introduces an ApiWatchlistTrait that refactors out common code
across APIs that allow you to watch pages. Some methods have been
migrated from ApiBase and changed completely, but codesearch suggests
they aren't being used outside the API modules in this patch.
Bug: T248512
Bug: T248514
Change-Id: Ia18627b9824dca81f44f0571e8420d89b7626cf6
T233963 added serizalization type to RESTBagOStuff. Although
there were no known callers that were not refactored to be
aware of this, T233963 also added a deprecated "legacy" type,
marked for removal in MW 1.35, just in case. There are still no
known callers using this, so remove "legacy" as planned.
Bug: T234779
Change-Id: I0c7707692aa1d0c75e262c914e064bddc10897c7
