The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
Deprecating something means to say something nasty about it, or to draw
its character into question. For example, "this function is lazy and good
for nothing". Deprecatory remarks by a developer are generally taken as a
warning that violence will soon be done against the function in question.
Other developers are thus warned to avoid associating with the deprecated
function.
However, since wfDeprecated() was introduced, it has become obvious that
the targets of deprecation are not limited to functions. Developers can
deprecate literally anything: a parameter, a return value, a file
format, Mondays, the concept of being, etc. wfDeprecated() requires
every deprecatory statement to begin with "use of", leading to some
awkward sentences. For example, one might say: "Use of your mouth to
cough without it being covered by your arm is deprecated since 2020."
So, introduce wfDeprecatedMsg(), which allows deprecation messages to be
specified in plain text, with the caller description being optionally
appended. Migrate incorrect or gramatically awkward uses of wfDeprecated()
to wfDeprecatedMsg().
Change-Id: Ib3dd2fe37677d98425d0f3692db5c9e988943ae8
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
This updates some code that has been constructing TitleValue directly
to use TitleValue::tryNew or TitleParser::makeTitleValueSafe.
Bug: T200055
Change-Id: If781fe62213413c8fb847fd9e90f079e2f9ffc9d
This patch fixes the documentation of newFromText and makeTitleSafe to
no longer state incorrectly that any Title they return is guaranteed to
be valid. That has never been true.
It also makes canExist() checks a lot stricter, to match the assumptions
of current callers, namely that the title can exist as a wiki page.
Finally, it replaces several existing calls to isValid() with calls to
canExist().
Bug: T229705
Change-Id: I2a483136ec6acca49afb5eb32cb94616672b8fb2
Classes that use ServiceOptions need to declare a list of keys that they
use, typically in self::$constructorOptions. If keys are missing from
that list that are supposed to be present, an exception will be thrown
when someone tries to access them. If keys are present on the list that
are never used, no error is flagged. This means if a dependency on a
given configuration option is removed and nobody updates the list, the
service will keep thinking it depends on that option when it doesn't.
This is messy at best, like an unused variable.
A new and easy-to-use TestAllServiceOptionsUsed trait fixes that
problem. It will log all the ServiceOptions accesses while the test
class runs and raise an error if there are any keys that were never
accessed.
In retrospect, it was probably not worth the time to write this, but
it's a sunk cost now.
Change-Id: Idcaf9a0e2f687069869e6f8057908ffee7dd5f11
This works exactly the same as Title::makeTitleSafe(), but for
TitleValues. 100% test coverage of splitTitleString(). Also added
identical parallel tests for Title::makeTitleSafe() to verify that
behavior is the same.
Along the way, I discovered that TitleValue doesn't allow an empty page
name even if there's an interwiki prefix, which is wrong, so I fixed it.
Bug: T220966
Change-Id: I4b915244ceee4c1857178dd68dcdf57f1ee32200
This causes Title::getTalkPage and NamespaceInfo::getTitle() to throw
an MWException when called on a LinkTarget that is an interwiki link
or a relative section link. These methods were already throwing
MWException when called on a link to a Special page.
Bug: T224814
Change-Id: I525c186a5b8b8fc22bca195da48afead3bfbd402
This changeset resumes work on T89432 and related tickets
by porting an initial set of tests to the new unit test suite
separated out in I69b92db3e70093570e05cc0a64c7780a278b321a.
The tests were only ported if they worked immediately without
requiring any changes other than changing the test case class
to MediaWikiUnitTestCase and moving the test to the new suite.
If a test failed for any reason (even trivial misconfiguration),
it was NOT ported.
With this change, the unit tests suite now consits of a total
of 455 tests. As before, you can run these tests via the following
command:
$ composer phpunit:unit
Bug: T84948
Bug: T89432
Bug: T87781
Change-Id: Ibb8175981092d7f41864e641cc3c118af70a5c76
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
Aka: Streamline Linker::formatAutocomments() and add tests
This uses the "streamlining" for the code proposed by Thiemo
in I38edc1ad7720. I have squashed the two commits, so it now
has his code in Linker, but still has my tests as well as his.
Thiemo wrote on his patch:
This also changes the output in case there is no fragment to link to.
Before an empty `/* */` in a summary this would have created a link to
the page. I would like to argue this is not what a user expects.
Bug: T222628
Change-Id: I05408ede0e20dfd976f4057fc5baab461d2ef769
When $wgNamespaceProtection specifies multiple rights for a
namespace, the code was assuming all of those rights had to
come from one group. But MediaWiki allows for the rights to
come from multiple groups that each give a subset of the rights. Allow for that case.
Bug: T222598
Change-Id: I1e9aca6e521260f783bd881e7d095d62bc605dc6
In the new tests I added, I tried to cover all interesting scenarios and
not just hit each line to make the coverage green. But I didn't review
all the existing tests to see if they were properly thorough, so there
might still be room for improvement.
I uncovered a bug here that will be addressed in a separate commit,
because the fix is not so simple. For now I left the test expectation as
a @todo.
Change-Id: I33d556bf83c631a8a02a6c77f2f5cb06b8dbf869
This method was deprecated in .30 hence remove as the usage is actually
zero in extensions and one only in core.
Usage:
https://codesearch.wmflabs.org/search/?q=%3A%3AcanTalk%5C(&i=nope&files=&repos=
Change-Id: Ia18c63f95c969d13c28ffb1afa376ec2df2002a3
This matches behavior of Title, and is meaningful for creating links.
However, in other contexts such a TitleValue doesn't make sense, so
perhaps we want to write special cases in linking code instead.
Change-Id: I812ad9090463766f38ef677de318c006912b4cca
MWNamespace::clearCaches() has been removed entirely, along with the
$rebuild parameter to MWNamespace::getCanonicalNamespaces(). The rest of
MWNamespace is deprecated.
Diff best viewed with -C1 so git notices that NamespaceInfo is a copy of
MWNamespace.
Depends-On: Icb7a4a2a5d19fb1f2453b4b57a5271196b0e316d
Depends-On: Ib3c914fc99394e4876ac9fe27317a1eafa2ff69e
Change-Id: I1a03d4e146f5414ae73c7d1a5807c873323e8abc
fbc1449653 (Make Titles with an unknown namespace ID refer to
Special:Badtitle.) was never implemented in TitleFormatter, so let's do
that.
While we're at it, formatTitle() is now structured in the same format as
Title::prefix(), to make it easier to compare code between the two
implementations. The existing tests verify that this is a no-op. There's
a little extra indirection in getPrefixedDBkey(), which now goes through
dbkeyform -> textform -> dbkeyform, but reduces duplication of code,
which I think is worth it.
Bug: T165149
Change-Id: I4e43487a52663d2a647f9e71d487f58e25474f7a
This changes behavior in some tests by making them set $wgLanguageCode
as well as $wgContLang, but that seems like a good thing.
Bug: T200246
Change-Id: I936888f46ff9fefe2707efba837e2ce3a7ca5e3f
Unicode 6.3.0 (September 2013) the added additional directional
formatting characters:
U+061C ARABIC LETTER MARK
U+2066 LEFT-TO-RIGHT ISOLATE
U+2067 RIGHT-TO-LEFT ISOLATE
U+2068 FIRST STRONG ISOLATE
U+2069 POP DIRECTIONAL ISOLATE
https://www.fileformat.info/info/unicode/version/6.3/index.htm
This change strips the new directional formatting characters from the
title like the directional formatting characters from Unicode 1.1.0
(June 1993).
Any existing titles containing the new Unicode directional formatting
characters get stripped by a run of maintenance/cleanupTitles.php after
deployment.
This change also allows to insert the new Unicode directional
formatting characters into the DISPLAYTITLE.
Change-Id: I2279f51048f5252c2e4280ec6a13f060ff9967cb
This change strips all soft hyphens from the title. This is already
done for Unicode bidi characters (T5696).
URLs with soft hyphens (%C2%AD) get redirected (301) to the URL without
soft hyphens (T145605):
https://de.wikipedia.org/wiki/Bosnatal%C2%ADbahn get redirected to
https://de.wikipedia.org/wiki/Bosnatalbahn
Links in wikitext containing soft hyphen "[[Bosnatal<AD>bahn]]" (the
"<AD>" stands here for a soft hyphen) links "Bosnatalbahn" but displays
"Bosnatal<AD>bahn".
This change also allows to insert soft hyphens into the displaytitle
(T66528). This allows to insert soft hyphens into the first heading for
manual hyphenation of titles with very long words.
This change prevents access to any existing articles containing soft
hyphens in the title. After deploying this change a run of
maintenance/cleanupTitles.php must performed to rename existing titles
with soft hyphens. Before deploying this change existing articles and
redirects with soft hyphens in the title can already renamed or
deleted.
Bug: T121979
Bug: T66528
Change-Id: Ie13626c433cdb460dbf00b3bba28d1bb5a7b6d6a
