aboutsummaryrefslogtreecommitdiffstats
path: root/includes/title/ForeignTitle.php
Commit message (Collapse)AuthorAgeFilesLines
* Coding style: Auto-fix MediaWiki.Usage.IsNull.IsNullJames D. Forrester2020-01-101-3/+3
| | | | Change-Id: I90cfe8366c0245c9c67e598d17800684897a4e27
* Make ForeignTitle properties privateaddshore2016-01-261-3/+3
| | | | Change-Id: If9ea22f412a378aa1090ba761c19f77c97da7df0
* Proper namespace handling for WikiImporterThis, that and the other2014-12-101-0/+117
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