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
* Sets short-lived cookie in EditPage
* Adds JS module, 'mediawiki.action.view.postEdit', to all views to
convert cookie to wgPostEdit. This avoids caching the variable in the
HTML.
* Based in part on PostEdit extension
Change-Id: Ie89507f8e98c365df9d93a7633223103b9025790
Rather than sending a 404 on empty user pages, send a 200 response.
It's ideal to use the user's page as an OpenID identity url, but
OpenID expects 200 responses on identity urls. If we send 404s on
empty user pages it's necessary for all users to have content on
their pages to use Wikimedia as a provider. This change eliminates
that requirement.
Fixes: bug 45241
Change-Id: I527aa9d9c19c5cef7bebde78ef22f426bcbb3cd6
Makes life easier for static analysis, since they don't need to
handle if the end of a function where a wfProfileOut was not called
was reachable or not.
It is recommended to review this change ignoring whitespaces
(specially for includes/parser/Tidy.php)
Also documented the rationale for the elseif chain in UploadBase::detectVirus()
Change-Id: Ic4f65937fa9e6f926d8fcfd670e3b0e99e06eefc
Since SVN r106354 (85ee2d2d), when passing null or an invalid block target
to Block::newFromTarget(), it was never returning any block, even if the
vague target would have matched one.
This broke two features of core MediaWiki:
- Excluding user and user talk pages of blocked users from being indexed,
the feature that actually caused bug 33101 and the revision mentionned above
- Blocking of account creation when both the user and its IP address are blocked,
but of only the IP address blocks prevents account creation (bug 13611)
And maybe some others in extensions, I didn't check that.
This changes reverts part of r106354 to make Block::newFromTarget() work again
in that case and changed Article::getRobotPolicy() to pass the user to be checked
as vague target only when it's an IP address and as specific target otherwise.
Change-Id: Ie7e16e0bae8c4326d16cca237877693f7b474a01
(bug 43466) If enabled, send a rel=canonical link on every page
indicating the correct server to use. I tested all three callers:
Article, ImagePage and the variant feature in getHeadLinksArray().
Change-Id: I59b7c1d5589825ea390967036190218d5ce2db88
Implement AJAX patrolling with the new mediawiki.page.patrol.ajax
module, which makes use of the API via mediawiki.api.
During the patrol process a spinner (created by jquery.spinner)
shows up and after it a suitable message gets shown via
mediawiki.notify.
Depending on whether we had success or not the link then turns up
again or the brackets completely disappear just like on a normal page view.
On top of adding the module, I've changed the following:
- Added the patrol token to the ResourceLoaderUserTokensModule.
- Registered messages 'markedaspatrollednotify' and
'markedaspatrollederrornotify'.
Change-Id: I472357566dda0ab572c20e2e4b87508b0f2f4c73
The error is Fatal error: Call to a member function getParserOutput() on a non-object in includes/WikiPage.php on line 3363.
The problem is that if the fifth parameter passed to PoolWorkArticleView::__construct() is not given or is null, which is now
the case since the change mentioned on the first line of this commit summary, the content is fetched from Page::getContent().
When the Page object is a WikiPage instance there is no problem, but when this is an Article instance, Article::getContent()
actually returns the content as *string* and not as object, like it did before the Wikidata branch merge.
Worked arround this by passing the WikiPage object to PoolWorkArticleView from Article::view().
Also removed non-existing sixth parameter to PoolWorkArticleView::__construct().
Change-Id: I537862f519542de4f034be29bba4b75898382f59
Before the introduction of the content handler, missing content was
signified by getText() returning null instead of a string. null will
work much like an empty string in most contexts, so in many places,
it was not checked explcitely whether the conent was null.
Now, when getContent() returns null, this often caused a fatal error,
because the code would access whatever getContent() returned as an object,
without checking whether it was null (because no such check was performed
previously, when the content was represented as a string).
This check introduces explicite checks for getContent() returning null
in the most essential core classes.
Change-Id: I551a90b0b67b8edc7570ca5d252ecc1de903f097
The introduction of the ContentHandler caused quite a few functions and hooks to
become deprecated. Usage of these has been removed in core, but is still present
in extensions. Extensions should be fixed after ContentHandler has settled in a
bit, but for now we need a way to silence the warnings.
Change-Id: Ia223243222675f778e8f8c32923f956790db0b4f
Also passed some $wgUser direct (when already there), so it is seen by
someone, that the user should be passed to that method.
Change-Id: Id4d5504a05ea34d80d59262ad3aef28f09c807a6
- This is needed to for I90965346 ((bug 37453) Move
$wgDisable(Lang|Title)Conversion to ParserOptions)
because that change sets an option based on the Title,
and I don't want to duplicate that to all ParserOptions
that need it.
- Refactored ApiParse to have a WikiPage object available
and changed some part to take advantage of having this
object available. Also used ApiBase::getTitleOrPageId()
to reduce code duplication.
Change-Id: Iec98e472af9c43d940f77261367a796b0d7b4b54
ContentHandler::runLegacyHooks can be used to run hooks that don't
supprot Content objects yet. runLegacyHooks will issue a warning and take
case of serialization/unserialization of the content as appropriate.
Changeset 2: rebased.
Change-Id: I31109061110f87c38bdeebf30d520c8e1241bb29
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
This comes from
https://translatewiki.net/wiki/Thread:Support/MediaWiki:Missing-article
that asks for a link to the deletion log in the
'missing-article' message.
Instead of simply changing that message I replaced
it with two news messages 'missing-revision' when trying
to view an old revision and 'difference-missing-revision'
when showing a difference. This removes the "lego"
construction of 'missing-article' with 'missingarticle-rev'
and 'missingarticle-diff' submessages.
I had to keep current messages since they are still
used in extensions.
Change-Id: Ibe60c84cfea922a78b3ad22cc48185a109cd617d
Two reasons:
- the page must exists to reach this part of the code
- it's useless to have special classes (redirect, stub)
since this a link to the history and not to the
content itself
Change-Id: I59af2f237e0539842cc7777ddd44ba5ac500b070
