Sets a cookie on user login (removed on logout) if wpStickHTTPS
was checked, which causes the browser to get a redirect if they
visit the HTTP version of the site.
Change-Id: I60f44a1062a93d15198edae6674bb3310a148b2d
The problem is that currently deferred updates are not executed
after action=ajax requests or file cache hits. This means that,
e.g. ViewCountUpdates are not executed after file cache hits.
The code to execute jobs (both deferred updates and job queue)
is now in MediaWiki::restInPeace() so that it's also executed
after what is mentioned above, and the remaining code of
MediaWiki::finalCleanup() is moved directly MediaWiki::main()
since that function is only used in one place and it make no
sense to keep a method for such little code.
Change-Id: I6f511a74c59a2e3653c10bfcff9b0d15118e699f
We have MediaWiki::getTitle() which will call parseTitle() if needed.
That method will be called in MediaWiki::main() when the Title object
is really needed. This allows to not have to call parseTitle() when
the DB replication lag is higher than the maxlag parameter or on
action=ajax requests.
Change-Id: Iebca2b3029e95879ea7739367b09c8c37502e71c
I found my comments in change 10088 is inadequate because we don't
have any known squid URLs in Title::getSquidURLs() and we may never
want to have... There's no hook there so extensions are unable to
add any squid URLs for them (maybe we want one someday? but new
extensions shouldn't be using the UnknownAction hook).
Change-Id: I44ba376f92776ec6bb32f91beb06f11ebd086fb4
See discussion on r111168.
Of course no one will see warning because trunk has $wgDeprecationReleaseLimit set to 1.17 by default
(<rant>have I mentioned how I don't like that variable. People enable warnings to be *warned* about
things. Making it so people won't get warned about things until a couple months after we've decided people
should stop using function/interface/etc defeats the purpose of having warnings</rant>)
p.s. Wasn't sure if this waranted something in the release notes, I don't think it does (It's just adding a warning)
but wasn't sure.
* Move Ajax stuff to before regular title/page action handling. Ajax actions circumvent most stuff and return early from the regular execution.
* Needed because getAction / Action-classes can't handle action=ajax properly, which isn't until MediaWiki::performAction
* Also undo's debug 'true' in the if-statement from r109688
* Action/Context stuff is pretty deeply nested everywhere.
* Should be okay now, at last.
* Reverts reverting r109243
* Same as r109223, except adding this:
+ if ( !$context->canUseWikiPage() ) {
+ return 'view';
+ }
- [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)
* Added Article::getPage() as accessor to the WikiPage object so that it can be set in the context from MediaWiki::initializeArticle()
* Use it WikiPage::main() to call doViewUpdates()
I'm doing to this now so that I can revert r105790 and use the WikiPage object before the 1.19 release
called in a way that matches the documented parameters
As it was, when an extension tried to use BeforeInitialize with the
documented parameters this resulted in an exception:
Detected bug in an extension! Hook HookFunctionName has invalid
call signature; Parameter 2 to HookFunctionName() expected to be a
reference, value given
allow page titles to be enumerated even when they are not guessable.
* (bug 32616) action=ajax requests were dispatched to the relevant internal functions without any read permission checks being done. This could lead to data leakage on private wikis.
* Made ExternalEdit use a context
* Updated DifferenceEngine to use ExternalEdit to send the diff stuff to reduce code duplication
* Introduced ExternalEdit::useExternalEngine() to check whether to use the external edit or diff (except for the action, section and oldid which are still checked in Wiki.php) to remove code duplication; external diff can now also be controlled with externaledit or internaledit URL parameters
* Use $wgContLang to get the name of the "Special" namespace instead of user's language
* Modified the line breaks in the comment on the top of the control file so that the URL is on its own line
* Updated extension to call EditPage::edit() instead of EditPage::submit(), the latter will just call the former
* Updated extension to let core handle itself the ExternalEdit mode instead of doing this themself
* (bug 26020) Setting $wgEmailConfirmToEdit to true no longer removes diffs from recent changes feeds
* Added second parameter to Title::userCan() and Title::quickUserCan() to allow callers to pass the User object to use for checks; this changes Title::userCan()'s second parameter from "do expensive queries" flag to User, but all callers should have been updated in r102183
* Updated callers that might throw a PermissionsError to use getUserPermissionsErrors() instead and pass the error array to the exception
* Refactored duplicate code in missingPermissionError()
* Moved Title::isNamespaceProtected() a bit upper and Title::userCanRead() near Title::userCan() to have related functions in the same location
* Some minor refactoring in permission-related functions in Title
* This replaces OuputPage::loginToUse() functionnality, made it simply throw a PermissionsEror exception and updated all calls in core
* Same for the check in SpecialUpload::execute(), EditPage::userNotLoggedInPage() and EditPage::noCreatePermission()
* Throw the same exception in EditPage::attemptSave() whether the user is logged in or not and let OuputPage::showPermissionsErrorPage() decide which message to display
* Replaced call to deprecated OutputPage::blockedPage() in SpecialUpload
* Displayed messages are the same as now, except the title is always "loginreqtitle"
* 'nocreatetitle' and 'uploadnologin' messages are still used by extensions, so I kept them, but the message 'whitelistedittitle' is not used anymore and has been removed
* Use local context instead of global variables
* Removed obsolete aliases PageHistory and PageHistoryPager; no longer used
* Made Action::getContext() and related methods public for the call in HistoryPager's constructor and also for consistency with other classes
* Left RawPage with back compat code for extensions that use it
* Removed calls to Skin for gen=(css|js). Calling action=raw&gen=(css|js) will now unconditionally return empty content
* Removed Skin::generateUserJs() and Skin::generateUserStylesheet() since they were only used in RawPage
