This was added in 381499a675 in response to the issue that when a skin
adopts a feature that was new in MW 1.36, it caused an exception when
that version of the skin is then installed on MW 1.35. That's expected,
and generally helpful because the default support policy requires
like-for-like (MW 1.35 with REL1_35, this applies to all skins and
extensions, except for a few like Translate and SemanticMediaWiki).
However, while supporting LTS within master is unusual, there are
indeed the Translate/SemanticMediaWiki projects, and this problem has
already been solved years ago there by using a conditional with
$wgVersion. The proposed approach on T271441 actually also involves
such a conditional, but late at runtime instead of in the module
definition. Anyway, the way it was fixed in Timeless already solves
the problem by not passing down the invalid feature in the first
place, thus making the 381499a675 patch obsolete. I'm not aware of
any skin in Gerrit having such a compat policy, but if they exist,
they can fix it the same way, by defining the module in code with
a condition, just as Translate/SemanticMediaWiki do.
Bug: T271441
Change-Id: If97b3d04ac1e3355ee4f229db11e524d24ebd27a
* Remove odd use of ResourceLoaderFileModule::extractBasePaths()
SkinModule.php which was basically just returning $IP.
* Use getConfig()->get('ResourceBasePath') so that the test does
not need to override global configuration variables.
Follows-up 6845912bcf and f1457312dc.
Bug: T277728
Change-Id: I64262b48bb5dc71c53b4114eddb2f080a6a076f5
* Remove confusing dead code for T271441, as a continue statement at
the end of a loop body does not do anything. I'll reinstate the
exception once we've looked at whatever skin caused the issue and
have fixed those repos to not pass invalid options.
* Simplify list creation by avoiding the loops and duplicate logic.
Assign the list directly when possible, and otherwise store the
filtered keys.
* Remove unexpected access to `$this->getConfig()` in the constructor.
Follows-up a6c769e976, which worked by accident due to it defaulting
to global state. The injection from ResourceLoader::getModule happens
after the constructor. I am working on a patch to enforce this, and
thus this change needs to land first.
I've moved the logic to getStyleFiles() and boldly changed it to be
a simple skip rather than based on whether it was specified. If this
is a problem we can find a more complex way, but I wanted to try this
first. It seems there is no reason to load these, specified or not,
when the parser feature is not enabled. (Ref T266148)
The unit test was working around this violation in a similar way,
which is now redundant and removed in this patch.
* Document that compatibility method only works on map-form.
* Make applyFeaturesCompatibility() an internal and protected
method. I don't think we'd support extensions calling this
directly.
* Limit applyFeaturesCompatibility() to just dealing with
the features array instead of also handling other options
and applying of the default value.
Bug: T277728
Change-Id: I24a2b783570c888cedee66885647b3ed765e0132
1) Rename content-parser-output to `content-body`
Widen the scope of this module to apply to anything that can be rendered
as the article body. Improve the documentation on what is allowed here.
For early-adopter skins already using content-parser-output,
map the feature to the new name and add tests.
2) Reclaim the `mw-body-content` class for result of
SkinTemplate::wrapHTML
The `mw-body-content` has been used in skins to wrap various elements.
Going forward we will use it to wrap any HTML content generated by
OutputPage.
See dependent patches, which we're not directly depending on to avoid
a CI gremlin:
- I90d85c21f4a62e6697f24e3ce388445a0a53c2b0 (MonoBook)
- I11242e243c9a529b72972089af9ac2a8c906331a (Modern)
- I87942c60e62f6f14acdfeaa1836ace4eac9252ac (CologneBlue)
- I4c1b15d90bacbc9b13782a1d8f52e838ce8ecd83 (Vector)
Bug: T279388
Change-Id: I3a91b294fcb3724cd46743e497dff723de0490a6
Instead of depending on full User objects, accept
UserIdentity(Value), we only needed User::getTalkPage
but that is trivial to recreate with UserIdentity.
By switching to UserIdentityValue objects, we can specify
the user id easily and not need to load from the database.
Also, give the anonymous user an ip address for the name.
Use a data provider for doTestUserHasNewMessages
Change-Id: I4d1d0226aeee154db42a31b56873e428cd46b64f
Use was removed in I7dc3fe90385c8066b89a5e06c55f5455edfbb4ca
when the logic that was using it was moved to MediaWikiTestCaseTrait
Change-Id: I3be7fdb0ad3e76d0f0bff713c21cb9216b77ee20
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
In all these cases the property is unconditionally set in
the constructor. The extra initialisation is effectively
dead code and an extra source of errors and confusion.
Change-Id: Icae13390d5ca5c14e2754f3be4eb956dd7f54ac4
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
MediaWikiIntegrationTestCase::overrideMwServices() is not static
and should not be called statically
Change-Id: I9d1f07b5bca8a39b82017e59978f2b28c399803e
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
When block restrictions are queried from the API, return the name
of the action blocked
Bug: T280566
Change-Id: I2e639864cfcdd3854fd67173b138fe8eb6f877cb
In order to allow Authority to know about user blocks,
we need a narrow interface to represent such blocks.
This deprecates some methods on AbstractBlocks in favor
of new methods on the Block interface that avoid binding to
the User class.
Bug: T271494
Change-Id: I7bb950533970984a014de0434518fbbefb695131
This allows deferred update tasks to be constructed with a PageIdentity
rather than a Title instance.
Bug: T278459
Change-Id: Ifa2888fdef9ecc97f5bf09ae0b3fa7be48a0e9ef
As previously discussed, the database should usually not be mocked. I'm
changing many of these queries for the next stage of the actor
migration, and just copying my own query from the code to the test file
does not give me any confidence that the query I'm writing is correct.
The unit test was simply ensuring that the implementation of the class
doesn't change, it wasn't verifying correct operation.
Change-Id: Id3ee02fd547d0a7b5b7f35866ee317e8b09e6c18
