I noticed anecdotally that 3% of load.php at WMF is spent in
AutoLoader::find(). It's unclear to me why that's so high, but
this change seemed to help a little bit (tested in a tight loop
on PHP 7.2 on bare macOS, and in a VM with Ubuntu).
[1] https://performance.wikimedia.org/arclamp/svgs/daily/2021-07-10.excimer.load.reversed.svgz
Change-Id: I6ad04d90595f92cc093cc8b922d15025248c73ad
$wgActions used to map string action names to true,
false, a string, a callable, or an object. Now it can also
be an array (that isn't a callable) corresponding to an
ObjectFactory spec for DI.
This patch converts the revisiondelete and rollback actions to
use DI, with the rest to be converted later. The new structure
of $wgActions is fully backwards-compatible.
We don't yet deprecate Action::factory(), ::getActionName(),
and ::exists(), those will be deprecated in a follow-up.
Additionally, we no longer impose a rule that only some
actions can be overridden on a per-article basis via
Article::getActionOverrides().
Bug: T253078
Change-Id: I0fc3c53d671eced1758458f9a0148180b40c6c9b
This replaces JobQueueGroup::singleton and ::destroySingletons.
A JobQueueGroup service has been added to serve as convenience
getter.
Bug: T277648
Change-Id: Ic8709119773ab788a07531193dc65d418536eda2
Use case: for a list of classes used in a specific context such as
MediaWikiServices, list all files containing these classes, so they can
be processed with command line tools such as grep.
Change-Id: I88dbee72dc5a560624f8cc1da0d905460309f624
Spotted a few of these while looking at flamegraphs for T273312. I don't
really think these fixes are going to have a noticeable effect, though,
since the slowness seems to be chiefly caused by FS functions.
Still I think these changes are worth the (low) effort, given that these
code paths are presumably hot, and that readability isn't affected IMHO.
Change-Id: I18c25e8a591d7fdc950c286370b7db5e85f3985f
Many files were in the autoloader despite having potentially harmful
file-scope code.
* Exclude all CommandLineInc maintenance scripts from the autoloader.
* Introduce "NO_AUTOLOAD" tag which excludes the file containing it
from the autoloader. Use it on CommandLineInc.php and a few
suspicious-looking files without classes in case they are refactored
to add classes in the future.
* Add a test which parses all non-PSR4 class files and confirms that
they do not contain dangerous file-scope code. It's slow (15s) but
its results were enlightening.
* Several maintenance scripts define constants in the file scope,
intending to modify the behaviour of MediaWiki. Either move the
define() to a later setup function, or protect with NO_AUTOLOAD.
* Use require_once consistently with Maintenance.php and
doMaintenance.php, per the original convention which is supposed to
allow one maintenance script to use the class of another maintenance
script. Using require breaks autoloading of these maintenance class
files.
* When Maintenance.php is included, check if MediaWiki has already
started, and if so, return early. Revert the fix for T250003 which
is incompatible with this safety measure. Hopefully it was superseded
by splitting out the class file.
* In runScript.php add a redundant PHP_SAPI check since it does some
things in file-scope code before any other check will be run.
* Change the if(false) class_alias(...) to something more hackish and
more compatible with the new test.
* Some site-related scripts found Maintenance.php in a non-standard way.
Use the standard way.
* fileOpPerfTest.php called error_reporting(). Probably debugging code
left in; removed.
* Moved mediawiki.compress.7z registration from the class file to the
caller.
Change-Id: I1b1be90343a5ab678df6f1b1bdd03319dcf6537f
One major difference with what we've had before is that now we
actually write class names into the serialization - given that
this new mechanism is extencible, we can't establish any kind
of mapping of allowed classes. I do not think it's a problem
though.
Bug: T264394
Change-Id: Ia152f3b76b967aabde2d8a182e3aec7d3002e5ea
Also move ResourceLoaderRegisterModulesHook under the same
namespace. I forgot this one in commit b7ac554304.
This is mainly motivated by making the collaboration graph
on doc.wikimedia.org not huge by pulling in the full range
of core hook interfaces.
<https://doc.wikimedia.org/mediawiki-core/master/php/classResourceLoader.html>
Depends-On: Ifa53d96dd3e4592208dbc991e2af9e6b7598e44d
Depends-On: Ib4571d80f55a4716e28b76ba1d007f95b0fb2540
Change-Id: I576305a5edb36a2ffb513e6d557bbf1d337cb17e
Follows-up f5aaf75ad1.
* Improve some docs for these hooks.
* Add type hints.
* Add them as a subgroup within the ResourceLoader docgroup
for easy navigation.
Bug: T246855
Change-Id: I52f31e2b63dcf265b27e68ba8fd4f885d82088ac
This reduces the size of the class map ($wgAutoloadLocalClasses),
and allows new classes and namespaces to be added without modifying
the class or namespace map as long as they conform to PSR-4.
Adding a PSR-4 mapping for the top-level MediaWiki namespace means that
conforming subnamespaces do not need to be listed.
I did not add some odd or broken cases, since I figure it's better to
fix them by moving the files, which can be done in a separate commit.
I removed testPSR4Completeness, since PSR-4 completeness is no longer
required, that's the point.
Bug: T166010
Change-Id: Ie5e50ecb519b99a1197688c046c7be245ce6da1b
This brings significant modularization to the Action API's parameter
validation, and allows the Action API and MW REST API to share
validation code.
Note there are several changes in this patch that may affect other code;
see the entries in RELEASE-NOTES-1.35 for details.
Bug: T142080
Bug: T232672
Bug: T21195
Bug: T34675
Bug: T154774
Change-Id: I1462edc1701278760fa695308007006868b249fc
Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
An injectable service interface for message formatting, somewhat
narrowed compared to Message.
Only the text format is implemented in this framework so far, with
getTextFormatter() returning a formatter that converts to the text
format. Other formatters could be added to MessageFormatterFactory.
Bug: T226598
Change-Id: Id053074c1dbcb692e8309fdca602f94a385bca0c
With the introduction of a REST API into MediaWiki core, we're going to
want to share parameter validation logic rather than having similar code
in both the Action API and the REST API. This abstracts out parameter
validation logic as a library.
There will be at least two follow-up patches:
* One to add calls in the REST API, plus the interface for the REST API
to do body validation. Should be reasonably straightforward.
* One to adjust the Action API to use this. That'll be much less
straightforward, as the Action API needs some MediaWiki-specific types
(which the REST API might use too in the future) and needs to override
the defaults on some of the library's checks (to maintain back-compat).
Bug: T142080
Bug: T223239
Change-Id: I5c0cc3a8d686ace97596df5832c450a6a50f902c
Depends-On: Iea05dc439688871c574c639e617765ae88a75ff7
Add some of the basic REST API class hierarchies:
* EntryPoint
* Router
* Request
* Response
* Handler
The actual entry point file rest.php has been moved to a separate
commit, so this is just an unused library and service.
Bug: T221177
Change-Id: Ifca6bcb8a304e8e8b7f52b79c607bdcebf805cd1
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
