AbortAutoAccount, AbortNewAccount, AbortLogin, LoginUserMigrated,
UserCreateForm, and UserLoginForm are all unused in Wikimedia
production and rare in other extensions.
This also scraps the FakeAuthTemplate and LoginForm classes and
the occasional remainig references thereto.
Bug: T193755
Change-Id: I24d6fa963f402d4311fa00fc11536a37ee3bd31e
This assures that MergeableUpdate tasks that lazy push job will actually
have those jobs run instead of being added after the lone callback update
to call JobQueueGroup::pushLazyJobs() already ran.
This also makes it more obvious that push will happen, since a mergeable
update is added each time lazyPush() is called and a job is buffered,
rather than rely on some magic callback enqueued into DeferredUpdates at
just the right point in multiple entry points.
Bug: T207809
Change-Id: I13382ef4a17a9ba0fd3f9964b8c62f564e47e42d
This should reduce excess contention and lock timeouts.
Previously, it used a pre-commit hook which ran just before the
end of the DB transaction round.
Also removed unused User::incEditCountImmediate() method.
Bug: T202715
Depends-on: I6d239a5ea286afb10d9e317b2ee1436de60f7e4f
Depends-on: I0ad3d17107efc7b0e59f1dd54d5733cd1572a2b7
Change-Id: I0d6d7ddd91bbb21995142808248d162e05696d47
Add the widget in both PHP and JS for OOUI, and into HTMLForm
definitions.
In JS, the widget uses the engine from mw.widgets.TitleWidget
with the async support from OO.ui.mixin.RequestManager.
The PHP version provides a textarea, like UsersMultiselectWidget.php
which is then infused if JS is available.
Also, add highlightSearchQuery option for TitleWidget to allow for
not highlighting the partial search query the user typed in, if the
UI requires it. This option (highlighting partial result) is already
optional in the TitleOptionWidget, so this config exposes that
optionality in the TitleWidget widget for its menu children.
Notes:
HTMLTitlesMultiselectField is a duplication of HTMLUsersMultiselectField
except for:
- The configuration variable changed to 'titles' (from 'users')
- OOUI modules were adjusted for the TitlesMultiselectWidget
- The PHP version instantiates a MediaWiki\Widget\TitlesMultiselectWidget
TitlesMultiselectWidget is a duplication of UsersMultiselectWidget
except for:
- $usersArray was renamed to $titlesArray
- getJavascriptClassName returns the correct js class for
mw.widgets.TitlesMultiselectWidget for infusion.
Bug: T197109
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: Ie96947a35f70b76731e16ae5b85de815dfa4a8ce
Special:RedirectExternal is an unlisted special page that accepts a URL as
the first argument, and redirects the user to that page.
Example: Special:RedirectExternal/https://mediawiki.org
At the moment, this is intended to be used by the GrowthExperiments project in
order to track outbound visits to certain external links. But it could be
extended in the future to provide parameters for showing a message to the user
before redirecting, or explicitly requiring a user to click on the link, which
could help improve security when users follow on-wiki links to off-wiki sites.
Bug: T207115
Change-Id: I822af14a84569aab22249e2f16a662a60e60f76a
With this change, MediaWiki will no longer have a 'JavaScript-powered'
wikitext toolbar, and instead sysadmins will be required to choose one
(or more) of the several extensions available for this purpose if they
need the functionality. For over half a decade MediaWiki's tarball has
included the 2010-era replacement for this feature, WikiEditor. We are
now working on replacing even that, with the 2013-era visual editor, a
mode of which is the forthcoming 2017-era wikitext editor, and several
more specialised editors like CodeEditor.
Beyond this, the core editor toolbar is ancient, un-loved, and is used
only exceptionally rarely, mostly by accident. It is unhelpful to give
implicitly this as the primary editor for MediaWiki just because we've
not removed it from core when it is not a very good experience for any
kind of user, and has not received the attention that users deserve to
be worth retaining in core.
The old core preference, which was intended to govern whether this old
toolbar should be shown, has since mutated into whether the to run the
EditPageBeforeEditToolbar hook. The hook is used by several extensions
to provide toolbars in lieu of the core one. This preference has been,
in practice, a very confusing preference for MediaWiki users, who have
to interact with quite similar preferences to toggle their real editor
which sit next to this one on the preferences page. Consequently, this
preference is also removed.
The code could be made into an extension for those (very few) users of
MediaWiki who might want to keep on using it. However, the author will
offer their services but not their encouragement in said undertaking.
Bug: T30856
Bug: T32795
Change-Id: I2b05f0ca25873ad8e0b33a5e4938bef52c4e9347
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
Pages with many revisions experience transaction size exceptions,
due to archiving revisions. Use the job queue to split the work
into batches and avoid exceptions.
Bug: T198176
Change-Id: Ie800fb5a46be837ac91b24b9402ee90b0355d6cd
image_comment_temp was always intended to be temporary, until an
expensive schema change on Wikimedia Commons's image table could be
done. Now that that has been done, stop writing image_comment_temp and
add a migration script to copy existing data into img_description_id.
Ic8efeddc will remove the reads from image_comment_temp and drop the
image_comment_temp table.
Bug: T188132
Change-Id: Iab5f521577a415b2dc213b517ee8a0dca4fdd0aa
This adds getSecondaryDataUpdates and getDeletionUpdates
to ContentHandler, and updates WikiPage and DerivedPageDataUpdates
to handle DataUpdates from all slots.
Bug: T194038
Bug: T194037
Change-Id: I75c96318f58a5cdda48484f7040ae41e6f42392a
RevisionRenderer is the MCR replacement for Content::getParserOutput,
as outlined in <https://www.mediawiki.org/wiki/User:Daniel_Kinzler_(WMDE)/MCR-PageUpdater>.
Note: This change also introduces quite a bit of code for
merging ParserOutput objects.
Bug: T194048
Change-Id: I871978bf79f67c9e7954fb3fc8528d6e365f2cc1
Since SDC doesn't actually require the edit form to handle multi-slot
editing, updating EditPage with its normal undo handling is being put
off for later. But in the mean time we still want some sort of "undo" to
work, hence this mcrundo that doesn't allow for editing.
Bug: T200216
Change-Id: I1f11d8ed141cb11576d2df883856d03e8f64bd38
Depends-On: Iedd9bf6c057e8b396a575bab700b15bd38b32cc9
This is to make sure that the design is similar, but also so
that the widget can be read in JS where needed and that we
can toggle the disabled state on/off through the whole widget,
that is made from a series of checkbox widgets.
Bug: T199946
Change-Id: I9943b0aa1746fdfb60c7d4c88d6d4d7ac0589a2c
Something for the short-term, perhaps. But at least an improvement
over 'update-oojs.sh' and 'update-ooui.sh'.
* Does not require any dependencies (no 'node' or 'npm').
* Performs integrity validation.
Change-Id: I0f79b84ef3903756353c66d3c3ee7e492c60e648
Move logic for rendering a diff between two content objects out of
DifferenceEngine, into a new SlotDiffRenderer class. Make
DifferenceEngine use multiple SlotDiffRenderers, one per slot.
This separates the class tree for changing high-level diff properties
such as the header or the revision selection method (same as before:
subclass DifferenceEngine and override ContentHandler::getDiffEngineClass
or implement GetDifferenceEngine) and the one for changing the actual
diff rendering for a given content type (subclass SlotDiffRenderer and
override ContentHandler::getSlotDiffRenderer or implement
GetSlotDiffRenderer). To keep B/C, when SlotDiffRenderer is not overridden
for a given content type but DifferenceEngine is, that DifferenceEngine
will be used instead.
The weak point of the scheme is overriding the DifferenceEngine methods
passing control to the SlotDiffRenderers (the ones calling
getDifferenceEngines), without calling the parent. These are:
showDiffStyle, getDiffBody, getDiffBodyCacheKeyParams. Extensions doing
that will probably break in unpredictable ways (most likely, only
showing the main slot diff). Nothing in gerrit does it, at least.
A new GetSlotDiffRenderer hook is added to modify rendering for content
models not owned by the extension, much like how GetDifferenceEngine
works.
Also deprecates public access to mNewRev/mOldRev and creates public
getters instead. DifferenceEngine never supported external changes to
those properties, this just acknowledges it.
Bug: T194731
Change-Id: I2f8a9dbebd2290b7feafb20e2bb2a2693e18ba11
Depends-On: I04e885a33bfce5bccc807b9bcfe1eaa577a9fd47
Depends-On: I203d8895bf436b7fee53fe4718dede8a3b1768bc
MediaWiki::emitBufferedStatsdData() is never called for the PerDbName factory,
so stats were being dropped. Instead of having two factories, turn the
PerDbName one into a proxy/wrapper around the main factory that just adds a
prefix in front of all of the keys.
Bug: T202144
Change-Id: I31e376446abb58e41353b4ca3814120d2e914104
And include tests :)
This code is independent of MediaWiki, but not really large enough to be
worth librarizing right now.
Bug: T200626
Change-Id: I022c074e8a708fb5219bc4ff4b53e7e31f60dc4b
Only bench with variable input ("indirect"). The static string is
too unrealistic and not worth testing for imho, if it even makes
a difference at all.
Also bump the default count from 100 to 10,000 given it's so tiny.
Change-Id: Iccc35af4bd3c5b0967983ddfacd1d4ead235e4a4
Calling SpecialPageFactory methods statically is now soft-deprecated.
SpecialPageFactory::resetList() is a no-op, and I changed tests
in core to use overrideMwServices() instead.
Methods that fell back to $wgUser now require a User object being passed.
Depends-On: Ie1f80315871085b9fd4763a265b588849d94414d
Change-Id: Id8a92d57743f790b7d8c377c033cef38d1bb24de
