Note this codebase appears to be dual-licensed. Some files mention MIT,
but extension.json and some other files mention GPL.
Since WMDE typically uses GPL, I will continue to mark the files we
created as such.
Change-Id: I126da10f7fb13a6d4c99e96e72d024b2e5ecee06
The main motivation here is to cover the fallback code that was moved
in I20c814d. At some point we might touch this code again.
Bug: T238194
Change-Id: I0ab8a34b09790f42b10376eb3730c3b3c4ef53d2
1. Most existing CiteTests can be unit tests. They run so much faster
this way.
2. I modified some test cases to cover all trim() in the code.
3. The strict type hint in CiteHooks is removed because the parameter
is not used. Having a hard type hint for what is effectively dead code
makes the code more brittle for changes done outside of this codebase.
Change-Id: I1bff1d6e02d9ef17d5e6b66aeec3ee42bba99cf4
This fixes a series of issues:
* There is nothing about a "frame" in the Cite class any more.
* There is no addModules() call in the Cite class any more.
Change-Id: I20c814d46c26825c5c07eab0a5586de3a531eee7
To be honest I don't get why this lazy registration was done in the
first place. None of the 4 other hooks should ever be called before
the ParserFirstCallInit hook got called.
Also, under which circumstances can the ParserFirstCallInit hook be
called more than once?
Both scenarios would be wrong, as far as I'm concerned. Either I'm
missing something, or this code can indeed be simplified. Maybe it was
something to make it more compatible with older MediaWiki versions?
The only reason I can think of is: in all situations that do not
involve a parser, having the 4 extra hooks registered is pointless.
Does this waste space and/or runtime in the $wgHooks registry?
Change-Id: I5ef1495f4ce7bce940fa5f8e700af3d2c4851a01
Can use a shortcut where we pass the expected value directly. Verified
that we're still asserting equality.
Change-Id: I63512488c50e599df23d5dae2a5064218e311e90
Note it doesn't make a difference if this is behind the feature flag or
not. It should always be forbidden, and in fact is: Either the follows
attribute is unknown, or the combination is forbidden.
Bug: T236256
Change-Id: Iebbb2d1d5bab183ab0590b8a7a7f6e79d319b72c
What we find critical is:
* That all tests relevant for book referencing are in a separate file.
* That unimplemented stuff is marked with TODOs.
Not having to move tests to another file allows for nice diffs.
I tried to order the tests as good as I could. E.g. have all tests with
a group="…" next to each other, followed by all with a follow="…".
Change-Id: Idc1d9e7843b341235ab3d8ebe398e01946eb1845
Any time the book referencing attribute is used in a page,
permanently tag that page with the `ref-extends` property, so
that it can be watched and cleaned up if necessary.
Bug: T237531
Change-Id: Ice5d9d8f7a305702cdc7c2a55d4147c4f79b5881
Incremental patch which extracts the refines attribute from the tag.
Doing this now to allow the calling function to have responsibility
for doing something with the attribute value.
Bug: T237531
Change-Id: I59bb409bedd8e6ed06268e705e02e8ffb45b1f0e
Encapsulate the feature tests in dedicated files. These are picked
up by the test runner for matching glob `tests/parser/*.txt`, as can
be shown by,
phpunit.php --testsuite parsertests --filter=bookRef
Also adds TODO comments to some tests, documenting how the current output
will not match the fully implemented code's results.
Bug: T236256
Change-Id: Ie3e769c84856256180754aeff417da893a84b479
These tests document the current status quo, and are meant to change
with every patch that makes the code for refined references more
feature complete.
Bug: T236256
Change-Id: I8c11b1decc36b86e7f7d1919cc39d0c16a200055
Note this is intentionally testing a private method. As of now, the
code is so heavily entangled, it's not yet possible to test individual
aspects without calling private methods. The plan is to slowly increase
the overall test coverage, and the start restructuring the code as
necessary.
Change-Id: Ib3b01bddaffd0469fb66979c67c8114a5807df6d
Allows the "refines" attribute when the feature flag is set, but doesn't
render. This is part of our rollback strategy, so that we aren't left
with invalid wikitext in case of undeployment.
Bug: T236257
Change-Id: I936be0e62dccb46caeb84162d2c5166956fd9916
This change allows to change the editsection HTML by
I305e3313ca2f931a2ea9cee34194b8cb93b90b0e without failing in Jenkins.
The parser test gets restored in the new format by the follow-up change
Ibb4341b405f0d6fa6883c992c5dd3a9e594c9efc.
Change-Id: I337d7f7c0cd134a3766343565e2c30edf1d70f7e
Adding a step to wait for loaded modules. This was manily taken from
the Popups-extension browser test, but with a fixed chain for the
results.
Let's hope we do not need to pause with this.
See as well I274bdee0b3c39c418a2b61881d56f89889c53485
Bug: T220318
Change-Id: I5bdc1951a23a51e9a4deea69af2bfc96843f5a1d
We can resolve this bug by either replacing the bogus "return false"
with the intended "return [ false, … ]". Or rely on the code a few
lines below that also bails out with a "return [ false, … ]" when to
many parameters ($cnt is not 0 then) are present. The tests prove both
solutions are equally valid.
Bug: T211576
Change-Id: Iadd55c134dede7042cfd152c69bc8f27b59d8912
This is split from I642d38e and does nothing but adding test cases
that document the current (broken) behavior.
Bug: T211576
Change-Id: Iee313d26e7bed6deb34101e37736a1c697947905
