Includes the new $wgWatchlistExpiry feature flag.
Consumers of WatchedItem and WatchedItemStore have not been changed to
make use of expiries, this along with associated UI changes will be done
in a separate patch.
Bug: T245213
Change-Id: Ifff5e56e0222bb325cf796e0aa3d88825820d1fd
As long as no parsing was started, and $this->startParse() was not
triggered at least once, the $this->mOptions property is null. This
does have a lot of consequences. I'm intentionally not fixing all of
them in this patch to not make it to big, only the most obvious ones.
This came up in I6714400 which was actually running into this issue.
This patch also removes a few comments that *literally* repeat what
the code already says. Such comments are not helpful, but clutter the
code, make it harder to read, and create error-prone redundancy.
Change-Id: Ic1ab18242b2f79d3da2a2e7c25e3af3e6907f7b4
I seriously hate jQuery for the way it concatenates strings to construct
long event names that can not be found when searching the code. This just
confused me again in Id8229e9. Let's please document this so we can find
the event name when searching for the string.
Change-Id: Ica19ee440a3ebe952ef1f2f883e2cbf893cbd879
* getSetting() was retreiving the overrides array from $this->settings
by settingName. But, the getAll() caller already had this array
locally available from its foreach loop as "$stuff" which was
previously unused.
The protected getSetting() was renamed to processSetting(),
and now takes this array directly.
* Remove the code duplication in processSetting() for handling
of 'tags' and handling of 'suffix'. Instead, treat the 'suffix'
as an extra tag internally, which is exactly how it was behaving
already. This happens in mergeParmas(), which now documents this
feature and what it means practically.
This means for WMF that it can remove the duplication between
$wgConf->suffices and wikifamily dblist files. These are redundant
given the suffix for those wikis is identical to the tag name.
This will save about a dozen dblist file reads in production,
once we utilize this decade-old feature.
* Rewrite the internal do-while in processSetting() in a more
procedural fashion. The only reason it used do-while was to
perform an "early return" from the given block in two places.
One was rewritten with a simple if/else that devides before/after,
and the other was rewritten by explicitly tracking the action it
wanted to skip (which is: applying of 'default' value').
* Document this scary code, including the various anti-features
I found along the way (such as 'default' overridding '+wiki').
No changes in behaviour for now.
Bug: T169821
Bug: T246858
Bug: T246213
Change-Id: I723133e6814a5d15c3b0b9e785921505ec7b9a69
* Remove the ButtonSelectWidget wrapper, use ButtonGroupWidget
instead. The two buttons are independent, and only grouped visually.
We did not even use the selecting feature (we reset the selection
immediately after a button was chosen), and the keyboard navigation
between two buttons was confusing because of the overridden styles.
* Re-add an ARIA label (and title) on the "Tags" button, which was
accidentally removed in b988627835.
* Remove the ARIA label on the obsolete ButtonSelectWidget wrapper.
Change-Id: I3420a5426dc0fa835c156559323c670fb440478e
If the username isn't valid, $performer is just false and not the
invalid name. For the other prints, use $performerName directly instead
of relying on User::__toString.
Change-Id: I22ad6f98a14a69ea13aa794b45869dd2eb747dee
Changes:
- Update TemplateParser::compile to return all files read during the
compilation of the template and the hash of those files
- Tweak the cache invalidation logic in TemplateParser::getTemplate
accordingly. This is made trivial due to the friendly design of the
FileContentsHasher::getFileContentsHash.
Bug: T113095
Change-Id: I948fdaecf720d7d16c5ccabb2d7f01b5cbf27c90
The runtime numbers in each bullet point are based on a local
benchmark that use a copy of WMF's InitialiseSettings.php file
to compute enwiki's $globals via SiteConfiguration::getAll().
Source code and results can be found at
<https://gist.github.com/Krinkle/2ef2fe72218b5f5cea91679df56a0b18>.
* The getSetting() method (called by getAll) was iterating over
each find/replace pair and performing a separate call to str_replace()
via doReplace().
Instead, iterate the pairs only to create a replacements array
(this array differs from the pairs in that it has a leading "$" in the
search keys), and then call doReplace() once for each setting value,
instead of multiple times.
Also, switch from str_replace() to strtr() while at it (which promises
to only search the string once, instead of repeatedly until it no
longer finds any of the search patterns).
Also also, generate the replacements array outside the getSetting()
method and do this in the mergeParams() method instead, which is called
before the getSetting-loop in getArray begins, thus further reducing
identically repeated work.
In my local benchmark for WMF/enwiki this reduced runtime from
~7.5-8.1ms to ~6.9-7.3ms.
* The getSetting() method was using a by-reference assignment
for a local variable that would hold a read-only copy a class member
`$thisSetting =& $this->settings[$settingName];`.
This was presumably a PHP4 or PHP5 era optimisation to avoid
an eager memory copy given the promise to only read the data.
However, in PHP5/PHP7 this is redundant given that PHP
does copy-on-write.
Removing the "&" symbol here made a drastic perf improvement,
reducing my WMF/enwiki benchmark runtime from ~6ms to ~1ms.
Bug: T169821
Change-Id: I0e8b395920c143f2b42f9d87c1afaffa2bfdaf2e
Update TemplateParser::compile to return the PHP code and metadata. The
metadata includes details about the compilation that can be used to
validate that PHP code fetched from a cache is fresh without having to
recompile the original template.
TemplateParser::getTemplate did have such an invalidation mechanism but:
- It stored the hash of the template file in the key
- It stored the hash used for checking the integrity of the cached PHP
code in the first 64 bytes of the value
This tight coupling between the compilation result and the contents of
the cache key/value made changing either the compilation or cache
invalidation steps difficult.
After this change, arbitrary metadata can be added or removed from the
compilation result.
Changes:
- Move all filename generation and reading to TemplateParser::compile
and align its signature with ::getTemplate
- Update TemplateParser::compile to generate the file hash with
FileContentsHasher::getFileContentsHash, which is used by
Resource Loader to generate file hashes, and return it as part of its
result
- Update TemplateParser::getTemplate to store the integrity hash in the
compilation result prior to caching it
- Bump the cache key major version as both the key and value have
changed
Note well that TemplateParser isn't expected to be subclassed, and
::getTemplate and ::compile are protected members and are therefore out
of the scope of MediaWiki's deprecation policy.
Bug: T113095
Change-Id: Ifb5e122c6ae238fd300cd60f2b1ab33b7ece8e71
Apply the same duplication logging and asyncHandler defaults for
factory-based entries as constructor-based entries.
Change-Id: I2aa835c5ec7932432d2c739ffa761a7bd9c21198
