For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: If560596f5e1e0a3da91afc36e656e7c27f040968
This annotates classes that can safely be instantiated by
extensions, per the Stable Interface Policy.
Bug: T247862
Change-Id: Ia280f559874fc0750265ddeb7f831e65fd7d7d6a
This class specifically has these 2 things in many cases and converts
into the use of a tenary operations.
Quoting @Thiemo_WMDE from Gerrit comment: "The ?: operator will skip
empty arrays, empty strings, as well as the string "0". But this is
not a problem here because the properties under test are all objects.
Objects are always considered true in PHP."
Sample change can be seen below as, from;
```
if ( !is_null( $this->skin )) {
return $this->skin;
} else {
return $this->getContext()->getSkin();
}
```
to
```
return $this->skin ?: $this->getContext()->getSkin();
```
Change-Id: I377b118d86a24c7bcb15512f6714e6201a3e36ee
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
Change-Id: Idcec077ef3fdf029b632cceafd0150851ad723e3
I'm also removing obsolete short comments that don't add anything to
whats already obvious from the method header. For example, I really don't
need a comment to understand that a method that's called "setUser" and
accepts a parameter named "$user" of type "User" is meant to "set the
User object". I mean, how more obvious can it be? ;-)
Change-Id: Ib079108457a5aa2a6896e95837542ab93b465144
Having such comments is worse than not having them. They add zero
information. But you must read the text to understand there is
nothing you don't already know from the class and the method name.
This is similar to I994d11e. Even more trivial, because this here is
about comments that don't say anything but "constructor".
Change-Id: I474dcdb5997bea3aafd11c0760ee072dfaff124c
Follows-up I2874175647e (7fdc3d09a3).
* Avoid "MediaWiki" in class names. If unavoidable, always camelcase.
* Use a more descriptive name, matching the implementing the class ("Buffering").
* Use "I" prefix for consistency with other MediaWiki-provided interfaces.
(Avoid "Interface" suffix, which is foreign to MediaWiki and is only used
in the StatsdClient namespace, which this interface is not in).
Bug: T166354
Change-Id: I06de59122625f9c23e7c1a1bfa69a7ddabbf379e
Note: calling msg() with no parameter was never supported,
doing this on a RequestContext for example would result in:
PHP Warning: Missing argument 1 for wfMessage() ...followed
by a bunch of fallout.
So this patch only formally declares what was already a
requirement in reality.
Change-Id: I1864afb8bcc641698689828914949a06506d8f3a
The following changes are added:
- Created MediawikiStatsdDataFactory interface
- Added hasData() method to see if there are any data to send
- Added getData() method to fetch data
- Made service infrastructure use MediawikiStatsdDataFactory interface
- Made wfLogProfilingData() use MediawikiStatsdDataFactory interface
- Added capability to enable/disable buffering collector
Bug: T166354
Change-Id: I2874175647e987996a9a399829b3319674471aaa
* Add `Timing`, an interface which mimics the W3C User Timing API.
It provides a canonical way to store and retrieve markers (timestamps)
and measures (timestamps + duration).
* As the initial use-case, use it to record 'requestShutdown'.
Change-Id: I36b29162ffcc091406df025463b0e2797e52f19a
This patch adds a metric data service object to the IContextSource interface,
with full support for StatsD meters, gauges, counters and timing metrics, via
the liuggio/statsd-php-client, which this patch also introduces.
Usage example:
$stats = $context->getStats();
$stats->increment( 'resourceloader.cache.hits' );
$stats->timing( 'resourceloader.cache.rtt', $rtt );
The metrics are flushed to a StatsD server, which may be specified via the
'StatsdServer' configuration key. If no such configuration key exists, the
metrics are discarded.
The StatsD client supplants MediaWiki's StatCounter class. wfIncrStats()
will continue to work, but it will delegate to the StatsD data object.
Change-Id: Ie10db1c154d225971398e189737de7c560bf0f90
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
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
Previously, the msg method was not taking into account any
changes to the context, and was just using the original context.
For example, if you had a DerivativeContext object, where the
original context had a language of en, and then you did
$derivContext->setLanguage( 'fr' );, $derivContext->msg( 'foo' )
was still outputting stuff in english instead of french.
Change-Id: I4a87e0e2664e77bf79a80c873db384e0c3f607e7
* 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