addGoodLinkObj() has many optional arguments, but omitting them actually
means corrupting the cache.
Nearly all existing callers are in tests.
So LinkCacheTestTrait::addGoodLinkObject() was created only
for testing. It is better to have this method in the
trait, because building the row directly in each test
would make these tests brittle against schema changes.
The only usage in WMF production code was in WikiPage and has been
fixed.
Bug: T284955
Change-Id: I03a2bd9ed64fcc0281ee29a286c8db395a9e03d9
- 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
This makes the data stored by LinkCache compatible with PageStoreRecord,
so we can use LinkCache inside PageStore.
This causes PageStore to make use of local caching as well as WANObjectCache.
Note that getPageById() does not yet benefit from cache, but does
populate the cache.
Bug: T278940
Change-Id: Icc27a0d9299a3e4ce45521daef87ad06ec06f064
Changes from patch set Icb93c79f4843b59dae80d3eda1a880457a1a68f2
Also some swaps from assertEquals to assertSame/True/False/Null
Change-Id: Ife497ae6cb1888b77eb25e85b76df72adc65641a
Returns an actual working ReadOnlyMode object
based on a ConfiguredReadOnlyMode and a mock
load balancer
Change-Id: I429c8e81343c24c536718b3fc112e797afbc05a2
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
After we updated the page row in WikiPage::updateRevisionOn(), some
fields in our mTitle – specifically, mLatestID, mLength, mRedirect,
mContentModel – are probably outdated. Use Title::loadFromRow() to
update them.
I put the loadFromRow() call very early in the block – specifically,
before the updateRedirectOn() call – because updateRedirectOn() already
potentially passes the WikiPage’s title into another class (LocalRepo),
and I want to minimize the risk of other code observing the outdated
Title (even though LocalRepo doesn’t currently use any fields that might
have become outdated).
Bug: T283654
Change-Id: Iacdacfd58a3e336e2d58dd7508d42d5afbb74500
These tests can be unstable as subsequent revision
may or may not have the same timestamp. This can
be problematic as we have tests that make sure Article
correctly uses the timestamp from the older revisions.
Bug: T282648
Change-Id: Ica585818faf6948249567cd3eacd29b0b63c0d38
Instead of always (except when reading from ParserCache),
using the latest version.
This can also clearly be seen by visiting an old revision on
Wikipedia (https://en.wikipedia.org/w/index.php?oldid=N)
and looking for "This page was last edited on …". When first
loading the old revision, the TS of the last rev will be shown,
upon reloading, the correct time will be shown (as the output
is fetched from parser cache).
This reverts the test removals from I83a43d651.
Bug: T282648
Change-Id: I517d4970d5c682489f27a65ba01ee30db9c62276
testViewOfOldRevision failed for me in CI, and I was able to reproduce a
2% failure rate locally using --repeat.
I also removed the assertion from testViewOfOldRevisionFromCache() for
consistency, although I wasn't able to reproduce a failure there.
Partial revert of 929dbef76d.
Bug: T282648
Change-Id: I83a43d65123304f3bac47869bbf3a9826873b397
This should not default to latest revision id, but
Article::getRevIdFetched() if the ParserCache doesn't
have the id set. Also set the revision id before calling
OutputPage::addParserOutput to make sure the id is
already set when the "OutputPageBeforeHTML" hook is run
(which is the case in other code paths).
Additionally I've made the tests more robust, by no
longer manually getting the revision into parser cache.
Bug: T281587
Change-Id: I999195441f9d75a7e4bde4d843ad7729cdb1bee0
In order to prevent bad titles from entering the database,
PageIdentityValue should not allow instances that have obviously broken
dbeys, just like it does not allow construction for a special page.
Note however that for now, we allow PageReferenceValue to represent
thigns that are not actual pages, such as titles like "User:#1234" which
are used in the block log to represent autoblock targets. Similarly,
a PageReferenceValue can represent a special page.
This patch introduces a convenience method for constructing
PageIdentityValues in a context where it is uncertain whetehr the title
is valid, providing an opportunity to the caller to report in which
context the bad values were found.
In addition, this patch adds some documentation and testing, to clarify
the semantics of methods in PageStore with respect to invalid and non-
proper titles.
Bug: T282070
Change-Id: I8a44d9e73dda8fe38d009847332946809767d0fa
JobRunner catches all exceptions and hides them in the status array,
meaning that it is not obvious when a job fails during a test case.
So, introduce MediaWikiIntegrationTestCase::runJobs(), which runs jobs
and asserts various things about the returned status array.
Depends-On: I4f4790c5d16a0767790eeff202e0be8fcdaeda93
Depends-On: I118f9e3f8950fd82d7b02baed6705b29fd6ab7d5
Change-Id: I63603aa158f77df4b40add096cb248f3b24979f4
The following methods no longer support Revision parameters:
- CategoryMembershipChange::__construct
- ContentHandler::getUndoContent
- DerivedPageDataUpdater::prepareUpdate
- DifferenceEngine::getRevisionHeader
The following methods were removed entirely:
- Title::countAuthorsBetween
The following methods return arrays that formerly include
a 'revision' key that would emit deprecation warnings when
accessed and return a Revision object. The Revision object
has been removed from the arrays, and the 'revision-record'
key should be used to get the relevant RevisionRecord instead:
- PageUpdater::doModify
- PageUpdater::doCreate
- Parser::statelessFetchTemplate
The ParserOptions `templateCallback` option is a callback
that is called in Parser::fetchTemplateAndTitle() and should
return an array - the 'revision' key to that array used to
be a Revision object and was used if no 'revision-record'
was returned - it is now ignored.
Bug: T247143
Change-Id: I163ada88d649c75697aff4fa31a3a3c0bdef78b7
- 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
It's the same and makes the test code much more readable, I
would like to argue.
Because of the was I split all the changes I made into smaller
patches this patch contains some other changes in the same
lines where I could not split them off. E.g. removal of
->any(), which is the default anyway and doesn't do anything.
Change-Id: Ib297b989d4aec33b31a4e33fe9d5032865b39be0
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
This explores the idea of a PageReference type which represents a
namespace/dbkey pair.
Every ProperPageIdentity is a PageReference. Some LinkTargets can be
mapped to a PageReference.
Bug: T279522
Change-Id: Id8b0c781fce329adcc4770f4840b2ba0108f6898
Code that needs to store an actor ID in the database to
represent a UserIdentity, or needs to construct a UserIdentity based on
an actor ID loaded from the database, should use the ActorNormalization
service.
Note: The getActorId() method is removed from the UserIdentity interface,
but all concrete classes continue to support it for now.
UsererIdentityValue::getActorId() is hard deprecated and should
be removed in 1.37. It always returns 0.
User::getActorId() is not deprecated at this point.
Bug: T274179
Depends-On: Id2b3ddf6a2a7cdf90f8936a69148d2cce6fde237
Change-Id: I9925906d11e47efaec3c1f48d5cb3f9896a982c1
Title::getPageLanguage has complex logic to determine the effictive
language of the page. PageRecord is a storage layer primitive and should
not haveknowledge of such logic, nor should PageStore.
The effective content language of a page needs to be determined
programmatically, see discussion on the ticket.
Bug: T278591
Change-Id: Ic26f6f7690499b3dd87982e3822881fd473cfd68
Still needs to downcast to WikiPage in 2 places:
1. To check get a ContentHandler and check if content model
is cacheable. We probably should just make all content models
cacheable.
2. To call WikiPage::triggerOpportunisticLinksUpdate. I have
an elaborate plan for this one, but it will be done separately.
Change-Id: Ifd9ab0155dc1fad0c1608dafea05d16292afd057
ParserOptions not updated cause they depend on Title::getLanguage
implementation.
Tests converted to not require a DB anymore. Can't be proper unit
tests yet due to globals in ParserOptions and fake time hacks,
but exec time does go down from 70 seconds to 9 seconds.
Page content model is still emitted in the metrics since
it was considered useful. Should be removed when we get
something like a page type concept.
Change-Id: Ib16fd0b5b87ffc3cb4d21f4aa43d1203cb7206d2
Bad redirects in the database led to fatal errors when attempting to
resolve the redirect when visiting the page. This patch does three
things to address this:
* change Title::isValidRedirectTarget to actually check whether the
target is a valid title.
* change WikiPage::recorddRedirectEntry to reject invalid redirect
targets
* change WikiPage::getRedirectURL to ignore invalid redirect target
that may be present in the database.
Bug: T278367
Change-Id: Ib17ebfb99fa17b846302438c675a968a1ec0f488
