This avoids the use of Parsoid's SiteConfig::getMWConfigValue() method,
which is unnecessary when the extension has direct access to MediaWiki
services itself.
This also fixes the omission of CiteResponsiveReferencesThreshold from
the extension.json.
Change-Id: I01b43136b0827f185523f1318253372b09750de4
This seems to play well with Popups with and without
Ie8fa1672b9fd . However, it's not clear to me why this still works
and even gives priority to the Popups implementation when present,
regardless of the order the extensions are loaded in. Happily, this
is the desired behavior.
Bug: T363162
Change-Id: Ic479c0a381ee16d1abcecfdd5ee48f0afccc1d3f
This moves existing code around a little bit without changing
anything, as proven by the tests.
This is motivated by Iaca0e14.
Change-Id: I30366d32b07f87f238b045f0d7817686b5cc26bd
It's always a string anyway. Also improve the test coverage. The
localization was pretty much untested before.
Change-Id: Ie6f34c67ae7dd9559346eb45a2604e14c5633991
The main benefit is that this makes it more obvious what is actually
under test, and what's not.
This is mainly motivated by the ongoing work in Iaca0e14.
Change-Id: Icbf1b824ba1f5468dbdb30445134db2b568e19f8
The message cite_references_link_many_format_backlink_labels contains
e.g. "a b c …" and so on, to be used as alternative backlink labels
when a single reference is re-used multiple times. The default numeric
rendering is "1.1 1.2 …" and so on.
The two labels end in the message cite_references_link_many_format as
parameters $2 and $3. But only one of the two parameters is ever used.
By default the alternative label in $3 is unused.
This implies that everything about these alternative backlink labels
including the error message is effectively dead code most of the time,
never to be seen on the majority of wikis.
This change makes it possible to disable the message without breaking
anything. Instead the code will silently fallback to the default
behavior of showing the numeric label. This is much more efficient
than rendering possibly hundreds of error messages that never show
up anyhere. The same optimization is already done for the extremely
similar cite_link_label_group-… messages, see
FootnoteMarkFormatter::fetchCustomizedLinkLabel.
This is also partly motivated by T335129 as well as T321217.
Change-Id: Iab818d7db7eddaf7091234f6a22a18cdff70f8e8
This is a direct follow up for I6f05842 where we already started
supporting dashes, but converted them to underscores. The only change
in this patch is that the CSS class will use the message key as it
is, without the dashes being converted to underscores. I added a test
case specifically for this.
Bug: T352676
Change-Id: Ic22e897c27b8371e3b1ed63932b619e7af71bd5c
In some tests we want to see the message parameters. But not here.
Simply echoing the message key (thats parameter number one) is
enough.
Change-Id: Id9824cbbe944c84c9fd1932b0863ac1b3f232b75
I think this was just a mistake in I5457304 when this test was
written. There was never an ->exists() call in the code, as far as
I can see.
This is motivated by our ongoing, probably year-long efforts to
clean this codebase up, see T335129.
Change-Id: I72d89213c5cff06d78ac119b3c79827afbd0b4f5
Whether the dynamic property is present or not, it should have a null
value when 'unset' -- and don't use `unset` to delete an *actual*
property when one is present!
Change-Id: Ifcb9492cc5c814d702c6e61e8231abfd8ea0647c
This does the exact same as the previously used generic stdClass
object, just strictly typed. Turned out to be surprisingly
straightforward, as proven by the small size of this patch.
I'm intentionally not adding anything new in this patch. For
example, the new class is perfect to write longer documentation
for every field. But this is for a later patch.
Change-Id: Ibf696f6b5ef1bfdbe846b571fb7e9ded96693351
There is much more to test, but it's a start.
Intentionally build as pure unit tests to make them as fast as
possible.
Bug: T354215
Bug: T358652
Change-Id: Iae1a8086b8f2b9e5b11e0117bd3f19fdaa087df0
The information read from the …cite-tool-definition.json files is
effectively user input, even if only interface administrators can
edit it. Usually we carefully validate user input. But as of now
this code starts failing with all kinds of uncatched errors.
* An entry with no name, an empty name, or a name that's not a
string will cause all kinds of undefined behavior.
* An entry with an empty title results in an invisible button.
* A missing message results in a technical <…> placeholder, even if
the name is usually a sensible fallback.
Note that hard-coding titles as plain text strings in the ….json
file was already possible.
Change-Id: Iddcedbe859e86ac4c3f79a53d36237daff86c0db
I always found the name a little ambiguous. The fact that it outputs
an actual HTML list and not just some "references" – whatever that
means – is relevant, in my opinion.
Change-Id: I0d169455c8d2b42d62da4dccb8376c09fb6902bc
… as well as "cite_warning". Both are extremely trivial and don't
really do anything by default. All they do is to add the prefix
"Cite error:" or "Cite warning:" to all error messages.
This patch will make it possible to disable both messages by
default, i.e. replace their default in en.json with "-" without
breaking anything. That's part of the plan outlined in T353695.
Local on-wiki overrides will continue to work.
Bug: T353695
Change-Id: I374800d0d0b837cd17ed3a1fdde20b70325b06de
This was slightly overengineered ever since I4b1f890 and slowly became
more and more complicated over time, notably when withConsecutive was
replaced in Icb951b4. Turns out this was never really needed. It's
impossible to get more than one tracking category from this code path.
While we might add more tracking categories later that will most
probably not happen in this code path.
Change-Id: Ie32d17bac8d3518c985b18f83a846c3fb2bd053f
This encapsulation gives us field name, type validation and code
documentation.
This patch only affects ReferenceStack and continues to return
approximately the same array outputs to callers. Some additional
information is included and the placeholder column has a new name.
Bug: T353451
Change-Id: I405fe7ac241f6991fd4c526bfbb58fbc34f2e147
The previous patch deprecated the last conditional depending on magic
meanings of 0 and -1, so now we're free to let "count" take on a more
natural meaning: the number of times a footnote mark appears in
article text.
Includes a small hack to avoid changing parser output, by
artificially decrementing the count by one during rendering. The
hack can be removed and test output updated in a separate patch.
Bug: T353227
Change-Id: I6f76c50357b274ff97321533e52f435798048268
Stop relying on the magic number distinction between "count" = 0 and -1,
by explicitly testing the "name" field instead.
Bug: T353227
Change-Id: I9dce16b01814e19f508d45b927de570049f0e0f5
Encapsulate all information about a ref inside of the internal
structure, rather than relying on the container to be organized by
group.
Bug: T353451
Change-Id: I4c91e8089638b7655bf120402a4a5fcbd1b35452
These fields get automatic values during normal operation, but we
should make this explicit in tests which meddle with internals. This
seems to add some clarity, and helps prepare for encapsulation.
Bug: T353451
Change-Id: I8b012a270f16139671f77ea04645d627b2fba87d
In this case, there was never a ref with this name in the article so
no backlinks should be rendered.
TODO:
* test case with empty parent backlink and LDR parent
Bug: T353451
Change-Id: I8a7abd05a48ce83da3beb92b15e894d53252bd33
Testing internal methods is brittle. This code path is already
covered by parser test "Valid follow="…" after it's parent"
Bug: T353451
Change-Id: I3b7a4b9962de1f25a7b57f82d80813219d633594
Check out how this gets rid of so many "to do" as well as
"deprecated" comments.
Next qustion: The elements in the stack become more and more
complicated. It's probably worth converting them from arrays into
first-class objects. But this is for another patch.
Bug: T353266
Change-Id: If14acd1070617ca8c4d15be6b1759bd47ead4926
For example, use convenient upstream methods, and generally make the
test setup a bit more readable.
Bug: T353227
Change-Id: Ifab71041fcc3f804315793ca7b783f84829c7a0f
Same arguments as in Iafa2412. The one reason to use more detailled
per-method @covers annotations is to avoid "accidental coverage"
where code is marked as being covered by tests that don't assert
anything that would be meaningful for this code. This is especially a
problem with older, bigger classes with lots of side effects.
But all the new classes we introduced over the years are small, with
predictable, local effects.
That's also why we keep the more detailled @covers annotations for
the original Cite class.
Bug: T353227
Bug: T353269
Change-Id: I69850f4d740d8ad5a7c2368b9068dc91e47cc797
