This class handles caching across distance sites where purges
must reach both. It also aims to make purging more reliable in
the face of network glitches and node consistent hash ejection.
bug: T88492
Change-Id: I686811b3075bf22e2f4de45127e8461e54648ead
This allows for extensions to format their log entry parameters, and
keeps the code for formatting API log entry parameters in the same place
as for other formatting.
This also takes the opportunity to rearrange the output format slightly
to avoid conflicts like what's happening in T73020.
Bug: T35235
Bug: T73020
Bug: T91466
Change-Id: I6846ce09322eb404c506b5a51780a44ce9279fe2
There is a new special page, Special:EditTags, which is very similar to
Special:RevisionDelete in a lot of ways. In fact, the SpecialEditTags class
started off as a copy-paste of SpecialRevisiondelete.
You invoke this special page by going to an article history page, checking
some revisions, and clicking "Edit tags of selected revisions". Then you
pick the modifications you want to make and click "Apply". Very much like
the revision deletion workflow.
I had to restructure some of the Action routing code, which was only
designed to handle revision deletion. Also removing some code from
SpecialRevisiondelete which didn't work as advertised in the first place,
and definitely doesn't work now.
Change-Id: I7d3ef927b5686f6211bc5817776286ead19d916b
You can add tags at the same time as performing action=edit, as long as you
have the "applychangetags" right. Also, you can add or remove tags after
the fact from revisions and log entries using the API action=tags.
No UI is provided for either of these changes. The target audience is user
scripts, gadgets and similar tools.
Includes a new log parameter format type: "list", for a comma-separated
list of values.
Logging of change tag events is limited to those that do not accompany an
edit (i.e. those done after the fact), and is hidden from Special:Log by
default, similar to the patrol log.
Bug: T20670
Change-Id: I37275e0f73fa3127f55da0c320b892551b61ee80
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
Move the non-namespaced classes referencing external Monolog classes to
an isolated PHP source file so that they aren't brought into scope by
the need to load another shim class.
Bug: T95220
Change-Id: I8270b8d5cd25db5a0f84fa94f59a6555052ae1ae
Move the MWLogger PSR-3 logging related classes into the
MediaWiki\Logger namespace. Create shim classes to ease migration of
existing MWLoggerFactory usage to the namespaced classes.
Bug: T93406
Change-Id: I359cc81fbd2dcf8937742311dcc7d3dee08747b0
* This ends up being more complex than its worth
and even more so for multi-DC support
Bug: T93006
Change-Id: Iaa774fe69061e42955b11dc82d30dba93208e606
* Associate Profiler objects with a request context by adding a $context
property with a getter and a setter.
* Introduce ProfilerOutputStats, which writes profiling data to the stats
buffer associated with the current request context.
* Make it the Profiler class's responsibility to enforce $wgProfilerLimit.
* Deprecate $wgProfilerLimit in favor of the (more aptly named, IMO)
$wgProfiler['threshold'] config setting.
* Tidy up Profiler instance creation code in Profiler::instance().
* Add Profiler::getOutputs, which returns an array of ProfilerOutput instances
which are configured for the current profiler and whose canUse() method
returns true.
* Make ProfilerStub not log by creating a stub ProfilerStub::logData() method
which does not call the parent. Previously the parent class checked if $this
was an instance of ProfilerStub and returned early if so.
Task: T90623
Task: T85641
Change-Id: Icf644ad3435c1f30d0a49957a97b481808a3153d
The Monolog\Handler\SamlingHandler class available since Monolog v1.12.0
is an upstreamed equivalent of MWLoggerMonologSamplingHandler.
Requires: I8790da95fd658234e35b2d846af35993ebcd80e9
Change-Id: I3841cbab95382a66098d90f5570fa0bf3521578a
Using a ResourceLoader module to send the data to the client
For I3fafc561
Message changes:
wikieditor-toolbar-characters-page-.* -> special-characters-group-
wikieditor-toolbar-characters-(endash|emdash|minus) -> special-characters-title-
Bug: T91608
Change-Id: If9c5cdbe077e8796e1ebae99f759331251b5c4b1
Also move creation of UploadStash to main entry point of the special
page to avoid use of context before it is set (by called getUser).
Change-Id: Ibcb17b6ee1b853d807f91104ba428b307e9a5208
This was left over from a previous attempt at Oracle support,
which was removed in 1.10 (r19196 / ccf91e827a).
Change-Id: I5f9b82fffc0b4f84286b697be8d504020fe22547
* SiteLookup interface is added, and SiteStore extends
it. (any SiteStore type hints can be changed to use
SiteLookup if all they need is lookup functionality)
* Memcached based SiteStore code is split from the
database SiteStore, and SiteSQLStore is deprecated.
If no caching is desired when using a SiteStore, then
use a SiteDBStore instance, instead of passing $source
parameter in SiteStore::getSite and SiteStore::getSites.
* SiteListFileCache renamed to FileBasedSiteLookup and
implements SiteLookup.
Bug: T77990
Change-Id: I36b599884c211580ea6806a8a190c65c4f9087cf
Follows-up 87dfc20b1e.
It recently started generating dirty output because
BufferingStatsdDataFactory was manually placed – in a different
position than script would (i.e. not alphabetical).
Change-Id: I030a6ec9eb6f3a9b6cb54c9646acf2a898b93a80
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
Restbase, the REST content API service, is to be queried instead of
Parsoid by current Parsoid users (most importantly VE). This patch
introduces the Restbase virtual REST service class and transparently
maps Parsoid calls into Restbase ones if parsoidCompat is set when
creating the service object.
Additionally, $wgVirtualRestConfig is introduced in DefaultSettings.php. This
is a first step towards global service configuration and management.
Bug: T89066
Change-Id: I4d4043e5052327bbd789331f1c05b607c45fe7cb
* The data directory can now be set via the construction params
* A standalone factory method now replaces the subclass
* Also made mDatabaseFile protected
Change-Id: I1791fd4f630e5c121fa7f68f473411a7c12d0c97
* On a basic/default install there is only a single wiki
and nothing uses this. Larger wikis would want to use redis.
Change-Id: Ie5bf1a644ae60b2c6ca72b165fa5510113717611
This makes it easier for subclasses to use ResourceLoaderWikiModule. Currently
many subclasses of this simply need to override the getPages() method.
UserModule and SiteModule keep their getPages override due to the set of pages
being dependent on context.
Change-Id: I388531398671afacfec36c6c5746d72267b5bdac
HashSiteStore comes from Wikibase (see I783bd95), where it was
called MockSiteStore.
This enables some phpunit tests, related to Site objects, to no longer
depend on a database, memcached or other external storage. This makes
tests faster and more simple.
Bug: T90874
Change-Id: I048d37bd2aaa5f17c9fe16b2855df8bf9fe7bc8c
I thought a unit test was supposed to fail if this hadn't been run, but
I3936417b and I40fd6aaa recently got merged despite it.
Change-Id: Idb9b4b77a4a1c82ed74ec829fad8c12a9c39af09
The base BagOStuff class and some of the implementations are
not dependent on MediaWiki and can be in the libs folder.
Change-Id: I299f9abb778abc65a70461a2aff3015c02a1f04d
This script would perhaps better belong in the SisterSites extension, as noted
on the extension's MW.org description page. However, that extension was never
actually developed to a usable state (first commit was r16390, no substantial
changes since) or imported into Git, so apparently the feature (or at least
its implementation) is of only limited, possibly historical interest.
Change-Id: Ia4c3b0316815f06b7e82f013edfd1798ed07d9a3
The TemplateParser class provides a server-side interface to cachable
dynamically-compiled Mustache templates. It currently uses the
lightncandy library to do compilation (which is already included in
the vendor repo).
Also converting NoLocalSettings.php to use it as a proof-of-concept.
Bug: T379
Change-Id: I28cd13d4d1132bd386e2ae2f4f0d1dd88ad9162b
The RESTBase team has requested the ability to check the validity of a
CSRF token and to interface with Title::userCan().
The former is accomplished by the new action=checktoken module. The
latter by a new parameter ('testactions') to the existing prop=info.
Bug: T88010
Change-Id: I2530f1315ec93f5be9fb437137992150fdc305f2