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
Adding a "root page" input to Special:Import, which is used as prefix
before each imported page. With this option, it is possible to import
pages as subpage of a user or a project page.
On de.wp the import is often done into a low used namespace (100 or 101)
and than moved to the user space. Doing this in one step, makes things
easier.
Change-Id: Id5dbf742295a1bbddd8cb6eaa09fb28051f26613
