* parent::setUp() should be first, and ::tearDown()
should be last
* Move tests that directly extend PHPUnit\Framework\TestCase
to /unit
Change-Id: I1172855c58f4f52a8f624e6d596ec43beb8c93ff
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
LessFileCompilationTest is checking less files for valid syntax
doc test is checking xml file for valid syntax
MediaWikiTest is testing a complex situation with many functions involved
SideBarTest is self checking, needs no coverage
structure tests not covers functions, there are covers global structures
Change-Id: I3ac65db561cae0be8418aa9c830e7a9f46ad11fe
If a user creates a redirect that goes to a [[Media:example.jpg]]
page, then an exception is thrown because NS_MEDIA is a virtual
namespace. This change catches this case and changes the namespace
to an NS_FILE namespace and the redirect works correctly. This
change only happens when we are dealing with a redirect so other
uses of the NS_MEDIA namespace shouldn't be affected.
Bug: T203942
Change-Id: Ia744059650e16510732a65d51b138b11cbd43eb4
If the request URL was not normalized, for example having a double slash
in it, this could cause it to fail to match in the PathRouter. But the
canonicalizing redirect was using the normalized URL, causing a redirect
loop exception.
So:
* If the PathRouter fails to match with the original URL, try matching
against the normalized URL. This allows it to still work for
normalized URLs with a double slash in the title part of the path.
* Have WebRequest::getFullRequestURL() always return the URL without
removing dot segments or interpreting double slashes. Just append
the path to the server.
* Make MediaWikiTest.php use WebRequest instead of FauxRequest, allowing
it to reproduce the exception in question. Add relevant test.
* Add tests for the new PathRouter behaviour.
Bug: T100782
Change-Id: Ic0f3a0060904abc364f75dae920480b81175d52f
When jobs are being run synchronously post-send, we don't want to allow
bugs to result in a job somehow setting cookies or headers that
interfere with those that were intended to be set in the request.
Bug: T191537
Change-Id: Ib5714a17af417797140f99e41eaacbba1bfd20f4
Urls that use the page's title and no extra query parameters now redirect
to the standard url format.
Previously we only did this for variations of the title value (e.g. "Foo%20Bar"),
not for variations of the overall url structure (like title=Foo -> /wiki/Foo).
Existing redirect (unchanged):
/wiki/Foo%20Bar
/w/index.php?title=Foo%20Bar
New redirects:
/wiki/Foo_Bar?action=view
/w/index.php?title=Foo_Bar
/w/index.php?title=Foo_Bar&action=view
Any intentional (or unintentional) ways a url can be rewritten by the server,
such as "/?title=Foo_Bar" in case of Wikimedia, are redirected as well.
While this has been a problem for many years, it went unnoticed until
recently when Google started to index significantly more results of
the "/?title=<name>" form. This query returns "About 3,220,000 results":
https://google.com/search?q=site:en.wikipedia.org+inurl:title+-intitle:title
The only change in logic is that the titlekey comparison is now no longer a
factor in deciding whether to redirect. Instead the existing comparison for the
entire url is used to cover this.
However I kept titlekey comparison in the redirect-loop check as otherwise this
check would throw on all canonical page views where no redirect can be made.
Added a comment explaining how this redirect loop was possible.
Bug: T67402
Change-Id: I88ed3525141c765910e66188427b9aab36b958a9
This is in preparation for fixing T67402, which requires adding
logic inside this condition block. However the to-be-added code
will influences whether or not a redirect should be made.
In case a redirect is not made, it has to fall through to the next
'elseif' handler in MediaWiki::performRequest(), which is not possible
from inside the 'if' block.
Hence, move it out in a separate block and use a boolean return value
to communicate whether the case has been handled.
This also allows us to unit test this thing. Which is desperately
needed. Albeit ugly as it requires lots of mocking.
Change-Id: If3157f2ff1fd3ab2ca20a5d1f550d864ea62c493
* It serves no purpose, since to be useful we would need to propagate it to all to all objects called by the MediaWiki class
* It is in the wrong place; the MediaWiki class is an helper class for the index.php script, not the base class for the software (and the class could maybe even be renamed)
XmlJs:
- simple class == simple test
GlobalFunctions:
- wfArrayDiff2: simple test, please add more
XmlSelectTest:
- test for constructor
- tests for setDefault. Found a potential bug when setting a default after
options have been added. The default option will not get marked as selected!
We should change our code to generates HTML for options at rendering time
or throw an exception that default can not be used if an option is present.
MediaWiki:
- basic placeholder generated by PHPUnit
- tests for setVal() / getVal()
