Some extensions like PageTriage will be able to use this new
parameter to determine whether to show its own curation toolbar.
Change-Id: I07e85aa37edc994c5a2bf9d011976b91ff01ab14
Affects whether these modules are loaded:
* mediawiki.searchSuggest ($wgEnableAPI only)
* mediawiki.page.watch.ajax ($wgEnableAPI, $wgEnableWriteAPI,
'writeapi' right)
* mediawiki.page.patrol.ajax (same as above)
Checking of $wgUseAjax has not been removed where it was
already present, in case some users have set the variable
to false to disable these specific features.
Bug: 30213
Change-Id: If2ec219cfbb94e7c9718c58b9b54a508d0e0c656
I've changed the logic in Article::showPatrolFooter to be able
to fetch the recent changes id and to only show the patrol link
in case the change hasn't yet been patrolled.
In case recentchanges patrolling is enabled this will try to
create a patrol link for the revision the user is currently
viewing. If only new page patrolling is enabled it tries to
create a patrol link for the first revision of the page.
Furthermore I've removed the passing around of &rcid parameters
within MediaWiki as those had several issues (some even security
related) and were only a workaround to protect the DB from some
queries, which is no longer needed.
This has already been partly implemented in a different manner in
r45778 but had to be reverted in r46542 due to performance issues.
This version shouldn't cause such issues as I'm only adding one or
two indexed database queries per page view.
I've written this new version of the patch with mostly
performance in mind and even tested the database queries it uses
against the replicated databases of enwiki on the toolserver. I'm
pretty sure this can't be implemented any faster without creating
a new index on the recentchanges table.
As I was on it I've implemented RecentChange::isInRCLifespan which
checks whether the given timestamp is new enough to may have a RC
row. That way we can avoid some DB queries for timestamps which are
older than the max RC age.
Fixes bugs:
(bug 15936) New page's patrol button should always be visible
(bug 35810) ! N pages non-patrol-able
(bug 36641) Patrol page link shows on non-existent revs
Change-Id: I1e24733cafbfdc51b7a5a9a1c1baf948e760fe1a
MediaWiki is sending HTTP 200 for every user page, this can result in
search engine indexing user pages with block hint. This is not happen,
when the page exists (even it is empty), so applying the default robot
policy also for non-existing user pages to avoid this.
Change-Id: Ia62b977b3488d6b002c7b129d9308b7887e4f42d
This will help with improving human readability of JS and JSON
objects encoded by both ResourceLoader and the API. This patch
also adds new "utf8" parameter to the JSON formatter of the API.
Changes to FormatJson class:
* Added escaping of '<', '>', and '&' by default to protect against XSS.
* Removed unnecessary escaping of '/' and added an additional option to
unescape non-ASCII characters (those above U+007F) as well.
* Added PHP 5.3 pretty printing code (to replace Services_JSON) that
uses a four-space indent as PHP 5.4 does.
Changes to Xml class:
* Defined Xml::encodeJsVar() in terms of FormatJson::encode()
and added a pretty printing option. Also added a pretty printing
option to Xml::encodeJsCall() as well.
* Deprecated Xml::escapeJsString() and QuickTemplate::jstext();
callers have to add quotes themselves, hence the escaping of
both double quotes and apostrophes.
Bug: 26818
Change-Id: I1987190f1ba5bf41738e7bd611209706c1f6bb5c
* Ran spell-checker over code comments in /includes/
* A few spellchecking fixes for wfDebug() calls
Found one very strange (NOOP?) line in Linker.php - see "TODO: BUG?"
Change-Id: Ibb86b51073b980eda9ecce2cf0b8dd33f058adbf
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
* 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
