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
This may seem a bit weird but anything else related to actor is already
under user/ including ActorCache, ActorNormalization, ActorStore and
ActorStoreFactory.
Bug: T321882
Change-Id: I7072b374bba7a0cd9d905e399c822bf30bd5c0d8
CommentParser:
* Move comment formatting backend from Linker to a CommentParser service.
Allow link existence and file existence to be batched.
* Rename $local to $samePage since I think that is clearer.
* Rename $title to $selfLinkTarget since it was unclear what the title
was used for.
* Rename the "autocomment" concept to "section link" in public
interfaces, although the old term remains in CSS classes.
* Keep unsafe HTML pass-through in separate "unsafe" methods, for easier
static analysis and code review.
CommentFormatter:
* Add CommentFormatter and RowCommentFormatter services as a usable
frontend for comment batches, and to replace the Linker static methods.
* Provide fluent and parametric interfaces.
Linker:
* Remove Linker::makeCommentLink() without deprecation -- nothing calls
it and it is obviously an internal helper.
* Soft-deprecate Linker methods formatComment(), formatLinksInComment(),
commentBlock() and revComment().
Caller migration:
* CommentFormatter single: Linker, RollbackAction, ApiComparePages,
ApiParse
* CommentFormatter parametric batch: ImageHistoryPseudoPager
* CommentFormatter fluent batch: ApiQueryFilearchive
* RowCommentFormatter sequential: History feed, BlocklistPager,
ProtectedPagesPager, ApiQueryProtectedTitles
* RowCommentFormatter with index: ChangesFeed, ChangesList,
ApiQueryDeletedrevs, ApiQueryLogEvents, ApiQueryRecentChanges
* RevisionCommentBatch: HistoryPager, ContribsPager
Bug: T285917
Change-Id: Ia3fd50a4a13138ba5003d884962da24746d562d0
ContribsPager was doing an actor table query from User::load() for
every row. Instead pass a UserIdentity to the constructor which can
cache the user ID. Most callers already had a UserIdentity with the
data already cached.
There are some weird kinds of targets which are not really users, but
UserIdentity was constructed unconditionally already, so I'm not
changing that. I did allow the target option to still be used in case
there is any future problem with round tripping strings through
UserIdentity.
Add integration tests.
Change-Id: Ifd05103fa648d0778ef5185fc73128d38d5fce74
Flow hooks into ContribsPager, causing formatRow() to be called with
FormatterRow objects instead of stdClass objects. formatRow() is
expected to silently decline to format such objects, leaving formatting
up to a subsequent hook.
Instead of calling newRevisionFromRow with all warnings suppressed and
all exceptions caught, provide isRevisionRow() which determines whether
the row is valid. Thus, unexpected exceptions will be visible and the
code does not depend on details of how newRevisionFromRow() validates
its arguments.
Bug: T288563
Change-Id: Id0316886d770cd905897d515b3eb658a5875bd80
Changes from patch set Icb93c79f4843b59dae80d3eda1a880457a1a68f2
Also some swaps from assertEquals to assertSame/True/False/Null
Change-Id: Ife497ae6cb1888b77eb25e85b76df72adc65641a
When we are using ip_changes for ORDER BY and the main query conditions,
put it first in the table list so that the MariaDB query planner doesn't
get confused. The join condition gets moved from ip_changes to revision,
but should have the same effect.
Bug: T284419
Change-Id: I7b9b48b0e78ca0a7c3849b829f9eb3cdc6e02207
- EditPage::$mBaseRevision
- EditPage::getBaseRevision()
- Title::getFirstRevision()
- LinksUpdate::setRevision()
- LinksUpdate::getRevision()
- Article::$mRevision
- Article::getRevisionFetched()
- WikiPage::getOldestRevision()
- WikiPage::getRevision()
- ContribsPager::tryToCreateValidRevision()
To make things easier, instead of rewritting
the Revision tests that were using WikiPage::getRevision,
just delete them, its not worth the effort to rewrite
them since the class is going away. For the WikiPage
tests, replace uses of getRevision with getRevisionRecord,
manually converting to a Revision object where needed
Bug: T247143
Change-Id: I52bc1f49649f8bd25797e3f7a090bec9c63ac2d1
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
When running the test in isolation or all tests from the /specials/ folder
the test is failing and internally an exception is thrown:
> Could not determine title for page ID 2 and revision ID 2
Just provide a Title object, because there is no guard that the revision
2 with a title exists on the database or such.
Change-Id: I8c251fcc5413971e52bafd09aeb6f1497cc65146
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
Soft deprecate ::tryToCreateValidRevision (to be hard deprecated once
MobileFrontend is updated)
In caller, replace use of Revision methods with corresponding
RevisionRecord calls.
Bug: T250431
Bug: T250580
Bug: T250980
Bug: T250579
Bug: T250714
Change-Id: Ic7be7d5cf5158482ee6fe08b179560460b6ccd32
Also fix PHPUnit 9 warning in PNGMetadataExtractorTest about $delta.
This should fix all of the integration test warning spam.
Bug: T244095
Change-Id: I0e2a76d5df2685ae5ad1498864e0b5f9db60c0cc
Add public, protected or private to function missing a visibility
Enable the tests folder for the phpcs sniff
Change-Id: Ibefce76ea9984c47e08c94889ea2eafca7565e2c
Use SpecialPage::getLinkRenderer and pass it to the pagers
Since I082152b64141f1a9a4085bba23fe81a99ec8d886 it is a property in the
IndexPager and can be used by getLinkRenderer
Change-Id: I2be8a8b9f2b0b8c04fe9e18aa1959987fc125f50
When ContribsPager is using an auxiliary table like ip_changes or
revision_actor_temp for the main action of the query, we already had
code in place to let it use the auxiliary table's denormalized timestamp
field for the ordering. What we didn't have was code to let it also use
the auxiliary table's denormalized timestamp field for *continuation*.
With the schema defined in tables.sql, the simplest thing to do would be
to be to add a redundant JOIN condition between rev_timestamp and the
denormalized timestamp field which would be enough to allow
MySQL/MariaDB to propagate the continuation conditional on rev_timestamp
to the denormalized timestamp field.
Unfortunately many Wikimedia wikis have rev_timestamp defined
differently from table.sql (P8433), and that difference is enough to
break that propagation. So we need to take a more difficult route,
restructuring the code tell IndexPager to explicitly use the
denormalized fields for ordering and continuation.
On the plus side, since we're doing that anyway we can get rid of the
code mentioned in the first paragraph.
Bug: T221380
Change-Id: Iad6c0c2f1ac5e1c610de15fe6e85a637c287bcd8
This works by using the new table introduced with T156318.
The only thing that differs from normal Special:Contribs is we are
showing the IP address next to each entry. This is it how it is
displayed if you request to see newbie contributions:
https://en.wikipedia.org/wiki/Special:Contributions?contribs=newbie
For the time being, Special:DeletedContributions does not support
IP ranges. Various other irrelevant links such as Uploads and Logs
are also hidden.
Refer to P4725 for a way to automate creation of edits by random
IPs in your dev environment.
IP::isValidBlock() has been deprecated with this dependent change:
https://gerrit.wikimedia.org/r/#/c/373165/
Bug: T163562
Change-Id: Ice1bdae3d16cf365da14c6df0e8d91d2b914e064
* Convert year/month date filter parameters to use start/end so that
ApiFeedContributions still works as expected after b668887
* Move SpecialContributions::processDateFilter (used to convert
year/month parameters to start/end parameters) to ContribsPager
since ApiFeedContributions also uses it now
Bug: T166859
Change-Id: I34fc8388a29e4cd36474934e6266127d0e3253cd
2017-06-06 10:41:40 -04:00
Renamed from tests/phpunit/includes/specials/SpecialContributionsTest.php (Browse further)
