This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
* Add $wgRequestTimeLimit. If it is non-null, it starts a time limit,
using Excimer with a fallback to set_time_limit().
* Add pretty formatting of timeout exceptions thrown by the library.
Related refactoring.
* Expose the library's critical section feature in MediaWikiServices
* In Setup.php, call warnIfHeadersSent() before sending session headers.
This helped to debug a related issue I had.
* In wfTransactionalTimeLimit() use the new library, and respect the
existing library time limit if it is larger than
$wgTransactionalTimeLimit.
Bug: T269326
Depends-On: I6409ad8a5cba775c27b0d5a79d3300c4dac4c91a
Change-Id: I2e6f6351c451407c06cc7e20932548f7b62e36b6
This deprecates access to the global service container before
initialization is complete. For now, such premature access will
trigger a deprecation warning. In 1.37 we can prevent it entirely.
Bug: T153256
Change-Id: Ibd3ab32d92c9c3d3783082ab574739467c1c2ff9
This does not help to avoid the suppression inside the class,
but it avoids the suppression for all callers
Remove unneeded local vars while looking at the code
Bug: T269895
Bug: T216348
Change-Id: I5ce9a2dddca2b3bb556eb7adb5305178db09a71a
Store IP and device information in the session and log when
it changes. The goal is to detect session leakage when the
session is accidentally sent to another user, which is a
hypothetical cause of T264370. The log will be noisy since
users do change IP addresses for a number of reasons,
but we are mainly interested in the ability of correlating
user-reported incidents where we have a username to filter
by, so that's OK.
Based on I27468a3f6d58.
Bug: T264799
Change-Id: Ifa14fa637c1b199159ea11e983a25212ae005565
Deprecated since 1.35, and no longer used in core, bundled, or
wmf-deployed projects.
Bug: T160813
Change-Id: Idd3166ef90d1795a0b22dc29d52de76048d0703e
Add $wgForceHTTPS. When set to true:
* It makes the HTTP to HTTPS redirect unconditional and suppresses the
forceHTTPS cookie.
* It makes session cookies be secure.
* In the Action API, it triggers the existing deprecation warning and
avoids more expensive user/session checks.
* In login and signup, it suppresses the old hidden form fields for
protocol switching.
* It hides the prefershttps user preference.
Other changes:
* Factor out the HTTPS redirect in MediaWiki::main() into
maybeDoHttpsRedirect() and shouldDoHttpRedirect(). Improve
documentation.
* User::requiresHTTPS() reflects $wgForceHTTPS whereas the Session
concept of "force HTTPS" does not. The documentation of
User::requiresHTTPS() says that it includes configuration, and
retaining this definition was beneficial for some callers. Whereas
Session::shouldForceHTTPS() was used fairly narrowly as the value
of the forceHTTPS cookie, and injecting configuration into it is not
so easy or beneficial, so I left it as it was, except for clarifying
the documentation.
* Deprecate the following hooks: BeforeHttpsRedirect, UserRequiresHTTPS,
CanIPUseHTTPS. No known extension uses them, and they're not compatible
with the long-term goal of ending support for mixed-protocol wikis.
BeforeHttpsRedirect was documented as unstable from its inception.
CanIPUseHTTPS was a WMF config hack now superseded by GFOC's SNI
sniffing.
* For tests which failed with $wgForceHTTPS=true, I mostly split the
tests, testing each configuration value separately.
* Add ArrayUtils::cartesianProduct() as a helper for generating
combinations of boolean options in the session tests.
Bug: T256095
Change-Id: Iefb5ba55af35350dfc7c050f9fb8f4e8a79751cb
A terminating line break has not been required in wfDebug() since 2014,
however no migration was done. Some of these line breaks found their way
into LoggerInterface::debug() calls, where they mess up the formatting
of the debug log.
So, remove terminating line breaks from wfDebug() and
LoggerInterface::debug() calls.
Also:
* Fix the stripping of leading line breaks from the log header emitted
by Setup.php. This feature, accidentally broken in 2014, allows
requests to be distinguished in the log file.
* Avoid using the global variable $self.
* Move the logging of the client IP back to Setup.php. It was moved to
WebRequest in the hopes that it would not always be needed, however
$wgRequest->getIP() is now called unconditionally a few lines up in
Setup.php. This means that it is put in its proper place after the
"start request" message.
* Wrap the log header code in a closure so that variables like $name do
not leak into global scope.
* In Linker.php, remove a few instances of an unnecessary second
parameter to wfDebug().
Change-Id: I96651d3044a95b9d210b51cb8368edc76bebbb9e
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
This was previously making calls to various methods during the
Setup.php, which apart from being deferrable logic that isn't
needed on most requests, is also risky/complicated because MW
isn't initialised yet at this point.
Bug: T189966
Change-Id: Iaee3f2af8d18bc5095e9297cbe1b6efc627f3977
Updated Doxygen markup in several .php files triggering warnings when mwdocgen.php is executed. Removed
obsolete settings MSCGEN_PATH and TCL_SUBST from Doxyfile. The former would generate a warning in 1.8.16
while TCL support was removed in 1.8.18. Since TCL_SUBST was blank anyway, it was removed prior to getting
to .18 in production. Increased DOT_GRAPH_MAX_NODES from 50 to 200 since Doxygen complained about it being
too low for API and Maintenance.
Bug: T248706
Change-Id: I9c67f0807d1b43089d351263d4f591dee5501f36
* Document how wgWANObjectCaches and wgMainWANCache are
used / should be used.
Remove outdated mention of event relayers.
* The easiest way I could document the 'other' options that
wgWANObjectCaches entries can have was by saying which keys
can't be set and that aside from these and class/cacheId
they are all passed on.
However, that wasn't (yet) technically right given we do pass
class/cacheId on blindly, which might be unexpected for
subclasses in theory. Explicitly unset those in ServiceWiring
to avoid any chance of confusion. Also simplify that code
slightly overall in terms of var names and var re-use,
and improve error messages a litle bit.
* Test plan for the wanobjectcache-deployment doc ref:
$ php maintenance/mwdocgen.php \
--file includes/DefaultSettings.php,includes/libs/objectcache/
Then open path/to/mediawiki/docs/html/, click on the docs for
DefaultSettings, and find-in-page to "wgMainWANCache".
Change-Id: I1cfc65c2cc4dbceed6b9777c2b808527a58daeb9
Only soft deprecated, removal is in process, see task and subtasks
Still used within core, but thats okay, since its not hard deprecated
Bug: T159299
Change-Id: I0e7e9857a0f6b83c4fd3df6316591c4b01e85106
Prior to 2004, the site language was configured via $wgContLanguageCode,
derived from that were $wgContLang (object). $wgLanguageCode was just a
cached copy of $wgUser->getOption('language').
In 2004 (r5492, 5537c5b85e, MW 1.3), $wgContLanguageCode ceased to be
supported as a configuration variable. Instead, the site language would
now be configured via $wgLanguageCode instead and the confusion started.
Its value was copied to $wgContLanguageCode for back-compat, and also
because $wgLanguageCode was still also used to store
User::getOption('language') right after initialising $wgContLang.
Sometime between 2004 and 2006, $wgLanguageCode was relieved of this
secondary purpose, as documented in r5492 (5537c5b85, MW 1.8), leaving it
as just a configuration variable for the site language.
Use of $wgContLanguageCode has been removed from Codesearch-indexed repos,
including third-party repos on GitHub.
Bug: T247674
Bug: T189966
Change-Id: Ic91f500d48d772360bf10323a2ed0733c0ea890d
I've moved the simple config expansions that don't depend on anything
else in Setup.php together, more compactly.
Change-Id: Iefb7f8ffdca70bcfbf7cbf49f7939747c5ab0d76
Deprecated since 2014 in MediaWiki 1.25, and the feature it
controlled was removed from core in 1.26.
The feature is still available via the HitCounters extension,
<https://gerrit.wikimedia.org/g/mediawiki/extensions/HitCounters/>
Bug: T189966
Change-Id: I5e46d1aef1b44b8828bdd1bba644136391cc1c4c
These are not configuration but business logic, similar to the
canonical names that are in NamespaceInfo.php, these must always
exist and cannot be altered or unset.
They were previously unconditionally assigned during all requests
in Setup.php and passed down as "site configuration".
Changes:
* Move them to MessagesEn.php where they can be cached and
processed the same way as other core-provided aliases.
Document and confirm with tests that this is a mergeable
attribute that follows the language chain.
* Remove the duplicated code in a few places that was reading
this variable + Language::getNamespaceAliases(), to instead
just call the latter and move the logic there, centralised,
and tested.
In doing so I noticed that these were applied in an
inconsistent order. Sometimes the config won, sometimes not.
There's no obvious right or wrong way here, but I've chosen
to standardise on the way that Language::getNamespaceIds() did
it, which is that config wins. This because that method seems
to be most widely used of the three (it decides how URLs and
titles are parsed), and thus the one I least want to change
the behaviour of.
* Document that $wgNamespaceAliases may only be used to
define (extra) aliases, it is and never was a way to access
the complete list of aliases.
Bug: T189966
Change-Id: Ibb14181aba8c1b509264ed40523e9ab4000fd71a
This isn't a default setting or fallback, it's unconditional
business logic that can't be overidden. This doesn't need to
run on every web request in Setup.php.
Bug: T189966
Change-Id: I708131b111cd2ff0e34c3cc8a4b933eff260b3da
Also remove some comments that didn't help understand the line
below (e.g. "install header callback" above "HeaderCallback::install")
Bug: T189966
Change-Id: Ib0b413c557f83f8f58683515fcdbf1817fe1f661
There were no callers to this method, outside the $messageMemc
global, which is to be deprecated with T243175. Pending its
eventual removal, its usage has been inlined as the function
was trivial anyways.
Any previous callers were migrated with the convertion of the
MessageCache to a service in 752e7dd707.
Bug: T243176
Change-Id: I79846442512f023dcdf2f1f8c425156589c0421d
Add getAvailableLogos static method and wgLogos config variable
Longterm we'll phase out wgLogo and wgLogoHD for this more extendable
config.
wgLogoHD is marked as deprecated. wgLogo continues to function as before
when wgLogos doesn't exist to cause minimum disruption.
From now on all logos should be accessed via getAvailableLogos. Patches
in Minerva and Vector follow. See I00899c16c0325f36b671baf17e88c2b5187b3526,
I569e0d800e147eabc7852567acd140108613f074 and
I013bd0904fe8c55efa49d14e84cf06ec1412896f.
Bug: T232140
Change-Id: I66a971631c623cc94b58eb0e5e5bad804789bf1c
Since MediaWiki 1.18, $wgServer has been automatically set by the web installer
when it generates LocalSettings.php, so this shouldn't be an issue for most
wikis. The CLI installer now supports a --server optional parameter to
specify $wgServer, otherwise it'll be set to 'http://localhost' by default.
Users will see a fatal error pointing them to the on-wiki $wgServer
documentation that I've updated as well.
Originally this functionality was slated for removal in 1.20, but now is
just a good time as any. It also calls into other parts of MediaWiki before
most things are initialized, making it difficult to librarize some code.
Bug: T30798
Bug: T232931
Change-Id: Ia5d616e7fafbab01655067c24c5a3a073b254f21
This is to ensure that the CI job is working with the new version.
Note: redundant_condition_detection should have worked as expected by
this version, but unfortunately it still has false positives.
Bug: T235049
Bug: T231636
Change-Id: Idaba6584cb5b2ff19b6455c7bbec6b89619ddbff
The variable is also read in a few other places, such as to
export the value from api.php (siteinfo) and load.php (mw.config)
but those requests don't need to be held back by this extra
logic.
Alternatively, if we really want to require this for all consumption,
we should probably let PathRouter provide the value and require
consumers to use it. E.g. services->getPathRouter->getArticlePath,
or something like that.
As easy first step, I'm moving it to PathRouter, called from
WebRequest::getPathInfo which is still called on all index.php
requests for any wiki page action in any namespace (incl Special)
when the wiki uses anything other than the default 'index.php?title='
article path.
Test Plan:
* Set '$wgArticlePath = 'bla';`
* View /mediawiki/index.php/Main_Page, and observe the fatal
error message (same as before this change).
Bug: T189966
Change-Id: Id06c2557e2addb58faeef0b6f7767a65b8de55a5
Phan can treat scalar types as non-interchangeable with
`scalar_implicit_cast` set to false. This patch fixes some of those
issues (which are in total >1000), namely the ones with alphabetic order
< includes/actions.
Change-Id: Ib1c6573ab899088bc319b9da9ceaffc850da3dbe
