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
Move the default of 2000 to DefaultSettings.php, and promote
the installer warning to a hard value.
Recommend that the setting be disabled, or increased to 5000.
Change-Id: Ifb0aadf8b52fd2d5c2a32f55e38eaa9c2600dfb5
This is only relevant when processing page views or when constructing
Title urls with an 'action' query. Pretty important stuff, and worth
optimising for if we had to choose, but we can defer it in this case
without slowing it down, which is better for everything else.
It also means we don't mutate configuration (beyond setting whole values
as dynamic defaults), which seems desirable, and makes the overall behaviour
easier to test. Handling absence of 'view' should be PathRouter's
responsibility, not Setup.
Bug: T189966
Change-Id: I9c1eea2dcea74be0e283eb2b175268315ced1793
* Remove checks in HTMLFileCache.php and Article.php.
These haven't been needed since the same check was added to Setup.php,
many years ago. When FileCache is enabled, The Setup.php code disables
MWDebug. There is no reason for FileCache to then also disable itself
based on unused config. That means both of them lose.
We now handle this logic in one place: MWDebug::setup().
* In rebuildFileCache.php, turn it off explicitly, just in case.
The previous code there didn't work because finalSetup()
is called after doMaintenance.php includes Setup.php, which
is what checked this config var to decide on MWDebug::init.
On the other hand, it's also always off in CLI mode.
But, let's not depend on that, maybe we decide to enable it on
CLI one day! Just keep it off explicitly here.
Bug: T189966
Change-Id: I45a8f77092249751dc6f276aa5bb67ebf5b4f64c
Define the global constant MW_REST_API in rest.php, by analogy with
MW_API. Also generalize this by adding MW_ENTRY_POINT, which contains
the entry script name, "cli" or "unknown". This allows tests such as
if ( MW_ENTRY_POINT !== 'index' )
which is probably what is really intended by defined('MW_API') in many
cases.
Change-Id: I24099f4cdd170de17afd6e1bbad67c9b204071fc
This is currently forcing more object cache interfaces to be constructed
than might be needed in a given request. The configuration for these
interfaces is usually quite straight forward or can be trivially
verified from eval.php.
If we do want to log this, I would recommend doing it from the classes
constructor instead e.g. something like:
LoggerFactory::getInstance('MessageCache')->debug( get_class( $cache ) );
Bug: T189966
Change-Id: I06dc6dfbdf274bb57e9295b0c757b8d52c02acbe
This is only needed when viewing SpecialRecentChanges (or a related
page). Move the consuming logic to that class, where it can be
maintained as part of the rest of the code. This also makes it
more testable and makes config easier to work with or load from
elsewhere in the future. Aside from some dynamic default values,
configuration should generally not mutate. If there is some domain-
specific way to consume it, the relevant component should be
responsible for doing so. This also means we defer such logic to
where it is needed, instead of unconditionally for all possible
features that might be used.
Bug: T189966
Change-Id: If17608909711d98ac560b6d64f72ba7913a561a9
To my knowledge this never goes anywhere. These are left overs from
when we used profileIn/profileOut still, which we no longer use
given things like Tideways and XHProf are now recommended for
profiling, instead.
Bug: T189966
Change-Id: Id1bacc951f267dc1d3872aed935afd306adc37b3
