Importing revisions in MediaWiki has long been weird: if the username on
the imported revision exists locally it's automatically attributed to
the local user, while if the name does not exist locally we wind up with
revision table rows with rev_user = 0 and rev_user_text being a valid
name that someone might later create. "Global" blocks too create rows
with ipb_by = 0 an ipb_by_text being a valid name.
The upcoming actor table change, as things currently stand, would
regularize that a bit by automatically attributing those imported
revisions to the newly-created user. But that's not necessarily what we
actually want to happen. And it would certainly confuse CentralAuth's
attempt to detect its own global blocks.
Thus, this patch introduces "interwiki" usernames that aren't valid for
local use, of the format "iw>Example".[1] Linker will interpret these
names and generate an appropriate interwiki link in history pages and
the like, as if from wikitext like `[[iw:User:Example]]`.
Imports for non-existant local users (and optionally for existing local
users too) will credit the edit to such an interwiki name. There is also
a new hook, 'ImportHandleUnknownUser', to allow extension such as
CentralAuth to create local users as their edits are imported.
Block will no longer accept usable-but-nonexistent names for 'byText' or
->setBlocker(). CentralAuth's global blocks will be submitted with an
interwiki username (see Ieae5d24f9).
Wikis that have imported edits or CentralAuth global blocks should run
the new maintenance/cleanupUsersWithNoId.php maintenance script. This
isn't done by update.php because (1) it needs an interwiki prefix to use
and (2) the updater can't know whether to pass the `--assign` flag.
[1]: '>' was used instead of the more usual ':' because WMF wikis have
many existing usernames containing colons.
Bug: T9240
Bug: T20209
Bug: T111605
Change-Id: I5401941c06102e8faa813910519d55482dff36cb
Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
If session data is lost between the transactions (read: the csrf token
does not match), the error message contains some wiki markup as well as
HTML. However, unfortunately, SpecialImport uses $out->wrapWikiMsg() in
combination with an error message (with wiki markup and HTML) wrapped as
a parameter of another message. This results in an escaped paramater and
it is not parsed correctly, which leads in wiki markup send to the user.
This change fixes that issue by parsing the message directly.
Bug: T172114
Change-Id: If49a600173c44d098f25d6e2a9b87b7b7bf3ee2a
Having such comments is worse than not having them. They add zero
information. But you must read the text to understand there is
nothing you don't already know from the class and the method name.
This is similar to I994d11e. Even more trivial, because this here is
about comments that don't say anything but "constructor".
Change-Id: I474dcdb5997bea3aafd11c0760ee072dfaff124c
Adds support for tagging log entries for the block, import,
managetags, and move API modules, using a 'tags' parameter.
Bug: T97720
Change-Id: I9d75d2cece317a7704c4bc6d734ad3cafe24544e
ImportLogInterwikiLink. Hook to change the interwiki link used in log entries and edit summaries for transwiki imports.
Change-Id: I03e054de16d8820c0f3d2c165288e229960d6bb1
The detail information about the count of revision and the interwiki
title get moved into log params. To show the new information an
ImportLogFormatter was written, which changes the key for new log items.
This allows to show the detail information in the user language.
It also decouple the user supplied data from detail information
Change-Id: Iaa57da0fc3e20c33c94fd850cd02db96fdb32dac
Currently import sources have to be set into $wgImportSources as part of
wiki startup. This is not practical for the WMF cluster, where we need some
reasonably complex logic to set up the import source structure.
This change allows the import source list to be populated from a new
"ImportSources" hook. This hook is only called when the list of import
sources is actually needed (namely, when a user with relevant permissions
loads Special:Import).
Bug: T17583
Change-Id: Ice9a19cb6dfe53ae72aa71353d0553ee9338f233
* Potentially long running POST requests often use multiple transactions,
talk to multiple services, or defer updates. Try to make sure they have
a chance to complete all of the work. WMF already sets ignore_user_abort()
across the board in config, but this applies it to key spots for all
installs, in addition to bumping the time limit.
* Eventually this can lower the need for high overall time limits.
Bug: T102890
Change-Id: I893ddd773064dcd63b5b24c84c6391974f4b5aee
* Links can now be customised on-wiki via system message:
e928d5bdd0
* Most help pages chosen here are good for any MediaWiki install
and have been imported on MediaWiki.org. Their license has been
noted in the appropriate template, only future contributions
will be in public domain (CC-0) unless we reach old authors.
An update/discussion was opened at the project talk:
https://www.mediawiki.org/wiki/Project_talk:PD_help
* The 6 pages on MediaWiki.org have been marked for translation;
import of previous translations is ongoing. 2 pages are left on Meta
because importing translatable pages with all translation units may
be overkill.
Bug: T45591
Change-Id: I5dd91a0b7233556f2da06b65205fee72ea65a55f
Previously there were two fields: Destination namespace, and Destination
root page. They were both optional, and the "root page" one in particular
was a bit mysterious until you tried it out. In addition, there was a
strange interaction when you set both fields (I still don't quite
understand what used to happen in this case).
Now, there is a set of three clearly described radio buttons, allowing the
user to select whether to import pages into their automatically chosen
locations, into a single namespace, or as subpages of a given page. These
correspond to the three ImportTitleFactory classes available in MediaWiki.
See https://phabricator.wikimedia.org/M28 for a screenshot.
The logic of WikiImporter#setTargetNamespace is tweaked slightly to remove
the interaction between target namespace and target root page, since only
one of these options can now be set. Similarly, the API's import module
is modified in the same way.
Bug: T17908
Change-Id: I11521260a88a7f4a95fbdb71ac50bcf7b4fe5cd1
There is no need for an extra formatter class, because at the moment
there is nothing extra to format.
This allows use of gender on Special:Log. Old messages are kept for use
in IRC. A test was added to ensure an unchanged IRC message.
The new log message for import-interwiki is used from
I3ca8b21bce49b41cac7109efb8056ca4469b88d7 to avoid "transwiki jargon".
Bug: T57404
Change-Id: I590075b203548c071a98c1eaa4b1bc9250f60e22
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
- Changed spaces to tabs for indentation
- space after 'function'/'if'
- Added/Removed space after parenthesis/brackets/end of line
- Removed space after cast
Change-Id: I0e8e6a19b84b5e1308b632a0266cb78f688494ee
- Added space after reserved words: function, foreach, if
- Combined 'else if' into elseif
- Added braces to one-line statements
- Added spaces after comma, before parentheses
Change-Id: Ie5bbf680d6fbe0f0872dab2700c16b1394906a72
There has been some demand, particularly in the Wikimedia cluster, for the
ability to import from any wiki of a cluster. For this to occur, the
transwiki import user interface needs a bit of a rethink.
This patch replaces the existing single dropdown with a pair of dropdowns:
the first to select the wiki project, and the second to select the
subproject (e.g. a Wikipedia/Wiktionary language, or a Wikia site).
The second one is optional (to support single-wiki sites like Meta, or
for backwards compatibility with existing setups).
$wgImportSources is now treated as a mixed array/associated array (see
comment in DefaultSettings.php). Existing configurations will still work
but will receive no new functionality.
The non-JavaScript fallback is not pretty, but (a) it works, (b) I don't
see an easy way to make it nicer, and (c) wiki sysops should probably be
using a JavaScript-enabled browser for admin actions like importing...
The intention is to alter the WMF configuration to automatically populate
$wgImportSources with all public cluster wikis. I'm not exactly sure how
this will be set up, but this patch is an important first step. I expect
some non-WMF users of MediaWiki will find it helpful as well.
Change-Id: Icdb655500c1ae5374dc7a9f4d99e6738b2269b14
This avoids the use of $wgUser in Revision constructor and makes the
dependency on the global visible.
Change-Id: Ib67bd706a3c4ef081f475406e9aa1094c42222ef
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: Icf6f36bb53322b39cd5c89523dbd0e4ab10b9ec9
Callers should use SpecialPage::getPageTitle, which is
exactly identical.
This is so that in the future we can turn SpecialPage
into a ContextSource, which requires getTitle to return
getContext()->getTitle.
Change-Id: Icdcf5d5295ef5e7f08b1d403e0c123f78738fd40
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
Having all group mapping for Special:SpecialPages in the global
$wgSpecialPageGroups is not a good OO style.
Created a method SpecialPage::getGroupName, which than can be overridden
by each subclasses to the featured group name.
Added also SpecialPage::getFinalGroupName to get the groupname on
Special:SpecialPages to handle the customization and
to keep $wgSpecialPageGroups for b/c
Change-Id: I1de3a186f0a59ec5ecb8996c5f805cf164e9637f
Fixed errors are:
* Duplicate ID mw-import-table
* Duplicate ID mw-interwiki-rootpage
* The for attribute of the label element must refer to a form control
(2x)
Added also a id for another input element for easy user scripting
Change-Id: I9c7aa3b2af2d49cf3aed42a057ab13aa1275ee90
