* Rename $offset to $extraConds
* Pass the limit as an integer instead of an options array
* Fix unnecessary extra parameters
* In JS, fix URL encoding
* In JS, show the link again on error so that the user can retry, and so
that it doesn't appear as if the end of the list was reached.
Bug: T249977
Change-Id: Ifaf8d1e9537da9245a7340c76af9c975f1fb643f
Update SQL query option to use timestamp for search.
Update "undelete logic" to load data by parts according to history
limit constant. Create module with js and styles for "load more"
button, use ajax call to get next revisions data.
Bug: T249977
Change-Id: I102b6ea1109733d032223e4fa187f934cf128740
The db/ directory does not have an owner and it's a mess in general.
These classes don't depend on anything in core except the rdbms library.
Let's simply move it there. In other words, Krinkle made me do it.
Since the class was moved in I6202e52ba73 merged less than a week ago,
no need to alias anything.
Bug: T321882
Change-Id: I24ceeb8bf765a50f441270136acd612359d50aa2
They are not suitable to go to rdbms library as they depend on mediawiki
pieces, the second best place is the db/ directory.
Bug: T321882
Change-Id: I6202e52ba7306d74261206c2ba7930c5f1a0a18e
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
PageUpdateStatus provides clean access the the newly created
RevisionRecord.
Depends-On: Ia08c586198082ea47e8313d0d41835f9830fb29e
Change-Id: Id6963842321c4eaa3d7d029ad0b769f73433c103
The day has gone. Still keeping the code as the schema changes are not
done in production but the data migration has been finished.
Bug: T299417
Change-Id: I906e069a63d1dae14924c72318b22b16244371d6
This is really hard to read. What is code, what is string? These
places are so simple, they really don't need the "{$var}" syntax.
Change-Id: I589dedb8c0193eec4eef500bbb896b5b790b727b
This continues the work in the child patch to replace callers
of setMwGlobals() with the appropriate method. Directory this
patch covers is `tests/phpunit/integration/`.
Change-Id: I0a9abf0d2a43587f2ffa029b68024a1ba5165fc7
In case two revision have the same timestamp, the higher rev_id is the
later revision and needs to be patrolled as well.
This also fix the tests, where the clock was faked to get higher
timestamps on the revisions
The WHERE changed from:
rc_cur_id = 2 AND (rc_timestamp > '20220603122124') AND rc_actor = 10
to
rc_cur_id = 2 AND ((rc_timestamp > '20220603122124') OR (rc_timestamp =
'20220603122124' AND (rc_this_oldid > 2))) AND rc_actor = 10
Bug: T309817
Bug: T304766
Bug: T260798
Follow-Up: I66bb6575dad4a970339e93b91fe486727111092a
Change-Id: I3cfcca4f0405f1d701c2883109c53b15854d6e64
When performing a rollback, we marks the reverted edits as
patrolled (on UseRCPatrol wikis) and also pretend they were by a bot
(discussion at T304766).
The way it is marked as patrolled is by setting the patrol status to
autopatrolled. But, if (one of) the edits was already patrolled before
the rollback, the manual patrol status should not be overwritten.
* Fix this.
* Also improve query performance by setting via rc_id instead of
through more complex conditional clauses in the update query
(should help with T260798).
* Test as much of this patrolling stuff as possible.
Bug: T304766
Bug: T260798
Change-Id: I66bb6575dad4a970339e93b91fe486727111092a
All revision related classes are namespaced MediaWiki\Revision
instead of MediaWiki\Storage since 1.32. The old namespaced
class names are deprecated and only kept for backwards-compatibility.
Bug: T305784
Change-Id: I34e492d84d9fc4bc78481667202716d93b3c43cb
This ensures that assertions work in a uniform way,
and provides meaningful messages in cause of failure.
Change-Id: Ic01715b9a55444d3df6b5d4097e78cb8ac082b3e
Currently this is implemented internally as a second method call. In the
future, it might be possible to optimize the implementation, e.g. to
reduce the amount of DB queries/jobs etc. without changing anything for
callers.
Since the implementation of e.g. the result getters is generic, a future
commit may add an option to delete subpages with relatively low effort.
The revision limit for big deletions is now using the total number of
revisions (base page + talk page). This is because both deletions would
happen in the same main transaction, and we presumably want to optimize
the deletion as a whole, not as two separated steps. This would become
even more important if the aforementioned improvements are ever
implemented. Note, the whole concept of "big deletion" might have been
superseded by batched deletions in the author's opinion, but as long as
such a limit exists, it should serve its purpose.
The current interpretation of the associated talk option is that the
request is validated, and an exception is raised if we cannot delete the
associated talk, as opposed to silently ignoring the parameter if the
talk cannot be deleted. The only exception to this is that it will not
fail hard if the talk page turns out not to exist by the time the
deletion is attempted, as that's hard to foresee due to race conditions.
Note that the summary for the talk deletion is prefixed with the
delete-talk-summary-prefix message. The main reason behind this is that
the delete UI can sometimes offer an auto-generated summary like "the
only contributor was XXX" or "the content was YYY", and since this may
not apply to the talk page as well, the log entry might look confusing.
Bug: T263209
Bug: T27471
Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
In retrospect, I rushed the previous patch: we really need a way to tell
which deletion an ID belong to (and whether it was scheduled). So make
both result getters return an array with known keys that can be used
programmatically. Right now the class can only delete a single page, and
thus there's a single constant and this change is effectively a noop.
The deletionWasScheduled() method, introduced in 1.37, was
hard-deprecated out of an abundance of caution. There are no known uses
on codesearch, so it can probably just be removed in the next release.
Also reorder constructor params to DeletePage -- BacklinkCacheFactory is
a service injected by the factory, hence it shouldn't be grouped
together with value objects injected by the caller.
Change-Id: I32679b7cacc638ec3e9dc5b8dfe9bcc794b22ecf
Instead of putting logID/false in the status' value, add getters that
can be used to retrieve this information. Also, make it return an array
of log IDs, which is easier to expand later on to account for deletion
of related pages (e.g. associated talk page).
Note: this change will be backported to 1.37.
Bug: T288758
Change-Id: I7ef64242ae0cb7018a4b1e8eb004a5563925b9a4
Some methods in the PageUpdater's class implements the fluent interface
design pattern. Use the fluent interface where need be.
Change-Id: If76a4b8c5070c20ed40038a4ee78e2d677de5180
- Switch do actual DI
- Add some more parameters for needed dependencies
- Create a factory interface, implement it in PageCommandFactory and add
wiring for it.
- Add new unit tests for DeletePage; unfortunately, this requires
conditionally disabling some code during tests due to dependencies on
legacy code that hasn't been migrated yet. I believe that these
temporary hacks are acceptable, since they allow us to use real unit
tests immediately.
- Adjust WikiPageDbTest: the two logging tests were identical as of
Ie0d9da2c8d273c93301921e1e108d9ffb381b8a5; and then the logging part
could just be part of the "main" test.
- Add integration tests for DeletePage. For now, these are all copying
their WikiPageDbTest counterpart. More tests will be added soon™.
Bug: T288758
Change-Id: I2fb79ed905ce621cb87f0658983d97148948da28
