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()
