I believe this makes the code less brittle, and also makes it a bit
more obvious what these strings are meant to represent.
Change-Id: Ia39b5c80af4b495931d0a68fd091b783645dd709
This was done automatically using the
`Universal.WhiteSpace.CommaSpacing` sniff, which will be included in the
next release of the MW PHPCS config.
Some of these have been adjusted manually where the autofix broke
vertical alignment.
Change-Id: I54a4668d8a2759b9d7de47742c943a535a04e211
We renamed many classes to be namespaced, but the `@covers` and
`@coversDefaultClass` annotations weren't updated properly.
PHPUnit didn't support short cover annotations with `use` statements,
these didn't trigger any errors yet, because they are class alias.
This patch is populated by a modified version of PhpunitAnnotationsSniff.
Change-Id: I6c602290a30099239b17d2dc0d67b1488b4eaeeb
There is no way to express that Title::castFromPageIdentity(),
Title::castFromPageReference() and Title::castFromLinkTarget()
can only return null when the parameter is null. We need to add
Phan suppressions or explicit types almost everywhere that these
methods are used with parameters that are known to not be null.
Instead, introduce new methods Title::newFromPageIdentity() and
Title::newFromPageReference() (Title::newFromLinkTarget() already
exists), without the null-coalescing behavior, and use them when
the parameter is not null. This lets static analysis tools, and
humans, easily understand where nulls can't appear.
Do the same with the corresponding TitleFactory methods.
Change the obvious uses of castFrom*() to newFrom*() (if there is
a Phan suppression, a type check, or a method call on the result).
Change-Id: Ida4da75953cf3bca372a40dc88022443109ca0cb
When a title is parsed with a default namespace of NS_USER a possible
interwiki at the begin would make the title external and ignores the
default namespace, but it would call IPUtils::sanitizeIP with empty
string, returning null
Bug: T329690
Change-Id: Id2a32c87d09d92ead20ad58547c22a513084ffa2
createMock() does the same, but is much easier to read.
A small difference is that some of the replacements made in this
patch didn't use disableOriginalConstructor() before. In case this
was relevant we should see the respective test fail. If not we can
save some CPU cycles and skip these constructors.
Change-Id: Ib98fb06e0fe753b7a53cb087a47e1159515a8ad5
This matches the behavior of PHP Title (added tests to confirm),
and supports a common case of obtaining the title text using the `URL`
API, when the 'title' parameter is using a legacy 8-bit encoding.
Change-Id: I04464c17369ffb0dd4e7c33d2bd4db7b2d050bf4
Seeing failed asserting false is true is just about useless for
debugging. Instead compare the prefixed DB keys which should be
identical to ->equals(), but since they're strings the PHPUnit error on
failure will be usable.
Change-Id: I3b14c1b23d43b693c76b306afc3e3555ed2b93aa
Replacing the mock InterwikiLookup used in
MediaWikiTitleCodecTest revealed that that test was,
because of the mock not behaving correctly, testing the
wrong thing - interwiki prefixes are *not* case sensitive,
and are always converted to lowercase in the actual
ClassicInterwikiLookup. Fixed those expectations.
Change-Id: I242431e88860b7700a9f93f77a0fe195fd748800
It is not entirely meaningless. It might be an indicator that
the number of calls to a method is intentionally unlimited.
This is similar to e.g. an @inheritDoc PHPDoc comment that
marks a method as being "intentionally undocumented".
However, what's the meaning of being "intentionally
unconstrained"? Let's just not have any constraint then.
I feel all these ->expects( $this->any() ) bloat the test
code so much that it's never worth it.
Change-Id: I9925e7706bd03e1666f6eb0b284cb42b0dd3be23
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
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
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
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
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
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
This ocassionally happens for whatever reason, but it doesn't really
make sense to throw an exception when creating a broken-looking link
would also work. We already do this for TitleParser::getPrefixedDBkey(),
and this also matches the behavior of Title::getNsText().
Bug: T136352
Bug: T136356
Change-Id: Ic7eb17f8917f7fbb28b11d94b742dac1fe5582a1
In TitleFormatter::getPrefixedDBkey(), match the
Title::getPrefixedDBkey() behavior for non-existent namespaces by using
an empty string for the namespace and including a leading colon.
Change-Id: I195c36df69963c7409711dd97bece078f61faf77
