Added an optional RevisionRecord param to:
- ContentHandler::getParserOutputForIndexing
- ContentHandler::getDataForSearchIndex
- the SearchDataForIndex hook
So that they have a chance to build the content related to a specific
revision.
Ultimately we'd like to make this parameter mandatory.
Bug: T317309
Depends-On: I8b220cd6c4aeeca1d924bdd527409b8602318944
Depends-On: I8616b611caab3f5fa97ff0e655b19c3034304597
Change-Id: I3298ce7591069eb32f624b2c9fbb6de58ae04a29
MessagesRki.php is mostly copied from MessagesMy.php.
Date format in the same as in Burmese, as confirmed
by User:YaThaWinTha, who also contributed namespaces at
https://incubator.wikimedia.org/wiki/Talk:Wp/rki/Main_Page
Bug: T320912
Depends-On: I582550df8fd5887b48dbf5c98e51551629d8e734
Change-Id: I4180431cf70c23eadd16c55389f08a78700f4777
This obscure class could only be used by running file_locks.sql and
customizing $wgLockManagers. It was not worth the overhead of having
to maintain it.
Remove DBLockManager since there are no subclasses now.
Change-Id: Id7e3fde02dfca02271bcec039be5c079de9de830
* Remove some use of `count()` in favour of boolean checks.
* Where trivial to do, add native return types to remove doubt
of the value possibly not being an array.
* Follow-up I7d97a4cdc9 (d4df7daa) and mark more methods as private
that were wrongly marked public en-mass when we added visibility
attributes but have no use outside core on a SpecialPage class that
generally has no use case for being extended or instantiated
outside core.
Change-Id: Iaf28b6132097fe34872c2a2da374ff00593ca6a9
This global variable was replaced by auto-discovery of parser test
files in extensions and is no longer needed (or used).
Change-Id: Ib616e60f36db32ffd8bc69c71a096f23c0a27910
Dumping many kinds of object with var_dump() leads to dumping the whole
address space, because a chain of references leads to MediaWikiServices.
So, introduce a trait which replaces the problematic properties with a
placeholder, if their doc comment contains @noVarDump.
Bug: T277618
Change-Id: Ifa685c26fbc5317d0359544289ec3f433ec4fedf
This obscure class could only be used by customizing $wgLockManagers
and was not worth the overhead of maintaining it.
Change-Id: Ia8f802b2c68f0f6b4278d16c67464c3b814c87f6
* DeprecatedHooksTest: Don't use assertContains().
* Replace uses of deprecated asserts:
- assertFileNotExists() -> assertFileDoesNotExist()
* Update hierarchy of MediaWikiPHPUnitResultPrinter, since ResultPrinter
is an interface in PHPUnit 9.
* Remove temporary forward-compat methods.
* Remove directories that don't exist from tests/phpunit/suite.xml, since
they now make PHPUnit exit:
- tests/phpunit/skins, it used to have SideBarTest, then moved to
tests/phpunit/includes/skins
- tests/phpunit/documentation, it used to have ReleaseNotesTest, then
moved to tests/phpunit/unit/documentation
* Update configuration with --migrate-configuration and reformat.
* Avoid redefining getMockBuilder() in
ActionModuleBasedHandlerTestTrait, use a @method annotation instead.
* In RCCacheEntryFactoryTest, avoid using internal PHPUnit logic for
HTML validation, and use native PHP methods instead. The code was
copied from Xml::load (moved to \Xml\Loader::load in PHPUnit 9) and
simplified for this use case.
Bug: T243600
Bug: T262076
Change-Id: I851b9158b73d0cfc315eed9d63b15c54b05895e3
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
Deprecated in 296b485
Fix comment about this function and wrong mention of pre-send,
but it is post-send, documented in c49a45f
Change-Id: I29448377ca785843d7cd16f8c458d31b77b8bbe6
Last usage was in FlaggedRevs, removed in Ie3d8ab35c978458ee.
Deprecated in core since 1.39 with Ic2971c31f29babb48fb.
Change-Id: Ieaccaab3e8805ecb387480990f945bca6f989c2d
Developers using ApiSandbox often don't realize they should be using
the "modern" formatversion=2 because our UX defaults to
formatversion=1. We can't change the default in the action API due to
b/c, but we can hack things so that when you use ApiSandbox we
initialize the query to set formatversion=latest. Hopefully this will
encourage adoption of the most modern formatversion and avoid client
bugs caused by the "falsey but present" values returned by
formatversion=1.
Change-Id: Ia7c8582a2589f971f1fb22fdc5afb3ee9bde1d50
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
- Add new menu components: Menu, Link, ListItem, Footer
- Add footer component which leverages menu components for
generating template data.
- Add footer to the component registry to be used in Skin class.
- Update Skin methods to leverage new Menu and related components.
- Move footer data generation methods from Skin and SkinTemplate
into SkinComponentFooter class methods.
- Remove Skin::getFooterLinks, Skin::getSiteFooterLinks
- Deprecate Skin::footerLink.
- Update RELEASE-NOTES with breaking changes, deprecations.
- No visual regressions for the footer or menus.
- SkinComponentRegistryContext::getLanguage now returns language
object (interface is marked as @unstable so changes here acceptable)
Bug: T302116
Depends-On: I97512d06df6f86236379a16fb0fbd6aa3f61deb5
Change-Id: I06054c2dead4773789b8c3d88a6b1ed8f78cd614
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
Varnish is unable to cache these currently. However since pages with an
invalid title will never have any variable/editable content, we can
cache them unconditionally.
Also, undeprecate OutputPage::enableClientCache for this since it
is clearly useful here, but the parameter is being removed since
OutputPage::disableClientCache should be used to disable client side
caching instead.
Bug: T316932
Change-Id: Ib98fd165bffd9ca3dcbbcb8c6f06964dba7c90b7
