A number of tests have hardcoded expections that pass only in WMF CI
where Quibble has LocalSettings.php with $wgScript and $wgArticlePath
set a certain way.
We could fix these by adding setMwGlobals() in their tests, as we
often do, but these are so often forgotten that I'd rather we just
add them to TestSetup.php so that it is simply impossible to write a
test that that passes locally for you (if you have the same config)
but not for someone else.
There is a larger project in there somewhere about expanding this
slowly such that we basically only pluck DB-settings and extension
enablement from LocalSettings and otherwise run the tests with the
default settings in PHPUnit. Pretty much by definition, any (other)
setting you have in LocalSettings is irrelevant because it either:
1. has no effect on the test (majority, harmless either way),
2. has a custom default via TestSetup.php (which has precedence over
LocalSettings.php),
3. is relevant to the code being tested and the test case correctly
calls setMwGlobals() to ensure a consistent value during test.
4. is relevant to the tested code but has no override, thus only
passes if you happen to have the "right" value set for it
(undesirable).
Case 4 is already categorically impossible for the most common config
settings that influence random code because we give them a value
in TestSetup.php. This patch expands that to include $wgScript
and $wgArticlePath. Perhaps in the future we can think about a way
to do this automatically by either re-applying MainConfigSchema
(sans db settings) or by only selectively applying LocalSettings.php
in the first place.
This patch follows-up I072ddf89562fe, which added a test case in
WikitextContentHandlerIntegrationTest.php that assumed "/index.php"
as the value of $wgScript. This passes in WMF CI since Quibble uses
that value, but the tests failed in most local development installs
since those tend to use "/w" instead.
Rather than one-off fixing that one test with overrideConfigValues(),
switch to a more general fixture, since the precise values don't
matter for this test.
Bug: T349087
Bug: T277470
Change-Id: If4304b7ca4a838bd892d4516a0b5c6dfbc30986e
We already depend on this behavior in IndexPager::getNavigationBuilder(),
but it wasn't allowed by the type hints and wasn't covered by tests.
Change-Id: I9343e852dc4610a50adf1c22ed429ec0a40da816
Follow-up to Ic75bd597b210e14612ca3aebb531b659897e8294.
No longer needed after I161dc0159e4372e3478341ee3fbea13b723d9fc1.
This is a public method, but it has not been included in a release
yet, so we can remove it without deprecation.
Change-Id: Ie5eea4d3423136812178747e187771e7cf78e95f
We had several implementations of almost identical paging links:
* PrevNextNavigationRenderer: The nicest one, somewhat recently added
(4ca72763ec). Unfortunately it was also the least featureful: only
supporting paging by numeric offset and not by index, and not able
to generate "first"/"last" links. Also, I didn't realize that it
exists when working on 94553a1bcb and b95d208340, so it was missing
those changes too.
* IndexPager/ReverseChronologicalPager/AlphabeticPager: These have
been here forever. The most featureful, but not configurable, so
a large part of the implementation was copy-pasted in two classes.
* SpecialWhatLinksHere: Through some accident of history, this one
special page ended up with its own implementation???
They are all replaced to use the new PagerNavigationBuilder.
It may be slightly too much, but I had fun writing it.
Notable changes compared to PrevNextNavigationRenderer:
* Adds <div class="mw-pager-navigation-bar"> wrapper around the
navigation and <span class="…"> wrappers on inactive links
* The current limit link is made inactive
(like the "prev" link when on first page, etc.)
Notable changes compared to ...Pager/...Pager/...Pager:
* Does not generate useless tooltips that contain only the
title of the page, can use custom tooltips
* The current limit link is made inactive
(like the "prev" link when on first page, etc.)
* All links have query parameters in a consistent order:
?title= &... &dir= &offset= &limit= (some of them are optional)
These changes affect many special pages and actions. I tested on:
* Special:Contributions (ReverseChronologicalPager)
* action=history (ReverseChronologicalPager)
* Special:Categories (AlphabeticPager)
* Special:WantedPages (PrevNextNavigationRenderer)
* Special:Search (PrevNextNavigationRenderer)
* Special:WhatLinksHere
Bug: T308364
Change-Id: Ic75bd597b210e14612ca3aebb531b659897e8294
