First iteration of adding a PermissionManager service as a replacement
for Title::userCan and User::isBlockedFrom methods.
- Created PermissionManager service
- Migrated Title::userCan to PermissionManager::userCan and deprecated the first
- Migrated Title::quickUserCan to PermissionManager::quickUserCan and deprecated the first
- Migrated User::isBlockedFrom to PermissionManager::isBlockedFrom and deprecated the first
Same for User::isBlockedFrom and PermissionManager::isBlockedFrom - the
$user parameter is now required so the declaration is changed from
isBlockedFrom( $title, ... ) to isBlockedFrom( $user, $title, .. ) which
means before User::isBlockedFrom removal all calls to it need to be updated.
Added PermissionManagerTest, it copies TitlePermissionTest but uses
PermissionManager instance instead of Title methods, this way keeping both tests
in place, we can ensure that nothing was broken and both are in working state
during the deprecation phase.
Bug: T208768
Change-Id: I94479b44afb3068695f8e327b46bda38e44e691f
This code doesn’t use any MediaWiki-specific code, so rename
MediaWiki\Services to Wikimedia\Services and move it below libs/. (Of
course, this does not apply to the MediaWikiServices subclass.)
Class aliases are added to retain backwards compatibity for now.
Bug: T211608
Change-Id: Ic14ea28ef21c359695b309d4293dbaaf5deedc09
Partial blocks logic will be used in multiple places. This
classes will group block restriction functionality to avoid
code duplication
Bug: T202036
Change-Id: I675316dddf272fd0d6172ecad3882160752bf780
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
Added spaces around .
Removed empty return statement which are not required
Removed return after phpunit markTestIncomplete,
which is throwing to exit the test, no need for a return
Change-Id: I2c80b965ee52ba09949e70ea9e7adfc58a1d89ce
This avoids the confusing error “Fatal error: Uncaught
InvalidArgumentException” or similar.
Bug: T195211
Change-Id: Ifda59a26f8bd968a2d0acbdb157d81dc0bf6aab4
This adds support for a PSR-4 (<http://www.php-fig.org/psr/psr-4/>)
autoloader, so instead of needing to manually list each class, just the
namespace prefix is needed.
Extensions can set a "AutoloadNamespaces" property in extension.json to
register PSR-4 compatible namespaces to be autoloaded.
The implementation is based off of the example implementation
(<http://www.php-fig.org/psr/psr-4/examples/>) with some modifications
for performance, notably cutting down on function calls, and only trying
to look up classes that are namespaced.
The generateLocalAutoload.php script will ignore any directory that is
registered as a PSR-4 namespace.
Bug: T99865
Bug: T173799
Change-Id: Id095dde37cbb40aa424fb628bd3c94e684ca2f65
Follows-up I8b1bdb84a969. This is not generated by that script,
the autoload.php file is, but that one has a similar comment
in it already.
Change-Id: Icb44f3dab356820f1e3aa5ba56949219af1b5719
Currently all new classes in core need to be registered
with the autoloader. This is acceptable but inconvenient.
This patch adds a script to read the output of php's tokenizer
to determine the names of all the classes within mediawiki core.
Patches with new or removed classes will just need to rerun
the maint script rather than manually adjusting the arrays.
A full conversion to psr-0 + composer would solve this as well,
but this is a very non-intrusive patch that can get us some
portion of the benefit(reduced manual maintenance) today rather
than months down the line once we figure out all the intricacies
of mediawiki + composer.
Change-Id: I8b1bdb84a9699de79f8b9951fa61e5437d083c55
Add a helper class to assist in collecting profiling information using
XHProf <https://github.com/phacility/xhprof> and a Profiler
implementation to hook it into the existing MediaWiki profiling system.
The Profiler includes support for generating tabular reports similar to
the traditional output of ProfilerSimpleText and ProfilerSimpleTrace or
sending data to a udpprofile daemon as supported by ProfilerSimpleUDP.
It also produces data compatible with the debugging toolbar.
Bug: T759
Change-Id: I16a75cb7636cb5dcef3830d738b2dcd2047d0aaa
This doesn't rely on any other parts of MediaWiki since we can
replace MWException with InvalidArgumentException here.
Change-Id: Id4512b184d24efc6674d486a5d452aa44dc871c6
- Put Profiler, ProfileSection and TransactionProfiler in their own
files and rely on Autoloader to use them (maintenance has been
using the autoloader here for some time--we don't profile the
autoloader manually)
- This reduces overhead in WebStart/doMaintenance by only loading
three functions at profiler initialization and defers until the
first profiling call happens
- Inline callback functions in ProfilerSimpleText rather than having
public static functions.
- Small comment and code formatting changes in various touched files.
Change-Id: Idf27677c068c50b847152c523a33e7f0c33fdeeb
list=deletedrevs has always been an odd one: it pretends to be a prop
module sometimes in taking titles from ApiPageSet, but when the pageset
supplies no titles it acts like a list module. This causes problems
such as bug 71389, and makes the whole thing unnecessarily confusing.
The solution is to split the "prop" and "list" aspects into separate
modules: prop=deletedrevisions when input should come from ApiPageSet
and list=alldeletedrevisions when not.
At the same time, let's take advantage of the situation to clear up some
other bugs. And let's share the revision-formatting code with
ApiQueryRevisions instead of partially reimplementing it.
Bug: 23489
Bug: 27193
Bug: 44190
Bug: 71396
Bug: 71389
Change-Id: I3e960d5c655bc57885d6d4ee227e67104808add7
An interesting experiment, but it was never completely fleshed out
and represents an anti-pattern as the only class that doesn't follow
the Profiler -> ProfilerStandard inheritance.
Since we want to refactor this to split profiling and profiling output
we need this unused but difficult to refactor code gone.
Maybe in the future after things are refactored and someone has the
time or inclination this could be dusted off again.
Change-Id: I1fd8813894e1fe88652b0c17b5ad8f42666bf776
Send wfDebug, wfDebugLog, wfLogDBError and wfLogDBError log messages to
the new MWLogger PSR-3 logger subsystem. Compatibility with the historic
logging operations of wfLogDBError are provided by MWLoggerLegacyLogger
and the MWLoggerLegacySpi logger factory.
Requires the MWLogger system introduced in I5c82299 and the Composer
managed libraries from Ie667944.
Change-Id: I1e5596d590144fbfdfd5f18bc42cf1ef0dbcac12
Allow $wgMWLoggerDefaultSpi to specify a more expressive object creation
by introducing a new ObjectFactory class which can process an array of
instructions to call either an object constructor or a factory method
with an array of arguments. This allows removal of the
$wgMWLoggerMonologSpiConfig global variable in favor of configuration
using $wgMWLoggerDefaultSpi.
New classes introduced:
; ObjectFactory
: Construct objects from configuration instructions.
Change-Id: If56cce5dcb1ad5712e238d6e2dab809a351f79be
This allows use of gender on Special:Log
Old message is kept for use in irc,
a test is added to ensure a unchanged irc message.
Change-Id: I0557a0d2751540cf0d7967333ffd767b934011c6
Use HTMLForm instead of self-built table structure, to be
prepared for use with MediaWiki UI.
Bug: 71446
Change-Id: I5c03dc543b910aab27a26a5a223341be50893cf3
The MWLogger class is actually a thin wrapper around any PSR-3
LoggerInterface implementation. Named MWLogger instances can be obtained
from the MWLogger::getInstance() static method. MWLogger expects a class
implementing the MWLoggerSpi interface to act as a factory for new
MWLogger instances. A concrete MWLoggerSpi implementation using the
Monolog library is also provided.
New classes introduced:
; MWLogger
: PSR-3 compatible logger that wraps any \Psr\Log\LoggerInterface
implementation
; MWLoggerSpi
: Service provider interface for MWLogger factories
; MWLoggerNullSpi
: MWLoggerSpi for creating instances that discard all log events
; MWLoggerMonologSpi
: MWLoggerSpi for creating instances backed by the monolog logging library
; MWLoggerMonologHandler
: Monolog handler that replicates the udp2log and file logging
functionality of wfErrorLog()
; MWLoggerMonologProcessor
: Monolog log processer that adds host:wfHostname() and wiki:wfWikiID()
to all records
New globals introduced:
; $wgMWLoggerDefaultSpi
: Default service provider interface to use with MWLogger
; $wgMWLoggerMonologSpiConfig
: Configuration for MWLoggerMonologSpi describing how to configure the
Monolog logger instances.
This change relies on the Composer managed Psr\Log and Monolog libraries
introduced in Ie667944.
Change-Id: I5c822995a181a38c844f4a13cb172297827e0031
The existing API help, formatted as basically a plain-text document
embedded in XML and with a little bolding and a few links
syntax-highlighted in after the fact, works ok for experienced programmers
but isn't at all newbie-friendly. Further, all the help is hard-coded in
English, which isn't very friendly to non-English speakers.
So let's rewrite it. The help text is now obtained from i18n messages
and output in HTML, with the default display consisting of help for a
single module with links to help for other modules. This, of course,
necessitates deprecating many of the existing help-related methods and
hooks and replacing them with new ones, but backwards compatibility is
maintained for almost everything.
At the same time, action=paraminfo also needs to support the
'description' and other help-related fields being output in wikitext or
HTML, and I11cb063d (to access all modules via the 'modules' parameter
instead of having 'modules', 'formatmodules', 'querymodules', and so on)
is folded in.
And we also add Special:ApiHelp. When directly accessed, it simply
redirects to api.php with appropriate parameters. But it's also
transcludable to allow up-to-date API help text to be included within
the on-wiki documentation.
Note this patch doesn't actually add i18n messages for any API modules
besides ApiMain and ApiHelp. That will come in a followup patch, but for
the moment the backwards-compatibility code handles them nicely.
While we're messing with the documentation, we may as well add the
"internal" flag requested in bug 62905 (although the 'includeinternal'
parameter it also requests doesn't make much sense anymore) and a
"deprecated" flag that's needed by several modules now.
Bug: 30936
Bug: 38126
Bug: 42343
Bug: 45641
Bug: 62905
Bug: 63211
Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
Requires skins use the 'mw-wiki-logo' class on the logo element for the styles
to apply and to load the 'mediawiki.skinning.interface' module (or implement
their own skin module that uses the ResourceLoaderSkinModule class).
This is backwards compatible with skins using inline styles as the class only
applies when used.
Bug: 56257
Change-Id: I4e6db89a688843ac24539f8fd1b408c0d04881b3
