Sometimes the special page can’t be created – for example, the list of
registered pages could have changed between the data provider and the
test function, due to extensions conditionally registering their special
pages. Skip the test in this case instead of crashing.
Bug: T275661
Change-Id: I573967ac22ed3a596b4f80b76d395ac948f802e8
ActorNormalization needs to have separate wiring if we want to be able
to access it by name. This is needed to allow access to the service in
declarative wiring, e.g. via ObjectFactory specs.
As an aside, this changes SpecialPageFatalTest to not construct special
pages in a data provider. Accessing services in data providers should be
avoided. This change does not eliminate all such access, but reduces it
by deferring service lookups via ObjectFactory.
Change-Id: I5792cdcc0e5b0d1681f55dbe3e1f70c34a0cb775
Exception::getMessage() always returns string, so it will
never equals boolean false, so the test will always fail, but
with a confusing error message.
Bug: T274591
Change-Id: Icd10e67a70666927eca886c829a4a3b1cd7441eb
My personal best practice is to not document @params when there
is a @dataProvider. I mean, these test…() functions are not
meant to be called from anywhere. They do not really need
documentation. @param tags don't do much but duplicate what the
@dataProvider does. This is error-prone, as demonstrated by the
examples in this patch.
This patch also removes @throws tags from tests. A test…() can
never throw an exception. Otherwise the test would fail.
Most of these are found by the not yet released I10559d8.
Change-Id: I3782bca43f875687cd2be972144a7ab6b298454e
These are not only 100% identical to the actual code, but also:
* It's error-prone. Some are already wrong.
* These test…() functions are not meant to be called from
anywhere. What is the target audience for this documentation?
* There is a @dataProvider. What such @param tags actually do is
document the provider, but in an odd place. Just looking at
the provider should give the same information.
* The MediaWiki CodeSniffer allows to skip @param when there is
a @dataProvider, for the reasone listed.
Change-Id: I0f6f42f9a15776df944a0da48a50f9d5a2fb6349
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
Creates an OPTIONS handler that handles any OPTIONS requests that are
not already handled by a handler. CORS has no mechanism to ensure the
user is authenticated, so the Router will reject cross-origin requests
from anon users.
This change allows authenticated users to make cross-origin
requests if they authenticate with OAuth or if
$wgRestAllowCrossOriginCookieAuth is enabled.
Bug: T232176
Bug: T262712
Change-Id: I128b4bdbec4f6bea35142153c951fd7b79617106
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
As was pointed out in CR on the original change from December 2011, the
test requires elevated privileges when it is run against a database with
binlogging enabled, which is a nuisance when I'm trying to test replication-
related code. The author commented that the test was to support GeoData,
but that was only true until the "schema revamp" of February 2012.
I considered mocking the database and making it into a test of
streamStatementEnd, since that code was introduced at the same time, but
we already have DatabaseMysqlBaseTest::testStreamStatementEnd().
I also removed the restoreFlags() call since that was apparently left
over from testFlagSetting(), which has been moved to DatabaseTest.
Refs:
* https://www.mediawiki.org/wiki/Special:Code/MediaWiki/107376
* https://www.mediawiki.org/wiki/Special:Code/MediaWiki/108603
* https://www.mediawiki.org/wiki/Special:Code/MediaWiki/110649
* 67f08d6990
Change-Id: I1a6b9d0cd91c8539ac1080a423b519743088733e
This is specifically for fatal errors, so it's fine that some
queries encounter (non-fatal) errors. Surpress them for now,
so that we can safely re-enable enforcement for everything else.
Bug: T248191
Change-Id: I962ee2dbb0568cc869fda6fa7312edc45ba43215
This helps preventing mistakes, for example if you don't know or you
forget to generate the sql schema for one or all of them.
Also it helps preventing malicious changes to the generated files that
might go in without much scrutiny as the manual files.
Bug: T252919
Change-Id: I50e2715a55914f7712f9925c149bd09e8265a20b
* Get rid of a long regexp that had to be maintained and
was broken anyway, resulting in a false negative.
* Fix that false negative.
* Make the failures array a bit more readable.
Bug: T248075
Change-Id: I4e4e5d6487d23b0d64f29c113d84bddce758e516
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
ResourceLoaderFileModule::readStyleFile() both reads a style file from
disk and processes it through LESS, CSSJanus and CSSMin. Factor out the
processing part into ResourceLoaderFileModule::processStyle(), which
takes a string of unprocessed CSS/LESS rather than a file. This is
needed for future support for styles that don't come (directly) from a
file, but are generated through packageFiles.
Other changes:
- Use a hash of the source instead of the file name in the cache keys
for the LESS compilation output
- Also prefix the cache key with 'resourceloader' while we're changing
it anyway
- LESS compilation no longer adds the source file itself as a dependency
- Don't pass down $flip, just use $this>getFlip()
Change-Id: I86e880d06af724f0fbae93e042c85e0395771912
Avoid data providers for dynamic expansion over all JS, CSS
and images files known to MW and extensions (1000+), because
there's non-trivival overhead in PHPUnit for creating a separate
"test" wrapper and iteration for each.
Instead, make each group a single test with each of the checks
being an assertion within that.
Reduces test count of 'php phpunit.php structure/ResourcesTest.php'
(with MW core + Vector + Minerva installed) from 1039 tests to
37 tests, and reduces runtime from ~1.6min to ~40sec.
This is the same pattern I previously adapted in a5a672b1a5
for the biggest part test of this suite (dependency verification),
but I forgot to apply it to all the others.
Bug: T225730
Change-Id: Iae46b2d9ff8cd70aa6e64aaddf6ccf839591153b
New data provider and test method were added to ensure file paths are correct and the file is present.
Bug: T231430
Change-Id: Iadafe0df1104de8829ea87632d65b3008cf80d76
Added:
- ContentHandlerFactory
Tests:
- PHPUnit
Changed
- Calls of changed and deprecated
- DI for some service/api
Deprecated:
- ContentHandler::* then similar to ContentHandlerFactory
- ContentHandler::getForTitle
- ContentHandler::$handlers
Bug: T235165
Change-Id: I59246938c7ad7b3e70e46c9e698708ef9bc672c6
This tests validity of parameter definitions for the MW REST API, like
ApiStructureTest does for the Action API.
Bug: T243437
Change-Id: Iac9ca951d00573be6efe00cc07478c3581c84588
ApiStructureTest has a lot of logic for validating Action API settings
arrays during CI. Some of that logic should be part of ParamValidator
instead.
Bug: T242887
Change-Id: I3c3d23e38456de19179ae3e5855397316b6e4c40
Depends-On: I04de72d731b94468d8a12b35df67f359382b3742
ApiBase falls back to this message when the module itself doesn't define
an extended-description message. ApiDisabled and ApiQueryDisabled should
do so as well.
Bug: T242534
Change-Id: I8f3ed17559363d9c66c5baf0ef7b0675714dc877
This was done automatically by replacing every assertContains with
string *needle*. Then verifying the results.
Bug: T192167
Change-Id: Id8cbbf3b01e948f80046714183cc299f86be21fd
Done automatically using the master version of MW codesniffer and
running composer fix.
Bug: T192167
Change-Id: If6b40f515fde32ab5eff074a90e821c30c791827
Going directly to 8 is too much pain.
Depends-On: Iafcea151389663d79e70ad6ab3741ce8b2e25cac
Bug: T192167
Change-Id: I77ea560f4a5344bd1c356ecc3e7857968ad829b8
assertEquals( false, … ) still succeeds when the actual value is 0, null,
an empty string, even an empty array. All these should be reported as a
failure, I would argue.
Note this patch previously also touched assertSame( false ). I reverted
these. The only benefit would have been consistency within this codebase,
but there is no strict reason to prefer one over the other. assertFalse()
and assertSame( false ) are functionally identical.
Change-Id: Ic5f1c7d504e7249002d3184520012e03313137b4
