* Right now, one or two are permitted. This patch limits it to one.
The current behaviour seems more a byproduct of refactoring than an
explicit goal.
* Note that this will break links on a handful of pages surfaced in
Parsoid's roundtrip testing.
Change-Id: Icabd34bbf15781bb891bd8e0c079d1a65eb28595
A null $errorMessage constructor argument has not been supported since
I43d988602b, since wfMessage (via the Message constructor) throws an
exception if the message key is null. It follows that getErrorMessage()
can never return null.
Bug: T99818
Change-Id: I2cbf4909e7237b0a91d100cc5478fb4cfee1d748
This patch allows for a custom InterwikiLookup service
when constructing MediaWikiTitleCodec instances.
If not specified, it continues to get the service from
MediaWikiServices::getInstance()->getInterwikiLookup().
This patch will allow a fully customized instance
creation, without any global state.
Change-Id: Ica87aff5df4534aae0a32e307b27d88b3df023b4
If an XML dump of a wiki is exported using dumpBackup.php, and there are
pages in a namespace that is not registered (perhaps because of a missing
extension), they will appear in the dump in the form
<page> ... <title>PageTitle</title> <ns>1234</ns> ... </page>
This caused the ForeignTitle code to raise an undefined offset error,
because it assumed that the <title> element was of the form
"Namespace:PageTitle" when <ns> was nonzero. This assumption is not valid.
Now, the importation of such dumps will no longer throw errors and the
pages will be correctly imported, although possibly to unexpected
locations.
Bug: T114115
Change-Id: I0271435dc208e7ea118339584f8a0e359c96113a
The current output "Bad value for parameter $dbkey: invalid DB key" is
useless for actually working out which DB key is to blame.
Bug: T146778
Change-Id: Iaf57e25ab27b5065469c5dc5de0a1b881c48210c
We already throw around some exceptions that are localized
(ErrorPageError and its subclasses, MalformedTitleException), but
there's no standard way to recognize them. Let's change that.
Then let's use them in the API to be able to have internationalized
errors when such exceptions are caught, instead of wrapping the
English-language version.
Change-Id: Iac7c90f92a889f8de9dae373547c07b884addaea
The MediaWikiPageLinkRenderer interface was introduced with TitleValue
in 1.23, but was barely used outside of two special pages in MediaWiki
core. It has now been superceded by MediaWiki\Linker\LinkRenderer and
should be removed in favor of that.
Change-Id: Ib56d5731d4803aa417942aced7f3dedf2104bbde
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
This adds support to the LinkTarget interface and TitleValue
implementation for having an interwiki component, matching the function
names used in Title.
MediaWikiTitleCodec was updated accordingly.
The motivation behind this change is to be able to fully use LinkTarget
in the Linker rewrite instead of depending upon Title.
Change-Id: I6666b64f0e336aadc7261e7ca87ac2e498c61856
The createFragmentTarget function allows for switching the fragment on a
target in an easier way. TitleValue already had a now-renamed
createFragmentTitle function (no uses outside of tests), and an
implementation was added for Title.
This will also help with reducing the amount of public usage of
Title::setFragment(), which is deprecated.
Change-Id: I1e8ba2f85e748b1b4394fb2f2a1ccce69cf6e3c5
LinkTarget::hasFragment() is a helper function which returns a boolean
of whether the target has a fragment. Title already had such a function,
and one was added to TitleValue.
Co-Authored-By: addshore <addshorewiki@gmail.com>
Change-Id: I49e607ae5a58c3aef96d0246297740e7d88ac816
Every single caller of Title::newFromLinkTarget() already special cases
when the LinkTarget object is already a Title, so move that logic into
one function.
Change-Id: Iba5432ae01c87850e5b34893092427c5b1629188
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
