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
A difference between UNIX and Windows is the dir separator,
which makes this test failing, because the file name does not match to
filter out the psr4 loaded classes to just keep the alias, which must be
part of the autoloader class list.
1) AutoLoaderStructureTest::testAutoLoadConfig
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
'ParserTestFileSuite' => '[...]...te.php'
'ParserTestTopLevelSuite' => '[...]...te.php'
'SuiteEventsTrait' => '[...]...it.php'
+ 'MediaWiki\Block\DatabaseBlock' => '[...]...ck.php'
+ 'MediaWiki\SpecialPage\SpecialPageFactory' => '[...]...ry.php'
+ 'MediaWiki\Revision\IncompleteRevisionException' =>
'[...]...on.php'
+ 'MediaWiki\Revision\MutableRevisionRecord' => '[...]...rd.php'
+ 'MediaWiki\Revision\MutableRevisionSlots' => '[...]...ts.php'
+ 'MediaWiki\Revision\RevisionAccessException' => '[...]...on.php'
+ 'MediaWiki\Revision\RevisionArchiveRecord' => '[...]...rd.php'
+ 'MediaWiki\Revision\RevisionFactory' => '[...]...ry.php'
+ 'MediaWiki\Revision\RevisionLookup' => '[...]...up.php'
+ 'MediaWiki\Revision\RevisionRecord' => '[...]...rd.php'
+ 'MediaWiki\Revision\RevisionSlots' => '[...]...ts.php'
+ 'MediaWiki\Revision\RevisionStore' => '[...]...re.php'
+ 'MediaWiki\Revision\RevisionStoreRecord' => '[...]...rd.php'
+ 'MediaWiki\Revision\SlotRecord' => '[...]...rd.php'
+ 'MediaWiki\Revision\SuppressedDataException' => '[...]...on.php'
)
Change-Id: I1485cc7309c20d131f398473367d281a3ce78a25
We use AutoLoader::$psr4Namespaces to include extension entries too.
All PSR-4 directories need to exist, otherwise there's no point in trying
to autoload from them.
I verified that this test would have caught T259448 and prevented it from
happening.
Change-Id: If2df3b79a926847e443f887218ab09274ace1a44
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
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
Follows-up d4045035b0.
This class was added to the MediaWiki\Special namespace, contrary to the
plan in T166010 which reserves that namespace for core special pages.
Instead, use MediaWiki\SpecialPage, following the directory in which it
is located.
Also, fix two bugs which prevented the introduction of a namespaced
class alias.
Bug: T166010
Change-Id: I6e31340aaae32a89beb7e45b79d76a7fea9808d2
Going directly to 8 is too much pain.
Depends-On: Iafcea151389663d79e70ad6ab3741ce8b2e25cac
Bug: T192167
Change-Id: I77ea560f4a5344bd1c356ecc3e7857968ad829b8
This makes AutoLoaderStructureTest in PHPUnit and the
generateLocalAutoload.php maintenance script much faster.
On my machine, it made it 35X faster (or time spent reduced by 97%).
Bug: T225730
Change-Id: Ife959bd17ce9c2ae952dfbd158ddb3d8475e8cb2
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
@covers does not make any sense for structure tests, which either
do not cover any PHP lines (they test things like configuration or
messages), or cover lines which cannot be determined at the time
of writing the tests (e.g. they cover all classes implementing a
certain interface). Requiring @coversNothing to be manually added
for all of them is a waste of developer time.
tests/phpunit/suite.xml has forceCoversAnnotation=true so removing
the annotations will not change test coverage, these files will
still be skipped.
Change-Id: I27cb58e92341b9b1a76f109701f5bc843adbaa9b
The file paths we inspect are always normalized (File_Iterator_Facade
applies realpath()), but the directory we compare against may not be,
depending on how wfLoadExtension() was called. Normalize the directory
before we remove the directory prefix from each file, so that we don’t
end up stripping away the wrong parts of the path.
Change-Id: Ib272fb892c18d989f8d439ed50c6a5a8fd542cc9
Sometimes classes can be loaded via autoload (PSR-4) and class_aliasing
and due to this calling array_unique() on expected classes will remove
one of these classes due to them sharing the same file (and array_unique()
works on array values).
Also allow for ::class suffixed classes to be namespaced (ie look for \
in the regexes)
Cleanup some of the regexes, remove redunant code (don't need multi cased
letters when we have /i), simplify them
Bug: T206728
Change-Id: I235274d579b1bfd12a448448ddf020546c9aa89b
Per discussion in T166010, we're going to handle class aliases (e.g. for
BC) by including the class_alias() call in the same file as the target
class. When the target class is a PSR4-compliant class, we still need to
pick up that alias for inclusion in autoload.php.
Thus, instead of excluding whole directories, we need to process the
files and filter out only those found classes that are PSR4 compliant.
Bug: T204983
Change-Id: I1c516998df368531c90ea54acc5be8be96e1db6c
This reverts commit 634c2ec2af.
Reason for revert: that strips the PSR4 directories from the class.
Example:
$dir BlueSpiceFoundation/src/"
$file BlueSpiceFoundation/src/ConfigDefinition/IntSetting.php
$abbrFileName: IntSetting
$expectedClassName: BlueSpice\IntSetting
$abbrFileName should be relative to $dir and not just the filename.
Bug: T198077
Change-Id: Ie934e309fee0392439b4e26d86249f0650e5ea67
When setting AutoloadNamespaces to './' in extension.json, the test
AutoLoaderStructureTest::testPSR4Completeness would fail. The directory
path is not made canonical while the file is, which causes the substr()
call being used to strip too many characters. For example:
$dir : /mediawiki/extensions/Wikidata.org/./
$file: /mediawiki/extensions/Wikidata.org/Hooks.php
$abbrFileName = substr( substr( $file, strlen( $dir ) ), 0, -4 );
>>> oks
Use pathinfo() to parse the filename. Yields 'Hooks' as expected.
Bug: T198077
Change-Id: Ia8a11d87788b32ddb426a16a61b410b05ff5f15e
Autoloading classes is a 100% accurate way to ensure the autoloader
worked, but there are cases where if optional dependencies aren't
installed, then autoloading the class will fail. We can re-implement the
logic behind the PSR-4 autoloader, and ensure that classes will be
autoloadable by turning the filename into a class name, and making sure
that class name is the one we found in the file.
Bug: T195823
Change-Id: I5df378180e567c257386482383ef73812592f989
Files like ServiceWiring.php can be safely located in a PSR-4 autoloaded
directory, because they have no classes.
Change-Id: I359b305df9071d6bc5afe4b5f29e762041f4aaef
AutoloaderTest covers the AutoLoader class, and AutoLoaderStructureTest
covers the structure part of the test.
Change-Id: Ic4e7bfd670e1c3413631bda31260cc1cc825b1a2
2018-05-26 16:16:02 -07:00
Renamed from tests/phpunit/structure/AutoLoaderTest.php (Browse further)
