If there is an error when executing the method under test, then this
test caused the downstream test \remoteapicore_test::test_getBacklinks
to unexpectedly fail. Probably, because the global plugin controller
would not have been reset to its original value.
Running this test in its own process ensures that it won't affect any
other test, even if it messes with the global state and doesn't clean up.
On PHP8 trying to access a non-existing array key leads to a warning,
which we might treat as errors?
This incidentally also fixes another test downstream which broke because
this rendering test changes the global plugin controller, but doesn't
clean it up that if the test errors.
-9000 is used as the position to make it obvious that this number is
meaningless for this test.
This event seems not to be used by any plugin, which explains why this
bug hasn't surfaced yet. Access is always checked against a full method
name in the form of plugin.<pluginname>.<method> Such a full method was
not passed when using an event as described in the documentation.
* master:
dwpage: output meta data as JSON
dwpage: rename gmeta into getmeta
translation update
Make it easier to remove h1 around logo
fix: better max-width for images in tables
dwpage.php: add an option to get metadata
rename namespace Media to File
use SVG icons for media file links
readded $jump mechanism, removed unused functions
fix use of $rev parameter
fix entity definition
reenable the option to display a relative namespace for media files
simplified the media_searchlist tests
make use of the new media file classes
SVG based file icons
first go a refactoring the media manager
lazy load images
On windows systems a file can not be deleted while processes still have
a handle on them. JPEGMeta seems not to close its file handle correctly.
Usually thats not a problem in short lived processes where everything is
garbage collected at the end, however within a test request the object
may live on a little longer causing problems.
This adds a class to the h1 around the logo
and changes the CSS to reference that class
instead of the h1.
That way it's easier to change the h1 to a div
if someone prefers to have not more than one h1 per page.
This error only occurs when PHPUnit runs both the `testScripts` and the
`test_Validity` suites [1], because all tests are running in the same
PHP process.
Adding an `if(!defined` check to avoid the problem.
[1]: ./phpunit.phar --filter 'testScripts|test_Validity'
There are actually 2 distinct test cases of invalid methods:
1. Not following the definition in Api class's PHPDoc block
- core methods begin by a 'dokuwiki' or 'wiki' followed by a . and
the method name itself.
- plugin methods are formed like 'plugin.<plugin name>.<method name>'
2. Method "type" does not begin with 'dokuwiki', 'wiki' or 'plugin'
A new check was added so both are now covered.
Test was modified to make use of PHPUnit expectException() method,
instead of relying on a try/catch block.
The following files should not be checked in:
- phpunit.phar: per documentation [1], it is PHP version-specific
- PHPUnit's cache file
- data files generated during tests execution
[1]: https://www.dokuwiki.org/devel:unittesting
Gerrit Uitslag