Its state can change when people do something with objects it returns or
when they alter globals like $wgRequest. By resetting this singleton, we
ensure that no such change will propagate outside of a test.
Change-Id: I7e8598716d810a09c17f80a05deecab617b62346
To avoid misleading errors in case of failed initialization,
flags used to protected against recursion need to be reset
in case of an exception being thrown.
Change-Id: Ifbc1db4b827012177fcfd271981179ebb2329b52
Follow up to I13baec0b6 ("Config: Add Config and GlobalConfig classes"):
Config:
* Rather than returning Status objects, Config::set will now throw an exception
if an error is encountered
* Config::factory was moved into it's own ConfigFactory class.
* Since there are no more functions in it, Config was turned into an interface.
GlobalConfig:
* Remove $prefix args from Config::set and ::get. The idea of having an
abstract Config class is to abstract some notion of configuration data from
the particular way in which it is currently implemented (global variables).
So the abstract base class has no business dealing with variable name
prefixes.
** Instead GlobalVarConfig's implementations of get and set call getWithPrefix
and setWithPrefix internally, which are now protected
* Rename GlobalConfig to GlobalVarConfig, which makes it clearer that it isn't
referring to the scope of the configuration value, but to the scope of the
variable name which provides it.
ConfigFactory:
* ConfigFactory is where Config objects are registered, and later constructed.
* Config objects are registered with a given name, and a callback factory function.
This allows for implementations to construct the object with the parameters they want,
and avoids the overhead of needing an entire class.
** The name 'main' is the default object returned by RequestContext::getConfig(),
and is intended to be used by core.
* This is a singleton class, the main instance can be obtained with:
ConfigFactory::getDefaultInstance()
In addition to the above:
* $wgConfigClass was removed, and $wgConfigRegistry was introduced, which
stores a name => callback. The name is to be what the Config instance is
registered with, and the callback should return an implementation of Config.
* Tests were written for the new ConfigFactory, and GlobalVarConfig's tests
were improved.
Co-Authored-By: Ori Livneh <ori@wikimedia.org>
Co-Authored-By: Chad Horohoe <chadh@wikimedia.org>
Co-Authored-By: Mattflaschen <mflaschen@wikimedia.org>
Co-Authored-By: Parent5446 <tylerromeo@gmail.com>
Co-Authored-By: Reedy <reedy@wikimedia.org>
Co-Authored-By: Daniel Kinzler <daniel.kinzler@wikimedia.de>
Change-Id: I5a5857fcfa07598ba4ce9ae5bbb4ce54a567d31e
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.
Change-Id: I8c9f30128b46086064326708a4878228ba459447
Allows configuration options to be fetched from context.
Only one implementation, GlobalConfig, is provided, which
simply returns $GLOBALS[$name]. There can be more classes
in the future, possibly a database-based one. For convinience
the "wg" prefix is automatically added.
Ironically, this adds the $wgConfigClass global variable
which is used to determine which implementation of Config
to use by default.
The ContextSource getConfig and setConfig methods were introduced
in I23194d1ba (1.23), but have no uses in Gerrit, so they can safely
be re-purposed.
Change-Id: I13baec0b6d4ea7badf20b9c5f9b40846348838e4
First step of providing configuration without relying on globals.
You can use this in your code now as follows:
$myvar = $context->getConfig()->get( 'wgMyVar' )
Change-Id: I23194d1ba747a9e0d925154ae065cbd612b4f591
If something is messing around with $wgTitle before MediaWiki::main()
sets $wgTitle in the first place, it needs to be able to reset it back
to null to avoid a problem like bug 53498. And to do that properly, it
also needs to be able to clear the title in the RequestContext.
Bug: 55435
Change-Id: I6c763b70bbffa0762ca52e61acf7dc200da4075f
Also add docs about how suhosin.session.encrypt tends to break
this (I was thinking about throwing an exception if the setting was
on in RequestContext::importScopedSession, but the docs seem to
indicate that you can tweak how the session is encrypted, so it
sounds like somebody could set up their php so everything worked).
Bug: 48371
Change-Id: I5a471c1f941fce046451fbb9abce1c830185cabb
* Renamed WebRequest::exportUserSession -> RequestContext::exportSession.
Updated the only callers of this new function.
* Init the user with User::newFromId() instead of relying on the session
(which breaks when things like CentralAuth are enabled).
* Made RequestContext::exportSession() include the user ID.
* Removed now-redundant user ID checks in upload jobs.
* Added unit tests for the session import function.
Change-Id: I543e6766f7a8a828ea5d270328c3bc7738c6fe94
* (bug 44080) Also carry-over the IP and HTTP header info.
* This adds a RequestContext::importScopedSession() function.
Change-Id: Ie9c0a4d78fb719569c8149b9cc8a5430f0ac5673
Just log and soldier on, since for some reason we are seeing a lot of
these exceptions at the moment, with multiple root causes. Based on Matt
Walker's I49dbc2d7. Updates Idc11b547. See bug 44754.
Change-Id: I2e8c062741c1b2ec2acd68dc76d3fb6efb113571
Looks like someone messed with RequestContext when I wasn't looking at it.
WikiPage is a representation of the Title. It should not be possible for wikipage
to point to a different title than the context's title.
Fix this issue by unsetting WikiPage when setting title and updating title when
setting wikipage.
Change-Id: I40471b12d08763cb1b47b8382f96d8db94b4f319
* 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
* Removed OutputPage::setPageTitleMsg() and OutputPage::setHTMLTitleMsg() and make OutputPage::setPageTitle() and OutputPage::setHTMLTitle() accept a Message object
* Updated core calls (including some that I missed last time because of non-matching case)
* Added Message::setContext() and use it in RequestContext so that I don't need to duplicate the call in OutputPage
* Yes, I'm calling $this->msg() on places and then setting the context one more time in OutputPage::setPageTitle() or OutputPage::setHTMLTitle(), but at least I won't be confused about which objects $
