* 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
Method similar to SpecialPage::outputHeader() to avoid registering
tons of system messages and to have -summary and -helppage tidily
listed together in Special:AllMessages by default.
Bug: T45591
Change-Id: Ic849dde00be7379c1909a8486cf20f48c5aea5cf
All the chosen targets are translatable public domain help pages
on MediaWiki.org. Mostly special pages and actions for privileged
users for now.
Adapted from the Translate extension, credit to Niklas Laxström
(TranslateUtils::addSpecialHelpLink).
Depends on 6f5b29ff4e, whose commit
message has a typo addIndicator() instead of setIndicator().
Bug: T45591
Change-Id: I2934b1708a0d207dcf3d940264f140613646f203
This provides better mobile experiences on various pages
and a more consistent UI across both mobile and desktop.
It does this in two ways.
1) Forces HTMLForms to not use table based layouts so as
not to interfere with responsive nature of mediawiki ui elements
2) Applies MediaWiki.UI classes to most pages
If a page is created via Xml or Html classes it will use mediawiki ui
Where possible I've added classes unconditionally, but for cases of buttons
this is behind the $wgUseMediaWikiUIEverywhere global since button styling is
enabled on pages by default and for checkboxes since it is changes HTML markup.
3) Adds all MediaWiki.UI styles to pages which can use it
When enabled:
* Apply these styles to all pages which use HTMLForms
* Apply to EditPage
* Apply to anything that uses certain elements outputted by the
Xml or HTML helper classes
* Apply to History page
* Apply to protection page
* Apply to move page
* Apply to deletion page
Currently kept behind a global to allow us time to finetune
existing elements. After further testing we will look to kill the
globals and make mediawiki.ui the default
See: I430c0fbb79d2a33bb828b2427bda0ee01115d73f
Change-Id: I47db5eab4569514d039261d11b6dedb0eeae17b5
- Separate file and class documentation
- Add some missing class documentation
- Fix erroneous documentation
Change-Id: I35c846ad63e837165b79456dc89d330498aebf64
- [Actions] -
* I am aware that eventually these classes should be more than just a few lines re-directing control to WikiPage, but I'm keeping these commits as uncontroversial as possible due to feature freeze. Refactor could be done later.
* Contributes to solution of bug 27930 - Ablity to get current action (The Right Way)
* Final goal: Get the current action without needing access to Wiki.php internals (i.e. with Action::factory in one hand and an instance of IContextSource in the other)
* Required for proper fix of r108342/108343 (currently marked FIXME)
* (bug 27655) Require token for watching/unwatching pages
* Previously done for API (bug 29070) in r88522
* As with markpatrolled, the tokens are not compatible and made that way on purpose. The API requires the POST method and uses a universal token per-session. Since the front-end is all GET based (also per convention like in markpatrolled and rollback) they are stronger salted (title / action specific)
* ajax.watch used the API already and was switched in r88554.
* The actual watching/unwatching code was moved from WatchAction->onView to WatchAction::doWatch. This was done to allow the API to do the action without needing to generate a token like the front-end needs (or having to duplicate code). It is now similar to RecentChange::markPatrolled (in that it also a "central" function that does not care about tokens, it's called after the token-handling)
* JavaScript / Gadgets that utilize action=watch in their scripts:
** Effects should be minimal as they should be using the API (see r88522 and wikitech-l)
** If they use index.php and scrap the link from the page, they can continue to do so.
* There are links to the watch action all over the place. I've tried to catch most of them, but there may be some I miss. Migration in most cases is just a matter of adding an array item to the $query for:
'token' => WatchAction::getWatchToken( $title, $user [, $action] )
or changing:
Action::factory( 'watch', $article )->execute();
to:
WatchAction::doWatch( $title, $user );
While replacing the usages in some cases an instance of Article() no longer had to be created, in others $wgUser had to be retrieved from global (which was implied before but needs to be given directly now)
Other notes:
* Article->unwatch() and Article->watch(), which were deprecated as of 1.18 and are no longer used in core, may be broken in scenarios where the Request does not have a 'token' but is making a call to $article->watch()
* Some extensions need to be fixed, I'm currently running a grep search and will fix them a.s.a.p
[1] http://www.mediawiki.org/wiki/ResourceLoader/Default_modules?mw.user#tokens
* (bug 26033, bug 24754) Added $wgArticleCountMethod to have a more flexible way to define which method to use to define if a page is an article or not and deprecated $wgUseCommaCount. There is now a new 'any' method to count any article that is in a content namespace and not a redirect.
* (bug 11868) If using links to count articles, Article::isCountable() will now use the ParserOutput to check if there's a link instead of checking for the "[[" string. Changed Article::isCountable() to take a stdObject or false for the first parameters. If false is passed, the result will be based on the current article's state (i.e. database). The only call outside of the Article class is in DeleteAction (including extensions).
* Removed this horror of Article::$mGoodAdjustment and Article::$mTotalAdjustment, replaced by the new $created parameter on Article::editUpdates(); simplified Article::createUpdates()
* Updated Import.php to take advantage of the new parameter and make a single call to Article::editUpdates()
* Actions come in two flavours: the show-a-form-then-do-something-with-the-result (delete, protect, edit, etc) and the just-do-something (watch, rollback, patrol, etc). Create abstract base classes Action and FormlessAction to support these two cases. HTMLForm is an integral part of the form-based structure.
* Look mum, no globals! :D Fully context-based.
* Implement watch/unwatch, credits and delete actions in the new system as proof-of-concept. This also gives the delete frontend a much-needed overhaul.
* Stub out the newly-deprecated functions from Article.php. This already reduces its linecount by about 15%, and there are plenty more actions still to do.
* Centralising actions like this is going to render a lot of hooks type-incompatible. There's simply nowhere you can put the ArticleConfirmDelete hook, for instance, where it can be passed an OutputPage as the second parameter. On the other hand, we can implement new hooks like ActionModifyFormFields and ActionBeforeFormDisplay, which can do much prettier stuff to the forms, like adding extra fields the 'right' way. Update LiquidThreads to use these new hooks where appropriate.
