We noticed the group="…" attribute was the only one that was not
trimmed. Does this mean it was possible to have two groups "a" and
" a"? It turns out: no. This was never possible because the parser
already trims all attributes before calling this code.
I tried to come up with the worst possible test case, but it succeeds,
even with very old versions of this codebase.
I suggest to remove the extra trimming from this codebase and rely on
what the parser provides.
Note the content is special and *not* trimmed by default.
Change-Id: Idff015447d7156ba7b5c03a5c423f199a71349f2
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
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
… and make the error message for bad dir="…" shorter and more to the
point.
Now I understand why the error reporting was not done when $text was
empty: the error was actually appended to $text, which messes with
everything else that also works with the $text variable! This even
includes the API. This error message was exposed via the API. That was
certainly a bug.
With this patch, all error checking for the dir="…" attribute is now
done way down, when rendering the <references> section.
Note this also fixes a bug where the dir="…" was *not* rendered when
previewing a section.
Change-Id: I4ab0cb510973ed879c606bfaa394aacc91129854
The use case we care about is this:
<ref extends="some_book"> </ref>
It doesn't make sense that works, but the following doesn't:
<ref extends="some_book"></ref>
We decided that both need to behave the same.
For consistency this patch is applying the same change to all references,
no matter if they use the extends attribute or not. This is an actual
change and might make existing wikitext render differently. However, I
would like to argue that all wikitext that was using this was broken. The
effect of a <ref> </ref> with some whitespace is that the <references>
section at the end of the article will contain – well – an empty footnote.
Bug: T237241
Change-Id: Iaee35583eabcb416b0a06849b89ebbfb0fb7fef9
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
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
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
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
This change does have two consequences:
1. A few more whitespace characters act as separators. This should not
have any consequence in real life situations, and is mainly done to
make the code easier to read and less surprising.
2. Sequences of two or more whitespace characters previously resulted
in partly *empty* results. This was a potential source of errors. The
additional + fixes this.
Change-Id: Ib58326109c740dd0cbd05d8fddb4af2145f232fe
Core sanitizes link targets and removes double spaces and underscores.
But the corresponding id="…" attributes are not sanitized the same
way. This results in broken links. This patch is not perfect (two
references with name="a_b" and name="a__b" will conflict), but the
best solution I can think of at the moment.
Bug: T184912
Change-Id: I9dbc916ad99269517d84c8ffb8581628d44a9f4e
Adding option for dir attribute in ref tags. The value must be a valid
direction ('ltr' or 'rtl', case insensitive) or the direction will be
stripped out.
The directionality of the li element is set using a css class accordingly.
Bug: T15673
Change-Id: Iff480bc8cc4f81403b310e8efecd43e29d1d4449
When using HTML5 ids, we need to take greater care to properly escape the
id (or derived strings) before passing them back through
Parser::recursiveTagParse().
Bug: T176170
Change-Id: I89a4f8ba24b867f2d5ccdc2bf9a4312ab9b385a9
This is based on the popular 'count' parameter from Template:Reflist on
English Wikipedia, which has also been adopted by many other wikis.
That template's 'count' parameter allows maximum flexibility on a per-
page basis. This was important because the template can't know how many
references the list will contain. Users typically manually add (and
later, increment) the 'count' parameter when the list exceeds a certain
threshold.
The template currently sets an exact column count (via the CSS3
property `column-count`).
This patch improves on that by instead using the closely related CSS3
`column-width` property. This automatically derives the column count
based on the available space in the browser window. It will thus create
two or three columns on a typical desktop screen, and two or no columns
on a mobile device.
The specified width is the minimum width of a column. This ensures that
the list is not split when rendered on a narrow screen or mobile device.
It also hooks into the raw list before parsing and adds the class only
when the list will contain more than a certain number of items. This
prevents very short lists from being split into multiple columns.
Templates like Template:Reflist on English Wikipedia currently are not
able to set inline styles on the list element directly, which is why
they set it on a `<div>` wrapping the `<references />` output. Because
of this, the feature of the Cite extension must not be enabled at the
same time, as that would result in both the template's wrapper and the
references list being split. The end result would involve sitations with
three columns split in four sub-columns, creating a complicated mess of
nine intermixed columns.
To provide a smooth migration for wikis, this feature can be disabled by
default using `$wgCiteResponsiveReferences = false`. Each individual
template createing reference list can then be migrated, by removing the
wrapper column styles and instead settting the new "responsive"
attribute, like so: `<references responsive />`.
Once any conflicting templates have been migrated, the default for the
wiki can be swapped by setting `$wgCiteResponsiveReferences = true`.
If wikis wish for some templates to keep their custom column splitting
behaviour, templates can also opt-out by setting `responsive="0"`, which
will make sure that it will keep behaving the current way even after the
feature becomes enabled by default for the wiki.
In summary, when disabled by default, pages can opt into this system
with `<references responsive />`. When enabled by default, pages can opt
out of the system with `<references responsive=0 />`.
* Deprecate cite_references_prefix/cite_references_suffix.
This message is rarely used and opens up compatibility hazards.
It was already removed by Parsoid, but the PHP implementation
still had it. It's typically used to add inline styles to the
wrapper which is more appropiately done in Common.css (or
obsoleted as part of the skin or Cite extenion itself nowadays
depending on what style in question).
It was also a HTML-style message with separated open and close
segments, which is an anti-pattern in itself.
* Declare module target explicitly and include mobile. The absence of
this stylesheet caused subtle BiDi/RTL bugs on mobile.
Bug: T33597
Change-Id: Ia535f9b722e825e71e792b36356febc3bd444387
