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
In this patch I replaced RevisionStore::$dbDomain to
RevisionStore::$wikiId, RevisionRecord::$mWiki to
RevisionRecord::$wikiId and changed all hierarchies
and tests accordingly
Bug: T272901
Change-Id: I439515cfb6aa8a8697c2a5a0458ec8925522363a
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
Most of these are found by the not yet released I10559d8.
I remove the type MockObject in some cases when the calling
code really does not need to know if he get's a mock or the
real thing. However, I do this only in places that are very
closely related to the fixes.
Change-Id: I26a4c3c5a8ae141bf56161b52b54bce7e68f2e30
* parent::setUp() should be first, and ::tearDown()
should be last
* Move tests that directly extend PHPUnit\Framework\TestCase
to /unit
Change-Id: I1172855c58f4f52a8f624e6d596ec43beb8c93ff
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
This covers only directly used services by this special page and pager
Services used by the base class are not part of this patch set
Have to change another service to avoid global state
Bug: T259960
Depends-On: I07203e22f4b254df5c8cd6180d915a1537b7de30
Change-Id: Ifed2cbd2eee7166daf2e7d9bab017786247f88f6
Title::userCan, ::quickUserCan, and ::getUserPermissionsErrors, hard deprecated in 1.35
Bug: T246138
Change-Id: Iee990a16c15bd827cf631fb5ff683367082d2ebe
Add a property to the 'tags' object in the /user/{name}/contributions
REST endpoint named 'display' which shows the display
HTML for the tag which is either defined in i18n .json
files or overriden at MediaWiki:tag-$name
Bug: T259716
Depends-On: I57e2a7253944a3fde3f52f52bbf5fe8473c8a415
Change-Id: Id755adcab8b0115e19df2a6046643ebe97881e28
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
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
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
The endpoint for user contributions should include change tags in the
result. Bump the version of npm module api-testing.
Bug: T252202
Change-Id: Iccc0c378bc65d0f34b38557f4c78f424d95a951f
ContributionsLookup::getRevisionsByUser() returns a ContributionSegment,
but the function name was misleading. Renamed to getContributions()
to more accurately reflect the return value.
Change-Id: Id94549f1f8d2dc5ca5769fcb4696a454fdb851ac
ContributionsLookup needs to have the acting user (the authority) passde
in explicitly, so suppressed user contributions can be filtered according
to the user's permissions.
Bug: T252202
Change-Id: I94098f87ae45cd4e1db4a7168bf6e9478e9e32fc
