These exist two times, one time in the unit/ folder as a unit test, and
another time in the parent folder as an integration test. This confused
me already several times.
Change-Id: I147b8af8a7edba2582496468b4878faecc6d8110
Functional changes:
* hasGroup() will return false when a group exists, but is empty. This
is in line with what other methods like getGroups() already do.
Shouldn't have any effect on the existing code, but feels more clean
and consistent.
* getGroupRefs() won't fail any more when asked for an unknown group.
Tests:
* Add missing @covers for the constructor.
* Simplify test setup by always returning a spy. All tests need it
anyway.
* Cover 3 more methods.
Change-Id: Ie93e9af6258b757d842b30b0b059344733aad434
That was annoying me. Since we're passing a bare list, alphabetical
order helps make the code and tests readable.
Change-Id: I6384094e429e0e2a6fa810fdc28ae0643a0ccf7c
This is invalid, because it would allow access to internal, autoindexed,
anonymous refs. These would break when refs are reordered.
Bug: T151305
Change-Id: Ib4bb8270d810b64e4c160f377ce52ce2fc70bab4
This introduces a slight behavior change, but for the better:
* When pointing to the name "0", the non-numeric error will be displayed,
which is correct whereas "no key" is not.
Change-Id: I33467b27cd447812fe67204831909c4d9869db08
Validation logic can be split from arg parsing, default values and
other side-effects.
No behavior was changed.
Change-Id: I2d9904b7631d0d6be13e0aaed0106f186d388c4f
Most of this state is used to manage interactions with other state,
and encapsulation allows us to hide data structures and access behind
self-explanatory function names.
The interface is still much wider than I'd like, but it can be improved in
future work.
There is one small behavior change in here: in the `follows` edge case
demonstrated by I3bdf26fd14, we prepend if the splice point cannot be
used because it has a non-numeric key. I believe this was the original
intention of the logic, and is how the numeric case behaves. I've verified
that when array_splice throws a warning about non-numeric key, it fails to
add anything to the original array, so the broken follows ref disappeared.
Bug: T237241
Change-Id: I091a0b71ee9aa78e841c2e328018e886a7217715
This partly reverts commit 8e42a6ecdf.
The variabe $k as created by the foreach() loop is not necessarily
numeric, because the $this->mRef structure contains data both for
named and unnamed <ref>s. The array key is a (non-numeric) string for
named, and an integer for unnamed <ref>s.
array_splice() requires a position, not an array key.
Note that both implementations are wrong. The foreach() might return a
string $k, which makes array_splice() complain and do unwanted things.
The for() loop assumes there are count() array elements with integer
keys, which might not be true. Luckily this was not a problem, because
the isset() check would stop the (to long) loop eary enough.
A better rewrite as well as a test case for this will be added with
I3bdf26f.
Change-Id: I5568d3084197f1861f9dc8983d8b606a961e201f
I realized especially the method name html() was wrong. It does not
return HTML. What it returns is still wikitext and must still be parsed.
It only applies some early steps of the parsing process, e.g. expanding
extension <tags>.
Change-Id: I2c403a77eef843940f34f0933e4bfe58e6200ce5
* This fixes the refArg() function. If there is nothing wrong with the
follow="…" attribute, it should not return null.
* However, *everything* is false if an unknown error (e.g. an unknown
attribute) occurs.
* A trivial check for `if ( $follow )` is fine because all keys are
guaranteed to not be the string "0".
Change-Id: Ia4e37781e01db1ee6615ffc30bb68e47023c6634
There was another, duplicated special case for previews. It was using
the same message as a <ref> with multiple uses. Now it's only one code
path.
The goal here is to reduce the number of code paths to make it much
easier to implement proper rendering for the extends="…" use cases.
Bug: T237241
Change-Id: I863ac3b5234d3a6f7f2371a2a85385c3aea276e5
One of the test cases was duplicated, but a lot of the possible code
paths never had tests, including the happy code path!
I found this issue while trying to rework some of the more confusing
loops in this codebase. These changes are still part of this patch. All
loops still do the same as before, but are (I hope) more readable now.
Bug: T238187
Change-Id: I85baeadd9b149025a14c7522bcc4182339c66972
