We already had a $filterCacheVersion variable, but it was
only used for the internal cache for JS and CSS minification,
which is not enough. If there is a breaking change in either
of these processes, we also need to invalidate version hashes.
This commit renames ResourceLoader::$filterCacheVersion to
ResourceLoader::CACHE_VERSION and takes it into account in
getVersionHash(). Adding it to getDefinitionSummary() is not
sufficient, because content-hashed modules also need to be
invalidated when there's a breaking change in the minifiers.
This cache version can also be incremented when there's a
breaking change in image embedding or LESS compilation,
although content hashing deals with that already, so we
could also add a separate cache version for those that's
only added to getDefinitionSummary().
Bug: T176884
Change-Id: Ife6efa71f310c90b9951afa02212b2cb6766e76d
This seems quite nuclear. I'd actually like to deprecate the
wgCacheEpoch variable more generally in favour of a handful
of more specific version constants, but as starting point,
remove it from the hash used for load.php urls and localStorage
keys.
The latter is also controlled by wgResourceLoaderStorageVersion
already.
Also ref T32956 about a more standalone ResourceLoader.
Change-Id: I913f846090e82d3d822653b9b7ce22233cdb5e90
If users provide invalid input to the date option on Special:Log (most likely
an intentional thing given the calendar input widget), don't let the
TimestampException bubble up - just discard the invalid date.
Integration test included, which fails without this patch.
Bug: T201411
Change-Id: Ie1a9a84343ae4e78e076586f759917e5fd5af33c
While MediaWiki Core already sets requirements for PHP versions, it should be
possible for extensions to tighten these requirements. This mirrors the PHP
parameter of extension infoboxes as well.
This change introduces a new 'platform' key (in addition to 'MediaWiki', 'skins'
and 'extensions', where non-MediaWiki software requirements will be listed
in the future, starting with a PHP version constraint. Further keys are
supposed to be added to allow setting constraints against php extensions
and other abilities of the platform.
Bug: T197535
Change-Id: I6744cc0be2363b603331af9dc860eb8603a1a89a
This has been soft-deprecated since MW 1.26; this hard-deprecation
sets the stage for future removal of this old cruft.
Bug: T198214
Depends-On: Idf246d05d116f63a73105b50a1929a7721fbe7b9
Change-Id: I2e7d990da1da378eb6e828d4b3c0f5a41791dd92
This changes the user name to "User unknown" when constructing a RevisionRecord
from a database row that has an empty ar_user_text resp rev_user_text field.
This may cause "User unknown" to be written to the database, if the
RevisionRecord is used as the basis for a new revision that is being created,
particularly during undeletion. Since "Unknown user" is listed in
$wgReservedUsernames, this should never lead to conflicts with actual user
names.
It is assumed that empty ar_user_text and rev_user_text fields will be
fixed during migration to the new actor based database schema.
Bug: T195692
Change-Id: I506c513b019778d83741e47f0d11093f5ab67a54
Expose this constant for internal use by Navigation Timing,
so that it can compute mwLoadEnd based on when these modules
finish loading.
The way mwLoadEnd is currently computed is by building a list
of all registered module names, and narrowing it down to the
ones in 'loading' state at the time that ext.navigationTiming.js
executes. The problem with doing that, is that it is includes
various lazy-loaded modules that aren't critical to the page and
aren't meant to be tracked by that metric. For example:
* Preloading of modules from various extensions (including VE,
and Popups).
* Background chains for EventLogging schemas from mw.loader.using,
including the one started by Navigation Timing itself.
On my local install, the list of filtered down modules always
includes 'schema.SaveTiming', '...rumSpeedIndex', etc.
Exporting the list passed to the initial load() call as constant
will enable Navigation Timing to instead only await only those
modules (and their dependneices).
Bug: T204426
Change-Id: Ida134b4dfee218db16c2d1f88d4f26e8d761e154
* There is only a single non-test caller to this method in the entire
codebase, and no callers elsewhere (Wikimedia Git, Codesearch).
It's only used with an array, so remove the other unused code paths,
and mark it internal (to my knowledge, nothing ever used it outside
RL in the past, either).
* Add test coverage for the module indexing logic.
Change-Id: I9e0f95416d5b2fdd87323288231ee6d8c85d88e7
Added spaces around .
Removed empty return statement which are not required
Removed return after phpunit markTestIncomplete,
which is throwing to exit the test, no need for a return
Change-Id: I2c80b965ee52ba09949e70ea9e7adfc58a1d89ce
This adds getSecondaryDataUpdates and getDeletionUpdates
to ContentHandler, and updates WikiPage and DerivedPageDataUpdates
to handle DataUpdates from all slots.
Bug: T194038
Bug: T194037
Change-Id: I75c96318f58a5cdda48484f7040ae41e6f42392a
Neither SpecialWatchlistFilters nor SpecialRecentChangesFilters are used in any
code known to Wikimedia code search. The related code to use these hooks was
only ever used within the MediaWiki repo.
Change-Id: Ib631d49d7b5835c665171dbad3e8a646b80827ef
This is intended to isolate parser tests from other tests
by resetting the service locator between test runs, just like
MediaWikiTestCase does.
NOTE: this has no effect on parser tests run via parserTest.php,
it's only for tests run via PHPUnit.
Bug: T204065
Bug: T204072
Change-Id: I772b3b4a2d4d98948a249603b1cdb0933427b01c
When submiting using the 'go' feature of Special:Search (standard
usecase for autocomplete) a nearby title can be selected.
Unfortunately a fragment only title is considered valid, which
sends the user to Main_Page#searchterm.
Instead don't allow a search starting with # to trigger the go
feature.
Bug: T182452
Change-Id: I8ce3ce8633e23db41ae6eafb9996ca7294f8445a
This introduces a check that allows magic words like {{REVISIONUSER}}
to still work even when an incomplete fake RevisonRecord is provided to
RevisionRenderer. In such a case, the revision is loaded from the database
if needed. This lets old code that only has access to a Content object for
rendering use that Content object in a fake RevisionRecord, instead of
having to load the full revision from the database in all cases.
Bug: T174035
Change-Id: I658eab97a8282b8943baf7968f3256da35789ec1
RevisionRecord::isReadForInsertion provides a concise way to check
whether a revision is complete enough to be inserted into the database.
Change-Id: I0c79f55c0b935bce9943163ed4c2cc8b5f9c82d5
This patch exists to see if CI passes with
$wgMultiContentRevisionSchemaMigrationStage set to
SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW.
NOTE: verify that $wgMultiContentRevisionSchemaMigrationStage
is explicitly set toSCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_OLD
in production config (T197816) before merging this.
Bug: T198561
Depends-On: Ib718868d2c768b6ea851355eef047bc0e6593495
Change-Id: I15989adae2b5916577d164c50d7da88774e49324
