To be used by things that do not care if they are
passed a Title or TitleValue so long as it has a
dbkey, namespace, possible fragment and text
Example uses include:
LinkBatch::addObj
MediaWikiPageLinkRenderer methods
MediaWikiTitleCodec methods
PageLinkRenderer methods
TitleFormatter methods
Change-Id: I2aa1a82129bb01155924a8e6a403c7a47391432f
This introduces https://github.com/wmde/Assert as a dependency,
as discussed in the RFC T91071.
This change uses assertions to check some parameters in some places,
to showcase the main intended use case for assertions in MediaWiki.
Bug: T91071
Change-Id: I93ac39b7c146f10532e37b51d973b59b9c424b2f
There's no reason for $ex->getMessage() to return nothing. Do like
ErrorPageError does and get the default English message for the parent.
Also move the appending of $titleText to $errorMessageParameters into
MalformedTitleException itself and document it, so every catcher of the
exception doesn't need to know about this, and fix the check so it
doesn't screw up for title "0".
Change-Id: I43d988602b847b67a3cf0aa84e271a0b5bd9adae
includes/Title.php
* The private method Title::secureAndSplit() now throws a
MalformedTitleException instead of returning false on invalid
titles.
* Added Title::newFromTextThrow(), which behaves exactly like
Title::newFromText() but throws MalformedTitleException instead of
returning null on invalid titles.
includes/title/MediaWikiTitleCodec.php
* Provide more information with the thrown MalformedTitleExceptions.
includes/MediaWiki.php
* Use the new Title::newFromTextThrow() to get detailed error
information, display it.
Change-Id: I4da8ecb457a77473e32d745ba48ab8505b35e45f
This drops support for the custom utf8 normal PHP extension in favor
of the intl extension.
Bug: T90825
Change-Id: Ifbaeb2ef684217cf6187ccc4fb4d303f89608300
Deprecated it in Title, and updated all current references to use the
non-deprecated version in MediaWikiTitleCodec
Change-Id: I2b9c36992028c97f695f2b95ba027fbb11904b57
Up until now, the import backend has tried to resolve titles in the XML
data using the regular Title class. This is a disastrous idea, as local
namespace names often do not match foreign namespace titles.
There is enough metadata present in XML dumps generated by modern MW
versions for the target namespace ID and name to be reliably determined.
This metadata is contained in the <siteinfo> and <ns> tags, which
(unbelievably enough) was totally ignored by WikiImporter until now.
Fallbacks are provided for older XML dump versions which may be missing
some or all of this metadata.
The ForeignTitle class is introduced. This is intended specifically for
the resolution of titles on foreign wikis. In the future, an
InterwikiTitle class could be added, which would inherit ForeignTitle
and add members for the interwiki prefix and fragment.
Factory classes to generate ForeignTitle objects from string data, and
Title objects from ForeignTitle objects, are also added.
The 'AfterImportPage' hook has been modified so the second argument is a
ForeignTitle object instead of a Title (the documentation was wrong,
it was never a string). LiquidThreads, SMW and FacetedSearch all use this
hook but none of them use the $origTitle parameter.
Bug: T32723
Bug: T42192
Change-Id: Iaa58e1b9fd7287cdf999cef6a6f3bb63cd2a4778
This solution is somewhat imperfect, as the logic being added here to
MediaWikiTitleCodec really belongs in the parser. However, given the
current state of this code, this is the cleanest possible solution at
the moment.
Modified the existing release note for this.
Bug: 68802
Change-Id: I38309186bdcad23f49e23beb26daaf3ef5bceea1
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: Ie419638e909a47aa72a274043604247830ee1a81
For example, [[en:]] on enwiki. These links were for some reason considered
invalid. However, to support use-cases such as cross-wiki transclusion and
the importing of templates across wikis, this type of link should be
allowed.
I can't see that this would break anything. If anything, it will "un-break"
some links.
Should MediaWikiTitleCodec depend on Title::newMainPage? Almost certainly
not, but I note that splitTitleString is earmarked for demolition, so I
expect that the confusing dependency-web will be cleaned up in the future.
I also note that MediaWikiTitleCode already uses various static methods of
the Title class.
Bug: 64167
Change-Id: I27495aa62e6059c7725387135ae0358d7e6fb35b
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: Iced714bca004756b461b66067a49a925a7e3b877
This code was added by Brion back in 2004 as part of r6398.
According to Brion, links like [[en:wikt:foo]] on English Wikipedia are
"just crazy!", but I can't see any reason to disallow them.
Bug: 61357
Change-Id: If449e60a0ef95cfe3dd6f4b1809ac012be62a0ea
TitleValue is intended to be a light weight alternative to the Title
class. Any operations on TitleValue are implemented in separate
service classes, like TitleFormatter and PageLinkRenderer. See
<https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue>
for more information.
This change updates SpecialCategories and SpecialLinkSearch to use
TitleValue instead of Title, to demonstrate how TitleValue would be
used, and how the necessary services can be injected and applied.
The intention is to improve testability and reusability; these
advantages will however only become apparent with further refactoring
of the respective special pages. This will be done in follow-up
changes.
More work will be needed to migrate essential functionality from
Title and Linker classes into the respective service classes,
MediaWikiTitleCodec and MediaWikiPageLinkRenderer.
Change-Id: I8eef5a165de4ffcacfbc4911fdacdb15d502fff4
