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: I7f605aa9e117b5fd80d9b1440864fe526d2b14a5
Right now, if you set $wgNamespaceProtection, the protection interface
is confusing: it will allow you to apply "useless" protection levels for
any namespace except MediaWiki, where it will refuse to let you set any
protection at all.
The fix is to find which restriction levels are more restrictive than
the $wgNamespaceProtection restriction (i.e. where there is at least one
group that can pass $wgNamespaceProtection but not the level from
$wgRestrictionLevels), and use only those in the protection form. If
there are no such levels, we can skip showing the "protect" tab
entirely.
Change-Id: I9e2b29ade566abcd008ea2ad1e2f9818e315bb32
* Follows-up b2e2b2e016.
* Minor clean up of surrounding documentation comments.
* Fixed missing keys for messages in WebInstallerPage
Change-Id: Iaa692064262f3c0e10cfa5e4b1ec8c86e5d02362
Split parts of doUpdateRestrictions() into several more concise functions.
The biggest drawback is increasing $dbw->encodeExpiry() calls times 3. This is
not much of a problem given that's a very inexpensive function and it is only
called very few times ($limit holds 2 values in current codebase)
Added $reason to the ProtectionForm::save hook, so that other code hooking into
and adding their own settings into page protection form can also process the
reason for the protection change.
Change-Id: I879290ed83e4e47e9561d4c352fbd50c07d7e18a
It has long been recognized that using the 'protect' right to control
the ability to edit sysop-protected pages is troublesome. r31247 fixed
this by adding an 'editprotected' right, but for some reason in r32164
this was changed to bypass protection completely instead of fixing the
bug identified in r31462.
This patch goes back to do it the right way: editprotected no longer
bypasses all protection, and it is used instead of 'protect' for
controlling access to sysop-protected pages. For good measure, the same
is done with autoconfirmed protection (semiprotection): a new
editsemiprotected right is created instead of overloading the
existing autoconfirmed right.
This also fixes bug 27152 by making editprotected no longer special.
Bug: 13137
Bug: 27152
Change-Id: I6bf650a3fbdab8589ae6945c8c916eafd949e41c
These are needed for OAuth grants.
Note that, even if 'editmywatchlist' is not granted, various actions
will still allow for adding but not removing of pages.
Change-Id: Ie33446a228dd6ed0114730935c1bf65667f5ce01
Added spaces after/before parenthesis
Removed unneeded parenthesis around some statements
Broke a long line
Change-Id: I7fbe129f7bbf524dd0598ece2a9708643f08453b
A page can only be protected with cascading protection if the
requested restriction level is included in this array.
This replaces previously hard-coded values of 'sysop' and 'protect'.
This is necessary, because if any protection could be
cascading, users could who cannot normally protect pages could
"protect" them by transcluding them on protected pages they are
allowed to edit.
Bug: 47617
Change-Id: I5f8bcc899b46d466161894606cd27bf3b8624bd0
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
This change disables the protection form and hides the protect
links in case there aren't any restriction types avialable.
Having no restriction types available let to a PHP notice and an
uggly, broken form. This became necessary as there are cases
in which no restriction types are avialable (caused by extensions)
eg. https://gerrit.wikimedia.org/r/34662
Change-Id: I0e5d3cfb299808ca14ead6baec0a18091acaa2b2
Created a new method User::groupHasPermission and check also
$wgRevokePermissions for the given right
Change-Id: I41edb091fa35c8c68b6f95cc5fd208ea99418cdb
The LogPage::logName method has been deprecated in 1.19,
warnings being planned in 1.21.
This change removes any call in the MediaWiki core to this
deprecated method.
Removing extra whitespaces/tabs in includes/ProtectionForm.php.
Change-Id: I1907f17341ecb6448967a5283e3c913778dcb1a9
* The problem is that Title::userIsWatching() relies on $wgUser,
which is not suitable on every case. Instead User::isWatched()
requires both an User and a Title object.
* Replaced all core calls from the former to the latter
* Added a cache in User for the WatchedItem instances so we do not
need to do a database request every time something want to know
whether a page is watched or not, which can happen several times
per request.
Change-Id: Ifa9c55b7ffb487ce6893c74df233eedc7654dc5e
* Make OutputPage::setSubtitle(), OutputPage::addSubtitle() and OutputPage::appendSubtitle() accept a Message object in addition to a string
* Added new method OutputPage::addSubtitle() to replace appendSubtitle() and marked it as deprecated
* Clear the subtitles when showing an error page
* Always show the subtitle from Article::viewRedirect() when showing a page; left the parameter for use in EditPage
* Make Article::setOldSubtitle() add two subtitles and has to set "display:inline;" for the three possible divs to avoid too many spacing
* Removed the six different backlink subtitles and added one new message 'backlinksubtitle' to replace them and added OutputPage::addBacklinkSubtitle() to factorise common code
* Changed EditPage's view source to show "View source for <Page>" with the same backlink in subtitle for consistency with other back links and page titles
* When the user doesn't have permission to protect/unprotect the page, display a page with the title set to "View protection level for ...", then the permissions errors and the current protection levels. Except for the title, this was already the case for permissions errors, but when the database was read-only this was throwing an exception due to the change in OutputPage::readOnlyPage()
* Moved check for NS_MEDIAWIKI a level up, so that is it also catched on page save, and make the output in such case much more user friendly
* Changed edit token to be salted with array( 'protect', 'page name' ) (as for action=watch)
* Allow extensions to return false in ProtectionForm::save hook for consistency with other hooks and in that case fill the error message with 'hookaborted' if the extension does not provide an customised error message.
* Changed ProtectionForm::show() to accept an array of message name and its parameters in addition of a string with raw HTML and converted calls to use the new method. This also means that ProtectionForm::save can use this
* Removed the setSubtitle() call for the 'formerror' message in case of error since it's overriden by the "back link"
* Removed OutputPage::setPageTitleMsg() and OutputPage::setHTMLTitleMsg() and make OutputPage::setPageTitle() and OutputPage::setHTMLTitle() accept a Message object
* Updated core calls (including some that I missed last time because of non-matching case)
* Added Message::setContext() and use it in RequestContext so that I don't need to duplicate the call in OutputPage
* Yes, I'm calling $this->msg() on places and then setting the context one more time in OutputPage::setPageTitle() or OutputPage::setHTMLTitle(), but at least I won't be confused about which objects $
* ResourceLoader::makeLoaderConditionalScript:
-- window.mediaWiki -> window.mw; Not just because it's shorter but because that's the variable that is actually being used inside the script.
* ProtectionForm::buildCleanupScript
-- Use a single quote string and no new line
-- Use ResourceLoader::makeLoaderConditionalScript instead of duplicating this logic everywhere
* ProtectionForm::buildCleanupScript:
-- Use Xml::encodeJsCall to render javascript code
-- Use ResourceLoader::makeLoaderConditionalScript
-- Fix bug 31230 by using the new OutputPage->addJsConfigVars( r98374 )
(had to use $wgOut for now since there wasn't an obvious route to a context that I could find here (Article has context, but ProtectionForm::__construct takes any WikiPage, not just Article)
* EditPage::getEditToolbar:
-- Use Xml::encodeJsCall
-- Use ResourceLoader::makeLoaderConditionalScript
Fixes:
* (bug 31230) ProtectionForm should set wgCascadeableLevels in mw.confg instead of globally
* WikiPage functions/fields are "magically" part of Article when accessed for b/c. Magic is kind of ugly but there are too many callers to make breaking changes atm. Some functions are just wrappers for WikiPage ones (were magic won't work).
* Added newFromID() to each WikiPage subclass (works around pre-existing inheritance problem).
* Added Page class for convenient type hinting and changed hints from Article -> Page. This lets things use WikiPage objects without getting type errors.
* Updated FlaggedPage to extend WikiPage. Worked around getOldIdFromRequest().
* Added setTimestamp() to WikiPage and moved some timestamp setting code from ParserCache to Article.
* Removed ampersands from $dbw arguments.
* @TODO: dependency inject user objects for WikiPage
The idea is to migrate things to use WikiPage, as the run-of-the-mill "new Article()" call doesn't care about $oldid and $wgRequest. After that, Article, ImagePage, and CategoryPage can be rewritten as an Action class or something sane (a Viewer class of sorts).
* (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
* 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.
