None are used in WMF-deployed extensions and have been hard deprecated
for multiple releases as well.
Change-Id: I62cfa22291f81295b4908192de8657a750c6716d
This branch fails to compile against PHP 7.4.3, our lowest supported
version, and will not be updated to support that or any newer version:
https://tideways.com/profiler/blog/releasing-new-tideways-xhprof-extension
In doing so, remove the Xhprof class. At this point, it doesn't do
anything other than calling either of two functions from whichever
extension is installed, which can just be done in ProfilerXhprof.
Change-Id: Iba1c16f47c68b36982f5d2dcda3bdf4dcb83501d
In PHP 7.4, it's possible to compile password without Argon, but if
Argon is compiled in, both algorithms should be available.
So:
* Remove Phan stubs
* Simplify class code
* Add test per todo
Change-Id: I749d456ad59698e5b1538b127586ea796efba1d1
MediaWikiTitleCodec: I removed the comment about dbkey being
"conveniently nullified" since that is no longer correct. The first
preg_replace() can return null, and that is guarded. The second
preg_replace() hopefully can't return null, because if it does, trim()
will generate a deprecation notice on PHP 8.1.
Some other self-explanatory changes.
Change-Id: Iad0ace821eba782c3033ec8abfeac461ac4e8ace
for LanguageConverter
"Static default variant" language code won't always be the same of
"language code with converter" when there's one of the variant form
specified as the "default variant language" instead of "mixed-form".
We would like to specify "sh-latn" instead of "mixed-script sh" as the
static default variant language for ShConverter.
The function "getMainCode" was not renamed for compatibility.
Bug: T268033
Change-Id: Ibd0fadf9ba1f740cf4aed06e11138549c9d6dc9f
This restores a rewritten version of
commit 78483caaaf.
- Special:Contribute the default entry point in the menu when enabled
- Otherwise it will link to Special:Contributions (default behaviour)
Depends-On: I65336cfd56e1f6b92c1b3bc83cb5d91bbca065bf
Bug: T319327
Change-Id: I67779b88c4904462f9d847b3edb08a65306b2bfb
* Inline mbUpperChar(), which is confusingly named and has a rambling
doc comment which duplicates the config documentation.
* Memoize the Config::get() call.
* Add a multibyte no-op case to avoid memory allocation.
* Remove "experimental" tag from the config.
It's around 2x faster for non-ASCII input.
Change-Id: Ie88784a20d8b0b6f6c0efee5c940e3a9a06f4bef
Introduced in 2017 with I7f14b9ca2533032 (2e5eb693) but remains
unused at WMF, and disabled by default.
Follows-up I62107789fa (9e49260fc9) which added reap to LinkCache
test cases in 2021.
Change-Id: I0654c29a671467dd6b366f462d1c09b90a273413
This only supports WRITE_BOTH for now, the rest will be implemented.
Tested locally, works fine.
Bug: T318606
Change-Id: I6f898aa89f7d36f3f8a4eb8c23706c64a90896b0
Equals signs have special meaning in wikitext, they're used in template
parameters and headings. Allowing them in usernames complicates things
as it's not possible to use them in wikitext without escaping them.
This only prevents usage in new accounts, so it doesn't stop the problem
entirely, but it stops it from getting worse.
Bug: T254045
Change-Id: I07c0af2c5e44ff67fc0bc6c1ae1d4ce7255aa0cd
This allows config variables to be declared obsolete. Obsolete config
will be omitted from the schema, defaults, name constants, etc. The
purpose of keeping a declaration of obsolete config around is to allow
the updater to warn admins that they are using a config variable that no
longer has any effect, and provide them with a remedy.
The idea is that support for deprecated config can be removed after one
release per the stable interface policy, but the declaration of
obsolete config should be kept for as long as we support updates,
that is, at least two LTS releases.
See https://www.mediawiki.org/wiki/Topic:X4bh4nf3pe2ho5jj for
discussion.
Change-Id: Ia7a00742ea7a5311e820a6a43b11135a3f2a825f
This global variable was replaced by auto-discovery of parser test
files in extensions and is no longer needed (or used).
Change-Id: Ib616e60f36db32ffd8bc69c71a096f23c0a27910
This at least doubles the speed, which would allow the number of
iterations to be doubled and computation of the password hash to
complete in the same amount of time as before, or maybe even a
slight bit less.
The doubling in speed is due to an optimization[1] that so far has not
been accepted into PHP's hash extension.[2] In addition, OpenSSL has
optimized assembly-language hash function implementations for several
common CPU architectures. These provide a further, yet more slight,
performance improvement.
While OpenSSL's PKCS5_PBKDF2_HMAC() is not the fastest implementation
around, using it does not add a new library dependency. And although
better password hashing functions exist, PBKDF2 is still the default
in MediaWiki. For these reasons, I think this change makes sense.
[1]: https://github.com/openssl/openssl/commit/c10e3f0cffb3820d
[2]: https://github.com/php/php-src/issues/9604
Change-Id: I7b06590d4c42581f8749336f9c17777f973a506c
What was previously a REST API-only feature (the thumbnails
hook allowing for thumbnails for non-file pages via the
PageImages extension) is now also being adopted in the main
search page.
That hook will now be called with NS_FILE result thumbnails
pre-filled, which was not the case previously. PageImages
essentially duplicated NS_FILE thumbnail logic that was
already present in Special:Search, so that can (and will
in a follow-up patch) then be removed there. Special:Search
will then simply take whatever is produced from the provider
(which will include both NS_FILE thumbs - which it handled
already - as well as whatever else it receives from the hook),
as will the REST API (which already received both)
Since thumbnails can now come in for multiple namespaces &
having some of those results with & others without a thumbnail
can be quite jarring, it was decided that we'd display
placeholder images (for certain namespaces). This is now
controlled by $wgThumbnailNamespaces.
I also split up a few things in FullSearchResultWidget::
generateFileHtml for more clarity.
Meanwhile also updated mediawiki.special.search.styles.less
to use variables for known colors.
Also implemented a 'transform' (required for testing this
change properly) and 'getDisplayWidthHeight' (it became
needed after implementing transform) callback function for
mock Files, and updated some existing tests in response to
these changes.
And some more Rest test files have been updated to allow
passing around a HookContainer instead of only an array of
hooks (from which a new HookContainer would then be created)
to allow the same container to be used across all relevant
objects, who may have it injected as dependency.
Bug: T306883
Change-Id: I2a679b51758020d3e822da01a1bde1ae632b0b0a
This was introduced in 2015 with 8e3721a2b9 (Iadb34f24d8b, T89308)
as part of the Multi-DC initiative, with the plan being to use this
job when queueng jobs during a requests that are not guruanteed to
be routed to a primary DC (e.g. during a GET request).
Its use was removed as part of T181216, but the job was kept and has
seen numerous maintenance changes since. I propose we remove it as it
is no longer used in any Wikimedia Gerrit hosted code.
The expectation now is that JobQueue backends are responsible for
making sure new jobs can be accepted in any DC. At WMF this happens
by writing to local EventBus/Kafka and the internal streams converging
and mirroring in both directions.
The built-in JobQueueDB implementation is unlikely to be used in for
large wiki farms, but it too would support writes from secondary DCs
from post-send. I haven't tested JobQueueRedis, but it seems like that
could likely also be used in a way that writes locally and replicates
writes from secondary to primary.
Bug: T89308
Change-Id: Ia84d0e9ca047cd78ab8c0d0d055d4199d0e3e5b6
This policy was just the fall-back set in 2015 with the default length
of 1. As pointed out on MediaWiki-l, it is a bit short nowadays, so
raise it to 8 characters, which is what we use in Wikimedia production.
Change-Id: I4e0e57ed910a16804e015c9f1aaf48a5603bf95f
* CDB stands for "constant database" file, hence also changes references
to "constant" when likely intended to refer to CDB.
* Remove reference to non-existent docs/Configuration.md.
* Remove unused resetLocalCache() method. This was documented as
internal for testing only, but tests did not use it.
It was left behind in 2016 with I7d7424345d0ce3ce90 (025f15a208).
Bug: T315315
Change-Id: I61d9689160d9bf5715c4ff18009fbd16236d34e6
This reverts commit cfed8e7743.
Reason for revert: Will implement a hook rather than changing config at runtime
Change-Id: I5a941b871f9a6347744e800ea63cd82450ab6da3
This patch changes the Special:Preferences menu layout to display as a vertical menu. This function will only work for users with AMC enabled.
It also creates a variable (SpecialPreferencesUseMobileLayout) that changes when a user navigates to Special:Preferences on mobile and has AMC enabled.
Bug: T311717
Change-Id: Ia7a730cd7f009dbb921a810f27fae4a9ee66f793
When the deprecation of wikibits.js originally started, it contained
a ton of things [1] such as:
* user-agent utils, `clientPC` and `is_gecko`.
* addOnloadHook.
* importScript.
* appendCSS.
* stylepath and other config vars.
* tooltip, e.g. updateTooltipAccessKeys.
* portlet, addPortletLink.
* tablesorter, e.g. ts_makeSortable, ts_getInnerText
* searchsuggest.
* notify utils, e.g. jsMsg.
* spinner utils, e.g. injectSpinner.
* event utils, e.g. hookEvent.
* siblings scripts included: mwsuggest, sajax.
Except for two (addOnloadHook, and importScript), these have all found
new homes and been succesfully migrated and replaced over the years
with other platform APIs.
The $wgIncludeLegacyJavaScript variable hasn't been needed for a while
as what it gated no longer exits. Remove it and fold the two remaining
functions into mediawiki.base as defacto stable APIs.
* addOnloadHook: Not worth breaking imho. I've shortened the
implementation which saves a few bytes in WMF prod, and adds a few
bytes for CI/third-party where it was previously absent for new
wikis (thus reducing portability).
* importScript: Never deprecated in the first place as there is no
mw.loader equivalent to this. In order to achieve optimal cache
performance, and benefit from automatic purging after edits, one
must craft a very specificly encoded and ordered canonical
action=raw URL. This is not something end-users need to know about,
and is what imporScript exists for to abstract. Plus, it ensures
de-duplication. One day something like Gadgets 3.0 (T36958) might
take off, but for many years to come, importScript remains the best
and only supported and usable means within the platform to share
and load user scripts.
Tested with: `curl 'http://localhost:8080/w/load.php?modules=mediawiki.String%2Cbase%2Cuser%2Cutil&skin=vector' | gzip -9 | wc -c`.
Before: 9.53KB
After: 9.45KB
[1] https://gerrit.wikimedia.org/g/mediawiki/core/+/1.17.0/skins/common/wikibits.js
[2] https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)
Change-Id: I10f17f68fea862d510d188b927f4a7b38be0e4a4
Instead of checking the result of uncondiional `['host']` access in
the foreach loop afterward, check the result of url parsing directly.
Also:
* Switch to plain parse_url(), we don't support exotic input here.
* Move parsing to loop, minor optimisation, and will often thus mean
we don't even need to parse or check the LocalRepo case, since the
feature is generally only enabled when a cross-domain ForeignRepo
exists.
* Improve docs.
* Remove experimental warning.
Bug: T317329
Change-Id: I6492f5142861513e4a7eb65fe4c14fa12c46977a
The merge of the addition of the new file e36a8af and the creation of
the first patch for removal in the old file b90d2dd overlaps by time and
the information is still there.
Follow-Up: I736cb74efc267fd2473a3267471735238217251c
Change-Id: I6de1e6874206d8a9c7b207b6322d77f6472d22f5
The day has gone. Still keeping the code as the schema changes are not
done in production but the data migration has been finished.
Bug: T299417
Change-Id: I906e069a63d1dae14924c72318b22b16244371d6
The authentication provider's testUserForCreation() method is for
checking whether a given user name is available. The current
user being IP-blocked has nothing to do with that username's
availability so stop checking that. (AuthManager will check it
via AuthManager::authorizeCreateAccount() elsewhere. Although
that method doesn't seem to be doing anything useful and could
probably just be replaced with a direct call to
PermissionManager, but that's left for a separate, less risky
patch.)
Special-case autocreation though, which doesn't use
the more appropiate AuthManager::authorizeCreateAccount() for
performance reasons so it does need an IP block check.
(At least I think it is for performance reasons. Maybe it's
just an unintentional omission, and that should be used instead?)
While we are at it, also fix a TODO in AuthManager where partial
blocks were taken into account for $wgBlockDisablesLogin, and
clarify in the config schema that they aren't, improve some
comments to make it more obvious why some things are/aren't
done in CheckBlocksSecondaryAuthenticationProvider, and make
the logic more similar to the one in testUserForCreation().
Functional changes:
* Partial blocks are ignored for authentication, account
creation and autocreation.
* On $wgBlockDisablesLogin wikis IP blocks won't prevent
login anymore.
* On $wgBlockDisablesLogin wikis, blocks will now prevent
account autocreation even if they are not configured to
prevent account creation. The assumption is that on such
wikis account creation is restricted via some means.
This probably isn't necessary as blocks should also prevent
the conditions needed for autocreation (e.g. log the user
out centrally), but can serve as defense in depth.
Along with the special-casing of autocreation, this means
on such wikis any IP block will prevent autocreation, which
is not great but seems not worth even more code complexity
to avoid.
* The action=query&list=users&usprop=cancreate API won't take
blocks into account anymore.
Bug: T306018
Bug: T208895
Change-Id: Ie94d61640301192b287275311f3452e606469d25
We’ve been using it in production for two months without issues as far
as I’m aware, so let’s start documenting it as a more permanent feature.
(After all, people querying the table, e.g. via Quarry, need to be aware
of it.)
Bug: T306589
Change-Id: I66d405b34f02c57a337d196124c0d5a4d3a3b20b
When $wgWatchlistExpiry = true and a user adds a page to their
watchlist, they are currently presented with a combo box where they can
pick a duration of permanent, 1 week, 1 month, 3 months, and 6 months.
This patch adds 1 year to the combo box, and raises the maximum age to 1
year. `api.php?action=watch&expiry=1 year` will now also work.
Bug: T313255
Change-Id: Ia84d6f99584ae23feea3831499d5baee2dd1a024
