Follows-up I8808cad03418 which added this option, but I neglected to
actually test it. When trying it out with a patched wmf-config on
a mwdebug server, the following issue surfaced:
> Fatal TypeError: Argument 1 passed to XhprofData::__construct() must
> be of type array, null given, called in ProfilerXhprof.php:90
This is because ProfilerXhprof::disable() actually has its own state
tracking which refuses to even try calling tideways_xhprof_disable()
unless its state says it was in control of enabling it.
Remove this check and reduce the class to just abstracting the calls
to the PHP extension.
Also, remove the useless null return which is incompatible with the
callers to this function as evidenced by above Fatal TypeError.
The PHP extensions already default to an empty array, which is now
documented.
Test Plan:
* Local wiki with php-tideways installed, on this pach applied.
Note that MediaWiki-Docker now has php-tideways pre-installed!
* In LocalSettings, configure profiling as per
<https://www.mediawiki.org/wiki/MediaWiki-Docker/Recipes/Profiling>
$wgProfiler = [
'class' => ProfilerXhprof::class,
'output' => 'text',
];
* At load.php?forceprofile=1, there are valid percentages (100% "main").
* Add `tideways_xhprof_enable();` and `$wgProfiler['running'] = true;`
to LocalSettings.
The percentages are still valid, and the profile is now longer
with additional coverage of early code such as MediaWikiServices.
* Switching to master, there is a fatal error with these settings.
Bug: T247332
Change-Id: Iaad88a0c46d39aee1374e5b02a77251bfa4c6f09
=== Why
* More speed
In debug mode, the server should regenerate the startup manifest
on each page view to ensure immediate effect of changes. But,
this also means more version recomputation work on the server.
For most modules, this was already quite fast on repeat views
because of OS-level file caches, and our file-hash caches and
LESS compile caches in php-apcu from ResourceLoader.
But, this makes it even faster.
* Better integration with browser devtools.
Breakpoints stay more consistently across browsers when the
URL stays the same even after you have changed the file and
reloaded the page. For static files, I believe most browsers ignore
query parameters. But for package files that come from load.php,
this was harder for browsers to guess correctly which old script URL
is logically replaced by a different one on the next page view.
=== How
Change Module::getVersionHash to return empty strings in debug mode.
I considered approaching this from StartupModule::getModuleRegistrations
instead to make the change apply only to the client-side manifest.
I decided against this because we have other calls to getVersionHash
on the server-side (such as for E-Tag calculation, and formatting
cross-wiki URLs) which would then not match the version queries that
mw.loader formats in debug mode.
Also, those calls would still be incurring some the avoidable costs.
=== Notes
* The two test cases for verifying the graceful fallback in production
if version hash computations throw an exception, were moved to a
non-debug test case as no longer happen now during the debug
(unminified) test cases.
* Avoid "PHP Notice: Undefined offset 0" in testMakeModuleResponseStartupError
by adding a fallback to empty string so that if the test fails,
it fails in a more useful way instead of aborting with this error
before the assertion happens. (Since PHPUnit generally stops on the
first error.)
* In practice, there are still "version" query parameters and E-Tag
headers in debug mode. These are not module versions, but URL
"combined versions" crafted by getCombinedVersion() in JS and PHP.
These return the constant "ztntf" in debug mode, which is the hash
of an empty string. We could alter these methods to special-case
when all inputs are and join to a still-empty string, or maybe we
just leave them be. I've done the latter for now.
Bug: T235672
Bug: T85805
Change-Id: I0e63eef4f85b13089a0aa3806a5b6f821d527a92
This is in preparation for making all version hashes the empty string
in debug mode, which will make things faster to work with, but also
helps solve T235672 in an easy way client-side without having to
add additional complexity to the mw.loader client that is specific
to debug mode.
Bug: T235672
Change-Id: I43204f22dfbcf5d236b35adc5b35df3da8021bad
By analogy with slow-parse.log. Also, I fixed the log message so that it
has the full title in it.
Change-Id: Icaeb6f002c5c2a676467d4c760f99cb2676ad73b
The skin methods serve BaseTemplate so are moved there. The associated
hook is seldom used so deprecated.
Bug: T290583
Change-Id: I166241fc88b98603f8d5489643eda984f49bad66
This allows these rows to be highlighted on Special:RecentChanges and
similar pages, and allows site CSS to target them as well.
Bug: T281741
Change-Id: Iebe234166d76e19736f626370b0384c49ceb1355
This reverts commit 0d453d915a.
Reason for revert: Trying to find a better approach than an abstract class
Change-Id: I69c0ec25cb920f41cb0eb6b3ad921d7b02290581
Building on my last few changes to use UserIdentityLookup and
TitleParser, plus the recent addition of UserNameUtils to the
DummyServicesTrait, its now fairly simple to make this a unit
test and retrieve services from DummyServicesTrait instead of
MediaWikiServices.
Add a 'hookContainer' option to
DummyServicesTrait::getDummyUserNameUtils(), because
subclasses of TypeDefTestCase don't have a helper method
createHookContainer() (normally this is provided by
MediaWikiTestCaseTrait). Instead, create a manual mock
HookContainer, like we did previously at NamespaceDefTest.
Also add more options to DummyServicesTrait to allow
callers to provide service instances, needed to avoid
creating two MediaWikiTitleCodec objects and to use
a hook container in NamespaceInfo.
This also required replacing uses of createNoOpMock()
in DummyServicesTrait, because that is also not available
in UserDefTest (its another feature of MediaWikiTestCaseTrait).
It may be worth exploring splitting MediaWikiTestCaseTrait into
the parts that are specific to MediaWiki (like HookContainer
or the Message system) and parts that are useful generally
(like createNoOpMock).
Change-Id: I25b8f0256d222d994173eee66f379fb5422994b5
The User class sets the name to be the context ip when creating based
on id 0, and the switch to UserIdentity(Value) matched that behavior,
but its likely unexpected for callers - treat 0 the same as other
ids that don't correspond to existing users by returning a
UserIdentityValue with an id 0 and the name "Unknown user".
Bug: T288311
Change-Id: I9763e4c1e17de8930e0f982ea868405db20a8efd
Migrate away from the Title object, use
TitleParser::parseTitle() which returns a
TitleValue which is enough. Will be followed by
switching UserDefTest to a unit test, but in a separate
commit.
Change-Id: Ia756964861c4e0f3edea89f6beec2643243ca741
Maintain the existing behavior for creating based on a user
id or name that does not correspond to an existing user:
* if creating a User object based on the id 0, User::loadFromId()
will load the defaults with the name being set to false, and
User::getName() will convert that false to the ip of the current
request. We probably don't want UserDef to be doing that, but
this behavior should be changed separately - at the moment
we are just matching the existing behavior (see the prior commit
which adds tests to confirm the behavior isn't changing)
* if creating a User object based on an id that cannot be found
in the database, User::loadFromDatabase() will load the same
defaults, *except* that it will set the user name to "Unknown user"
* if creating a User object based on a name, User::getId() will,
if the id isn't already known, return 0 if the name matches
UserNameUtils::isIP() or ExternalUserNames::isExternal(). However,
the User object is currently only created based on a name after
passing an ExternalUserNames check, and the creation with
RIGOR_VALID prevents it from being an ip. Thus, the existing
code will call User::load(), which will check the database or
fallback to 0 if the user does not exist.
When creating a User from an id that does not exist, User::getId()
will return that id, until after the object tries to fully load,
after which it'll return 0 for the id. Since we cannot replicate
this with UserIdentity (switching the id to 0 only after getName()
is called for the first time) we set the id to always be 0, which
is more accurate. This is the only change in behavior.
We will remove the use of the context ip in a follow-up that will
switch to using "Unknown user" instead.
Accordingly, we will use a UserIdentityLookup as well as
manual construction of UserIdentityValue objects to match this
behavior.
Bug: T288311
Change-Id: Ida80c5d04d721fafa8d66f656dbd346c6cf643eb
Deprecating different mixins, where we forecast basic supported
browser will be unprefixed at time of MediaWiki 1.38.
Change-Id: I4dc902aa9d7eb6a42085b91fd78bb4281b8a933f
Our basic support has been updated and Firefox supports replacement
`resolution` since version 8 or 16, depending which data source
one checks.
WebKit's support is a bit more complex and it seems like safest bet is
to leave its vendor prefix in for now.
Bug: T277803
Change-Id: I752f0b67672759824099b4b78892d143344e766f
Handle edge case of fast callbacks that happen to run just before
the transaction age reaches MAX_READ_LAG. Such callbacks will no
longer be considered "slow".
Distinguish slow and fast regenerations for the case when TTL
mitigation is triggered by the combination of snapshot and
replication lag.
Reduce the cases where TTL_UNCACHEABLE is used as the mitigation
TTL, to avoid operational risk.
Simplify the mitigation TTL code by reducing needless variation
between the "lockTSE" and non-"lockTSE" cases.
Track the key and time of the last 10 get() calls that returned
either a stale value or no value at all. Use this this estimate
the walltime in set(), if it was not provided.
Bug: T285070
Change-Id: Ie6c88fbf7dbfc831d67bfb6cde082c123555a8cf
The mw-ui-icon-with-label-desktop class allows a label to hide
at mobile resolutions and display at desktop resolutions.
it was broken by the recent change to mw-ui-button.mw-ui-icon-element
so this code needs to be slightly adjusted for its existence so it
can be used in Minerva.
Bug: T288678
Depends-On: I4675be1e0b4b2a2a34507d85c551cc3234f1a9f6
Change-Id: I4eb28eae4c4e23d58f1f85bc41c0caf77197d8a1
Only used in a single place in the store, the other usage was just
removed. Has no references from outside of the store.
Follow-up: I19721db51b2edf5f416f3a6b629d6ee002f608ec
Change-Id: I5b931a7d51b924a121d165bd42f0be28c6415842
In 2015, when we stopped storing modules that were larger than
100kB, we also started checking the size of existing stored modules
on each prune() call to handle any oversized modules already
stored. This check should no longer be needed, because
any oversized module still stored from back then would be pruned
for having an outdated version anyway (versions changed from 7
characters to 5 in 2019, so even if the code hasn't changed the
version hash has).
Bug: T290705
Change-Id: I19721db51b2edf5f416f3a6b629d6ee002f608ec
