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
Checking that the job queue is nonempty is cheap, and when the result is
negative (that is, when the queue is actually empty), it spares from having to
launch a derivative request to Special:RunJobs for job processing. The
derivative request is not cheap, because processing it requires having an
additional full instance of the application. This patch adds the check.
Bug: 60210
Change-Id: Icb95c35f4a8a3c9d4b5aff97fdfabf596d05940a
Adding a new global variable (DefaultSettings.php) named $wgRunJobsAsync, that
defaults to true, to allow installations to force the old synchronous job
execution on page requests instead of the new asynchonous one.
The asynchronous job queue execution was added in 1.22, executing a new shell
script, and it caused major problems for third party installations with restricted
environments or limited system resources, and also because a lot of bugs that went
unnoticed because WMF wikis do not use the on-request job queue.
In 1.23 it was changed to use a new internal HTTP request to a MediaWiki entry point
to perform the request, While some of the bugs were solved, it could still have
performance problems for opening a new process and loading a lot of MediaWiki PHP
objects on it, just to perform a request to see if there are pending jobs and execute
them (it doesn't check if there are jobs to execute). While this may improve speed
on single page requests, because it does not block the execution of the current page,
it has't been thoroughly tested on third party installations. And what is more
important, now there's no way to revert back to the old way of handling those jobs,
as it was done in 1.22 (setting $wgPhpCli = false). This means, in case of major
bugs on the job queue execution due to the new request, there's no way to fix it
other than editing MediaWiki PHP files directly, or completely disable the
on-request job queue handling (some hosts can't set up a cron job for that)
This situation makes it critical to have a safe way to revert to the old job queue
handling, at least until testing that the current implementation doesn't break a lot
of installations.
Bug: 61387
Change-Id: I892a3608228ec0a1c63268fb6180ec679c315980
The fifth parameter to fsockopen is the number of seconds
to wait before declaring the connection a failure. When not
provided it defaults to the php ini value of 'default_socket_timeout'
which is 60s. Under no circumstances should we wait 60s to
connect to ourselves, 100ms seems like a reasonable timeout
since its explicitly connecting to itself, but the exact timeout
could be slightly longer.
Change-Id: I18d328274ddf1e0848fce40ebf39e0466b5c4d5d
* Moved ApiRunJobs to a special page instead of going through
ApiMain and having to fight the logic there. As a separate
internal API, this does not show up on the API help page and
is no longer effected by $wgEnableAPI.
bug: 62233
Change-Id: I1db6f526d02e130a66ee03289858a734d89e6c00
* $wgEnableAPI may be false, though it is a basic part of MediaWiki.
This only disables api.php and not internal callers so just do that.
* Various socket functions may disabled. Though this is a terrible
wack-a-mole security measure to handle MediaWiki exploits or
non-authenticated services, it may still be in use, so work
around it.
Change-Id: I54a209e003ffce1fe36a5898fe0da735cf5e32e4
* A background internal HTTP request used to load the API.
This handles job execution and related periodic tasks.
It avoids blocking the main request or breaking it on fatals.
* This method avoids problems that shelling could have:
** Mismatched apache/cli PHP config or versions.
** Had to start a new process and could not use opcode cache.
** safe_mode and open_basedir restrictions required a fallback.
** Some wiki farms may not respect the --wiki parameter.
** wgMaxShellMemory applies to spawned PHP processes.
** Spawning processes is more prone to DOS due to a lack
of proper limiting/pooling.
bug: 60208
bug: 60210
bug: 60698
bug: 60844
Change-Id: I78b0e709301ac4a0c7b7ed337d6969d7546674bf
* Make it async on Windows
* Fixed possible "invalid filename" errors on Windows
* Redirect output to dev/null to avoid hanging PHP
bug: 60231
bug: 58719
Change-Id: If4e52b86fb3a1bff283dfba3dfac213367f47543
No uses found in core or Gerrit extensions.
* MediaWiki::articleFromTitle() (deprecated in 1.18)
* WikiPage::createUpdates() (deprecated in 1.18)
Change-Id: I689249b579ee89f883b97fdb4ac79fb3502c45dc
When using PHP-FPM to run PHP on a web server, the function
fastcgi_finish_request is provided, which flushes all response
data to the client and closes the connection, allowing PHP
to perform additional work without delaying the client.
This adds fastcgi_finish_request calls in index.php and api.php
where appropriate and if the function exists, so that the connection
is closed once the output is definitely finished.
Change-Id: Ic67a8956545874e94df5198088c0f4aa58ca376e
When a curid that doesn't exist is requested, cause the "Bad title" error
to be displayed rather than displaying the Main Page.
Bug: 58885
Change-Id: If54ca35b3799b8cf2f76e7f8a03001caa1fac676
The Line continuation Coding conventions prefers the closing parenthesis
on the same line than the beginning curly braces. This is done for ifs
and functions.
Also move some boolean operator from the end of a line to the beginning
and changed some indentation to make the condition hopefully better
readable.
Change-Id: Id0437b06bde86eb5a75bc59eefa19e7edb624426
The use of static server detection outside of its intended use case
(i.e. at the start of DefaultSettings.php), for example in r93258, was
an architectural error. Every other bit of information about the web
request in non-setup code comes from non-static methods of WebRequest,
which allows the request object to be meaningfully replaced or
subclassed. The situation became increasingly ridiculous as more
callers of WebRequest::detectProtocol() were introduced. Two of the
callers were calling it non-statically! I suppose they had the right
idea, in a way.
Using a non-static call allows caching, which is a nice additional
benefit.
WebRequest::detectProtocolAndStdPort() was introduced in r93258 as part of
the introduction of WebRequest::detectProtocol(). It was basically
useless. Grep indicates there was only one caller in core and WMF
deployed extensions, and it is patched here.
Change-Id: Ia0a61e98fbff7a46ceaeebcb02236e5eac3df0e1
This has been deprecated since 1.18, throwing warnings for over a
year and a half now, and nothing uses it anywhere in core or deployed
extensions.
No extensions in SVN seem to have this anymore (we must've cleaned
up well), and the only affected extensions in Git are:
- BlueSpiceExtensions
- DynamicPageList (commented, so shouldn't be a worry)
- SemanticPageMaker
- TwitterCards
If you're the author of one of these extensions or are feeling like
cleaning up ancient code, please get them fixed.
Change-Id: I8f3a54c14be4b38a8b917e32ba3a832e0a7ca116
Most code replaced wasn't exactly like what logException does
but most probably should be.
A few implementation differences with the code it replaced in
various places:
* MWException if-guards
Was there only to prevent a crash because getLogMessage is an
MWException method. Now that logException is generic, it seems
sensible to start logging those as well (follows-up a97f3550a0).
* Exception::getTraceAsString
Now using MWExceptionHandler::formatRedactedTrace instead.
It wasn't using it because that method didn't exist yet.
Notes:
* DatabaseError::getLogMessage
Removed as this override was no longer doing anything (we're using
MWExceptionHandler::getLogMessage instead of $e->getLogMessage).
Introduced isLoggable() to take over the responsibility of indicating
when an exception should not be logged (follows-up bcb9f9e1c0).
* DeferredUpdates and Wiki.php
Both specificy MWException. Though ApiMain intends to catch all
and only logged MWException because it couldn't otherwise, these
actually only catch MWException (as opposed to catching all and
having an if-statement inside). Left those as-is to have them
continue propagate other exceptions.
* JobQueueFederated and JobQueueGroup
All specify to catch JobQueueError only.
Not sure whether it should catch other exceptions. It now can,
but I'll leave it as is in case it intends to have those be
handled elsewhere (or fatal).
Change-Id: I4578a0fe7d95a080f1a3b292ce7ae73a4d5fcaca
== Prelude ==
wl_notificationtimestamp controls sending the user e-mail
notifications about changes to pages, as well as showing the "updated
since last visit" markers on history pages, recent changes and
watchlist.
== The bug ==
Previously, on every view of a page, the notification timestamp was
cleared, regardless of whether the user as actually viewing the latest
revision. When viewing a diff, however, the timestamp was cleared only
if one of the revisions being compared was the latest one of its page.
The same behavior applied to talk page message indicators (which are
actually stored sepately to cater to anonymous users).
This was inconsistent and surprising when one was attempting to, say,
go through the 50 new posts to a discussion page in a peacemeal
fashion.
== The fix ==
If the revision being viewed is the latest (or can't be determined),
the timestamp is cleared as previously, as this is necessary to
reenable e-mail notifications for given user and page.
If the revision isn't the latest, the timestamp is updated to
revision's timestamp plus one second. This uses up to two simple
(selectField) indexed queries per page view, only fired when we
do not already know we're looking at the latest version.
Talk page indicator is updated to point at the next revision after the
one being viewed, or cleared if viewing the latest revision. The
UserClearNewTalkNotification hook gained $oldid as the second argument
(a backwards-compatible change). In Skin, we no longer ignore the
indicator being present if we're viewing the talk page, as it might
still be valid.
== The bonus ==
Comments and formatting was updated in a few places, including
tables.sql and Wiki.php.
The following functions gained a second, optional $oldid parameter
(holy indirection, Batman!):
* WikiPage#doViewUpdates()
* User#clearNotification()
* WatchedItem#resetNotificationTimestamp()
DifferenceEngine gained a public method mapDiffPrevNext() used
to parse the ids from URL parameters like oldid=12345&diff=prev,
factored out of loadRevisionIds(). A bug where the NewDifferenceEngine
hook would not be called in some cases, dating back to its
introduction in r45518, was fixed in the process.
Bug: 41759
Change-Id: I4144ba1987b8d7a7e8b24f4f067eedac2ae44459
Since the forceHTTPS logic checks if the user is logged in, which calls
all sorts of hooks, some that assume that $wgTitle is setup (like
AbuseFilter for preventing autocreation of usernames), move the
logic down a few lines.
Bug: 55435
Bug: 53498
Change-Id: I53c82921595a9014b555e4ec468e5ba10454cd3a
The feature that oldid and diff parameters override the title was
not working if wiki's main page is a special page, because that
behaviour was excluded for special pages. Hence moved the main
page as default title code further down, so that we will hit the
no title provided condition for the oldid and diff parameter only
links.
Bug: 54452
Change-Id: I62cc6e2568a4db988fcf113955ba02710e42a1d2
From mark's comments on https://gerrit.wikimedia.org/r/#/c/86268/, we
should be setting Vary: X-Forwarded-Proto when the response varies on
the protocol, which is the case for redirects from http->https.
Change-Id: Ie6dc9da4e804199b99e3a7abbea7775a181801a0
After we switch to not using prefixes, still respect prefixed cookies
for users who are currently logged in.
Bug: 53538
Change-Id: I950e36e10420209fca28c41c438c363a3f332c14
* Introduce a hook allowing automatic redirects to HTTPS to be
disabled on the basis of client IP address.
* Make User::requiresHTTPS() return false if the client IP is
blacklisted as such.
* On login, make the "stick HTTPS" option default to false if the
client IP address is blacklisted as such.
* Do not redirect anonymous requests to HTTPS.
* If $wgSecureLogin is enabled, link to the HTTPS login page *via*
the HTTP redirect, so that there is no need to vary the cache of
anonymous page view HTML on client IP address.
Change-Id: Iaa9dd2108431b8c35e05db4bfe78a629018a003c
Removed the wpStickHTTPS checkbox from the login form, and instead
just use the user's preferences along with whether they came from
HTTPS or not to determine if they should stay in HTTPS.
Bug: 29898
Bug: 52283
Change-Id: I69e9cb23b8d700e821b8a961c672958e4e19e4f8
* Also factored out a new wfShellExecDisabled() function.
* This will keep the process in the background if possible to avoid
killing site performance, especially with slow jobs.
* This also keep fatals and uncatcheable exceptions from
hitting the user.
* If $wgPhpCli is not set to an actual path or safe mode
is on, then the old code will be used.
Change-Id: I6a28152251659ee53eee2604f16d5bf02c85a44f
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
Early in the request we call Action::getActionName to get the action
name for HTMLFileCache to see if the current action is cached.
This causes data to be loaded from the WikiPage object
stored in the main request context. However, later when
we're initializing the Article object, we overwrite that
WikiPage object with the one used by the Article object.
Later on the WikiPage object has to be re-loaded, and
hence the exact same db request is run twice in one request,
which seems wasteful.
Instead, initialize the Article object using the WikiPage
object from the context, in order to save the already
loaded data.
Change-Id: I292f0d70feb505fae5fa955fd735d85ad3b22fea
This was developed for translatewiki.net, which has but
millions of messages in MediaWiki namespace. To avoid
exploding the message cache, not all of them can be
loaded. Instead of logging what messages have been
requested, now it uses the fact that if the
message has not been customised in the
site language, there is most likely
no reason to load it in any other
language either.
Change-Id: I6dd81b3858acfd2b73332e46668d46015e99c748
Was accidentally broken in Ie38ae198, where the request URL was compared
against the final target title, not the title of the redirect. Also
tested squid purges of redirects, since that code presumably hasn't been
tested for a while, and committed my very advanced testing framework.
Change-Id: Ib2ffe8e109bcc4859e22df5470bddfdb09e67afa
* Added support for different queue types and methods for storing queues.
* Treat each job type as being on its own queue, at least logically.
* Added $wgJobTypeConf to configure queue types for each job type.
* Improved the job DB table so that duplicate job checks actually work
and are faster. Also improved the method for popping rows of the table.
* Disabled duplicate job removal for everything except refreshLinks.
The DELETE statements just add DB overhead and are not useful for cheap
jobs, especially ones with start/end params (which are unlikely to have
exact duplicates).
Change-Id: I49824c7fa855fea4ddcac5c9901ece8c2c0101d0
