Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
And deprecated aliases for the the no namespaced classes.
ReplicatedBagOStuff that already is deprecated isn't moved.
Bug: T353458
Change-Id: Ie01962517e5b53e59b9721e9996d4f1ea95abb51
I469de6f85e405e8ddbe7abaa5b99b77cb9cf415d added an initial RedirectStore
implementation, but it has remained a stub despite the corresponding
task being closed. So, flesh out the implementation by moving the
corresponding logic from WikiPage.
Soft-deprecate WikiPage::insertRedirectEntry() accordingly.
Bug: T290639
Change-Id: Ia500df45bc969ce77b6b2a06bfec10e32c00b931
The service was previously accessing the global ExtensionRegistry
singleton, making it lose its statelessness. Dependencies should always
be injected, so add constructor parameters for that.
Simplify tests accordingly.
Change-Id: Iae375a81cab411fab607cba0addb2088131b3c81
And remove hacky conditionals for unit tests. Note that the
isDeletePageUnitTest hack cannot be removed yet due to other
non-DI-friendly dependencies.
Change-Id: I215abd01ee8f4ea96539022147f0ce079cdf6c5e
SelectQueryBuilder::lockForUpdate() is confusable with a mutator that
enables for update mode, by analogy with lockInShareMode().
IDatabase::lockForUpdate() is a nice shortcut but the name is confusing
when the return value is used.
So,
* Deprecate SelectQueryBuilder::lockForUpdate()
* Add SelectQueryBuilder::acquireRowLocks(), which performs the query
but throws away the results.
* Migrate callers of IDatabase::lockForUpdate() to SelectQueryBuilder.
Change-Id: I3f18e9c48349838dcf0ba00a5beb67eace3029e1
When creating ServiceOptions objects or fake HashConfigs use the
constant to refer the config name
Change-Id: I59a29f25b76e896c07e82156c6cc4494f98e64cc
The ->getTitle wasn't mocked, which resulted in a bunch of
warnings about passing null as string.
Bug: T313663
Change-Id: I50c6dd2dcafefd1bb4536d31b2b6005e10dce570
* Adds option to undelete associated talk page in the context of a
subject page
* If subject page undeletion fails, talk page undeletion is aborted
* If restoring the associated talk page fails, a status with a
warning message is returned
Bug: T304962
Change-Id: I7b30863060974d4079639f57178062d359956c2e
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
In both cases the typehints were changed to the new interfaces. For the
ArticleDelete hook, the replacement has no $error param and requires the
caller to set a fatal status if it wants to abort.
Bug: T288758
Change-Id: I9540f6ab2075bcf56bd4fdc79c611c883246cdce
- 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
