PreparedUpdate represents an in-progress edit. It can be used to access
information about the edit from hooks that do to have access to the
PageUpdater. Ideally, the PreparedUpdate or PageUpdater would be passed
to the hook as a parameter. Handlers of legacy hooks may use
WikiPage::prepareUpdate() to access it.
Bug: T242249
Needed-By: I23324a31e06e7e6f28077085c0ade05db63e9a35
Change-Id: Id5ba40a21cc4547205adf2f3a1f725c3a69c24d8
These special pages and their counter-part APIs are:
- Special:RecentChanges
- Special:Watchlist
- Special:Log
- Special:Contributions
This also changes the way MAX_EXECUTION_TIME works from taking the value
as milliseconds, it takes seconds which is more intuitive for users.
Bug: T297708
Depends-On: I126e7181422d8da1a63afc3717faa4f72a687dd9
Change-Id: I3ff78751c3df3b6342f1865d35c2075f4415185d
Providing just standard timestamps means that formatting
has to happen in the client, however that means loading a
large deprecated library (moment.js). We already have
localised formatting functions in PHP so just provide
the output of those in the API.
Also fix test mocks to correctly provide a language object
rather than a string.
Bug: T224635
Change-Id: I73dcfcdbbc6e90bc692bf5a456075fe1eaed2df9
PHP 8.1 will give us "first class callables" that look like e.g.
$result = array_map( $this->fn(...), $array );
For now we can use
$result = array_map( [ $this, 'fn' ], $array );
Change-Id: I7278c80c075d162da73aa45af1b6578310ce0624
The concept of a redirect chain didn't really work for a value of
max redirect > 1. In the ideal world, we just want to have a source
which points to target (source -> target) discarding the concept of
a redirect chain completely.
Having something like: source -> target -> target1 -> target2 doesn't
really work well with the current database design.
NOTE: Support for $wgMaxRedirect will be removed soon hence
deprecation without interfaces for replacement.
Bug: T290639
Change-Id: I469de6f85e405e8ddbe7abaa5b99b77cb9cf415d
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
