This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
The following methods have beed converted:
::getRevisionByTitle
::getRevisionByTimestamp
::newRevisionFromArchiveRow
::newRevisionsFromBatch
::getKnownCurrentRevision
::getFirstRevision
Appropriate tests were adjusted to test both old interface (with
Title) and new interface (with PageIdentityValue)
Bug: T272886
Change-Id: Ica8da21d2413df885365475eaa498214edbcfd1d
As we convert the RevisionRecord to using Authority,
we no longer need Title instances, so we can convert
that to PageIdentity.
Ideally, we'd part away from using Title at all, but:
1. For foreign wikis PageIdentity has stronger validation,
so calling PageIdentity getId() on Title will break things.
There's still a lot of code depending on lax Title guarantees,
so we keep it.
2. A lot of code still depends on Title, so we try to pass it
through even if we don't nesessarily need to, to save cost
on recreating it later on.
Bug: T271458
Depends-On: I287400b967b467ea18bebbb579e881a785a19158
Change-Id: I63d9807264d7e2295afef51fc9d982447f92fcbd
My personal best practice is to not document @params when there
is a @dataProvider. I mean, these test…() functions are not
meant to be called from anywhere. They do not really need
documentation. @param tags don't do much but duplicate what the
@dataProvider does. This is error-prone, as demonstrated by the
examples in this patch.
This patch also removes @throws tags from tests. A test…() can
never throw an exception. Otherwise the test would fail.
Most of these are found by the not yet released I10559d8.
Change-Id: I3782bca43f875687cd2be972144a7ab6b298454e
RevisionStoreDbTestBase is mistakenly passing an array instead of an integer as
a query flags parameter in many places, which eventually gets passed to
DBAccessObjectUtils that uses it with a bitwise operator. PHP < 8 handles this
silently, but PHP >= 8 throws "TypeError: Unsupported operand types: array &
int" here.
Bug: T248925
Change-Id: I4e29b2709fe5e6d583727d45e005b3f16a1e3f4d
As the same string values are used by multiple methods in
RevisionStore, factoring them out to constants would make sense.
The only other appearances of these strings in core are some
long-deprecated methods that are probably not worth updating.
Change-Id: I85fe6ab96716f237291202dbb1ebefb90bb9f0da
Motivation:
This method would be useful to many extensions and other parts of
code that want to obtain a list of revisions in a given range. This
is quite hard to do properly, as the limit conditions are rather
complicated, so it would be useful to have a tested, working method
that does this.
This would be especially useful when obtaining a list of reverted
revisions. Currently extensions are provided with the newest and
oldest reverted revision ids, so this method could be used in such
a case. I think at least Echo, FlaggedRevs and EventBus could make
use of it. I also plan to use it in code marking reverted edits with
mw-reverted change tag.
Design:
I've decided for this method to return only ids, as this would suit
many (but not all) use cases and is far simpler than returning entire
revisions. If the method was to return RevisionRecords, it'd have to
have a few extra parameters (which parts of the revision should we
load? which slots should be loaded? should the content be loaded as
well?) and it would quickly grow to a huge supermethod that has way
too many responsibilities and is extremely hard to test reliably.
Bug: T258951
Change-Id: I0b82e8fa8bd7cb8aa599376a72ebc0a3b320c0e9
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
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
Clean up some technical debt; use MutableRevisionRecord instead of
manually constructing a Revision from an array, remove last uses of
RevisionStoreDbTestBase::revisionToRow and remove the method.
Each file can be reviewed separately (except that the removal of
revisionToRow depends on replacing its usage)
Bug: T246284
Change-Id: I0bdc069b21a5c41ef8f9e972c5b17ff189d4a741
Use assertRevisionRecordsEqual, not assertRevisionRecordMatchesRevision
also revisionRecordToRow, not revisionToRow
RevisionStoreDbTestBase::assertRevisionRecordMatchesRevision can thus
be removed
Bug: T254952
Change-Id: If5d7d4e01947d9f8a2ed51c950e750e82380930c
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
We're finally to the point of making the massive alter to the `revision`
table that we've been building up to for 2.5 years now.
Changes here are:
* Drop `rev_text_id`, `rev_content_model`, and `rev_content_format` that
MCR obsoleted.
* Drop `ar_text_id`, `ar_content_model`, and `ar_content_format` that
MCR obsoleted.
* Replace `rev_comment` with `rev_comment_id`.
* Replace `rev_user` and `rev_user_text` with `rev_actor`, plus
associated index changes.
Future patches will make the code changes to migrate data from
`revision_actor_temp` and `revision_comment_temp` into the new
`revision` columns.
Bug: T251343
Bug: T184615
Bug: T215466
Change-Id: I18071a2fe45907a0cf1b0fefebd96a97a2dacb7b
Change Ic6f98d8fb changed RevisionStore::getRevisionByTitle to convert
the passed LinkTarget to a Title using Title::newFromLinkTarget, to
address bug T206498.
Unfortunately, this breaks when RevisionStore is operating in the context
of a foreign wiki. In this scenario, when RevisionStoreRecord::__construct
calls Title::getArticleID on the Title instance to perform a sanity check
of the page ID against the page ID reference stored in the revision table
for the given revision record, then Title::getArticleID will lazily fetch
the page ID on the local, rather than the foreign wiki. This results in
an InvalidArgumentException thrown by RevisionStoreRecord::__construct.
This patch changes the logic to only resolve the LinkTarget to a Title
when operating in the context of the local wiki, similar to the checks
that RevisionStore::getTitle and friends are already performing.
It also adds a regression test to verify that
RevisionStore::getRevisionByTitle does not try to access the local wiki
DBLoadBalancer when called in the context of a foreign wiki.
Bug: T248756
Change-Id: I76090fa2907c2db8e23a62959346db531c6d9cb2
When for some reason we can't determine the title for a revision
in the batch, this should not trigger a fatal TypeError, but handled
gracefully, with helpful information included in the error message.
Bug: T205936
Change-Id: I0c7d2c1fee03d1c9208669a9b5ad66612494a47c
See codesearch - only deployed call outside of core is in flaggedrevs,
and already passes a RevisionRecord:
https://codesearch.wmflabs.org/deployed/?q=-%3EupdateRevisionOn%5C(&i=nope&files=&repos=
Also fixed a use of Revision::newFromId in orphans.php
Bug: T249561
Bug: T249021
Change-Id: I5933a278de8645b7005c11026c87ae27c0373770
Sometimes, an edit is done with a Title object that has gone
out of sync with the database after a page move. In this case,
we should re-load the current page ID from the database,
instead of failing the update hard.
Bug: T246720
Bug: T204793
Bug: T221763
Bug: T225366
Change-Id: If7701205ec2bf4d4495349d3e67cf53d32ee8357
This script scans for content blobs that can't be loaded due to
database corruption, and can change their entry in the content table
to an address starting with "bad:". Such addresses cause the content
to be read as empty, with no log entry. This is useful to avoid
errors and log spam due to known bad revisions.
The script is designed to scan a limited number of revisions from a
given start date. The assumption is that database corruption is
generally caused by an intermedia bug or system failure which will
affect many revisions over a short period of time.
Bug: T205936
Change-Id: I6f513133e90701bee89d63efa618afc3f91c2d2b
Before:
> 1. 1140ms to run …McrRevisionStoreDbTest:testLoadRevisionFromTimestamp
> 2. 1140ms to run …McrRevisionStoreDbTest:testGetRevisionByTimestamp
> …
After:
> …
> 36. 137ms to run …McrRevisionStoreDbTest:testGetRevisionByTimestamp
> 40. 135ms to run …McrRevisionStoreDbTest:testLoadRevisionFromTimestamp
Bug: T225730
Change-Id: I716bcf127761ef01d7ccfe10a79c08bea33ebc97
They naturally belong in RevisionLookup. They return Revision,
so should be replaced anyway.
Bug: T246284
Change-Id: Ie5c478e4667ca0e773186b9cb8a319cd09145112
