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
- 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
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
WikiPage::getContentModel() gets called several times per request via
Action::getActionName(), triggering memcached I/O on each call. Excimer icicle
graphs for index.php indicate about 1.26% of time is spent in this method, so
let's add process caching to avoid redundant memcached fetches on subsequent
invocations.
Change-Id: Icdb9ffb849a0a0a264083957431495f8f4fb783e
The method is called from two places:
- For new revision ParserCache, when the subtitle doesn't need
to be applied. That call is protected by !oldid check
- For old revision cache, when subtitle is already applied before
checking the cache. So, no need to set it.
Bug: T269727
Change-Id: Ibec845ccfe43ae2cb4bbe0152c932cb74f3cef4b
The links use {{FULLPAGENAMEE}} magic word which would resolves to
'Special:Undelete' on the diff page, therefore giving wrong target
title for the logs
Bug: T196669
Change-Id: Ibcd58cea23dbca8e24b638c6f6ee5e764f32ff26
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
Returns a Revision object; only deployed uses are in core
Make fetchRevisionRecord public as the replacement
Also removes a use of Revision::getContentHandler
Bug: T249393
Bug: T250981
Change-Id: Ib8f399e451c3a9b942001b48ea9a138f405c894c
Deprecated since 1.32, and no longer used anywhere.
It is referenced in ApprovedRevs, but conditional on a MW < 1.35
context only.
Change-Id: I415927f198473ae3e795fac8c4811690424f167a
This patch fixes all PHPUnit 8 compat issues in the DBless suite, aside
from assertArraySubset.
Bug: T192167
Change-Id: Iea782386509b9e579f06d63687669e14bc437fad
This was done automatically by replacing every assertContains with
string *needle*. Then verifying the results.
Bug: T192167
Change-Id: Id8cbbf3b01e948f80046714183cc299f86be21fd
Function Content::getNativeData() was deprecated. Replace with
calls to new function TextContent::getText() in most places.
Bug: T155582
Change-Id: I2bd508c72aac4faf474ba45ab1f92e2e8d2eb9be
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
The old behavior was that the audience was RAW if the revision object
parameter got passed in, otherwise PUBLIC. This was undocumented and
not used outside core; this patch gets rid of it in favor of an
explicit argument.
Bug: T205578
Change-Id: Ic7cdb38f658f6d85c48ff13c7f84c64a45c9b1ee
