There seems to be no reason for this to be a member function
Per suggestion of Ori, It should also be clearer
it is a getter so it is now prefixed with get
There are no consumers according to Github so a rename is safe
Change-Id: I414959d4cc107135ccbd0739f2fc7d62ca8d04c5
The two public functions ref() and references() are called from
Parser::extensionSubstitution(). Everything else is derived from that.
Change-Id: Ib9bb37ac0303f0e90149f5b1c4f4aa3bcf08b957
It can be both NULL and an empty string here.
Tests for both cases are added in the following patches:
Ia6c10419a7a92dac642db6ea21908927a5830b69
Ibb3bb1ab3450a34889dcd66b34542f2dd25fdc2b
Change-Id: Ia2b2b6545bb889de59a363a2c1d7569cbc971361
This uses a div instead of a span to wrap the section displaying
references in section preview. It also adds an id for the section
header specifically, and does not display the header if its message
is disabled.
Bug: T127188
Change-Id: If3df97319358706f7646f451ff2f4948537130e8
In the old caching system for references, the cache key needs the md5 of
the references, but it shouldn't be calculated when one is not using
this caching system.
Change-Id: I83c17d1df5c5e620ea21d1bf955b86ce94bc119a
This stores references in page_props during links update in
compressed JSON form. If the size is too big, it's broken up
in several parts to fit, which is very unlikely to occur more
than once.
When the data is retrieved from the db, it's always cached. If
set in config, it's also saved in the cache on parse. If not,
the cache is invalidated when references are modified.
Uses cases include : section preview to also show refs defined
elsewhere on the page (T124840) and MobileFrontend (T123328).
For the later, this still needs API support (T123290).
There's a soft dependency on the core change
I0c73b3d181f32502da75687857ae9aeff731f559.
Bug: T125329
Change-Id: I7b106254b8f264f93b0f0c9cfa89f65adeeea4f0
This is to make it apparent that this isn't part of the preview
of the section itself. A span class is also added.
Bug: T125981
Change-Id: I62c8dca8ee42e79c6b7cd7f837f4e7ee65f77770
Imagine the following wikitext:
<ref name=r/>
<references>
<ref name=r>A</ref>
<ref name=r>B</ref>
</references>
This is simple. Cite would see these as the following operations, in
order:
1. Use only: <ref name=r/>
2. References block
3. Define only: <ref name=r>A</ref>
4. Define only: <ref name=r>B</ref>
<ref name=r> is defined twice with different content and we get an
error message.
Now, imagine the following wikitext:
<ref name=r/>
{{#tag:references|
<ref name=r>A</ref>
<ref name=r>B</ref>
}}
Cite would see these as the following operations, in order:
1. Use only: <ref name=r/>
2. Use and define: <ref name=r>A</ref>
3. Use and define: <ref name=r>B</ref>
4. References block
When the 'references' block appears, Cite notices that the tag has
parsed content, and deduces that it was called with #tag. We need to
undo the last operations to update internal bookkeeping, as the last
two 'ref' tags do not actually represent ref usages, as we assumed,
but only definitions.
5. Undo: <ref name=r> reused
6. Define only: <ref name=r>B</ref>
7. Undo: <ref name=r> defined
(Right now, it appears to Cite that <ref name=r> was never defined!)
8. Define only: <ref name=r>A</ref>
Thus we get no errors, although we should.
This patch changes the order of the rollback operations:
5. Undo: <ref name=r> reused
6. Undo: <ref name=r> defined
7. Define only: <ref name=r>A</ref>
8. Define only: <ref name=r>B</ref>
Aha! <ref name=r> is defined twice with different content! We get an
error correctly.
Bug: T124227
Change-Id: I61766c4104856323987cca9a5e4ff85a76b3618b
For a section preview with missing <references/> tag,
add reference lists for each group.
Bug: T7984
Change-Id: I2ca1b62fc068b20b7df4b0af2e3e79535e656259
To make debugging easier when something goes wrong, display Cite errors
in the user language. This will fragment the parser cache, but since
these errors should be rate to not make this a problem.
Bug: T33216
Change-Id: I0f116f6da4b8f07b34f7d122458b6e23f542d468
For some reason there's an entirely separate function generating the
ref in this case.
This changes the behavior (in addition to adding the error message):
now the contents of the first <ref> with the same name inside
<references> are displayed, not the last. (This was already the case
for <ref>s outside <references>.)
Bug: T116377
Change-Id: I81b64ccd8a2e58f3b25938a63b8ad5967fe2a2c0
Follows-up c00cf4a which wrongly assumed the reason for empty()
to be about array count but the real reason was existence.
All other code in Cite extension already uses isset() so this
makes it match the rest.
Bug: T117084
Change-Id: Ic9b0d74ae6ceda5acba187c2fab18c8f5dc9526b
count() tends to be one of the slowest PHP functions and should be
avoided, especially if the actual number of elements is not needed.
Change-Id: Ia979c481f898d2fccedb0ed127417ef05ba7ff38
This value is supposed to be wikitext, which will be parsed later,
not HTML ready for outputting.
Follow-up to 6c59f47805.
Bug: T116149
Change-Id: I6d6f474db7c7a075499f94301978572179975749
Doesn't show an error for the default references group anymore. Only,
if a custom group was defined, but no corresponding references tag added.
Follow up: I9c7c13269d5ec355ccb280402aa8c0cedd208883
Change-Id: I67f4277b83b6b83ba5fc54cdcc021044b65f61c5
If a parser does not include the extCite property, ignore
the call and do not check references.
Depends on Ic77aa79aa6e2bf2a9ec00be4cc775d0123bed91a
Bug: T105598
Change-Id: Ic2257eef94fd73932f1e95a84b3b8b0eb245bafc
Restructure code to return early for errors instead of nesting
conditionals. This leaves the outer tree of the function as
the natural flow of the primary purpose.
Makes code more resilient by ensuring that new code added to the
function will not execute under error conditions by removing the
need to keep everything encapsulated in the various levels of
error conditionals.
Change-Id: I1b4a67d344fd9843ca088d008487914f87b1c640
This reverts commits 944b245428
and fa7be37d15.
These resulted in too many new exciting behaviors for the improvement
of nested refs behavior to be worth it. We should try again later.
Also, use Parser::MARKER_PREFIX instead of $parser->uniqPrefix()
which has been deprecated in the meantime by 12571bde.
Fixes T101390, fixes T100477. Reopens T22707, reopens T18330.
Bug: T100477
Bug: T101390
Change-Id: I1a71854cf24e85697ab171be43eeec9054bc504c
Move the JS which is purely for accessibility purposes into a separate
JS RL module named ext.cite.a11y. Move all pure CSS, which is not dependant
on accompanying JS into a separate ext.cite.styles module
Bug: T101559
Change-Id: I58adcfbcf9af2bb3b6d5dabb6c38c42af78e0416
It's possible that the output type is set to HTML when extensionSubstitution
is called, but that when we eventually get unstripped, it isn't anymore. If
this happens, detect it and bail out.
Bug: T99787
Change-Id: I32abaefeebc5357a2ab3fd23bcd47aa9b2a1663a
Cite has side effects that currently happen at the same time that the
preprocessor is running. This can cause oddities like references being out
of order, or references showing up in the reference list but never used in
the text. By moving the work to unstrip, only references actually used in
the final text will be present, and the numbering order will always match
the order they were used in the text. This depends on If83b0623 in core.
Change-Id: I0e136f952302b65f1abeeac5273bd842867e1dac
As of Icdf82cb9771e6, MediaWiki core now looks for the "Cite" class
instead of the "wfCite" global function. The WYSIWYG extension is also
checking for wfCite and a patch was submitted for that in I3de3e069e4be.
Change-Id: Ie0f190b7bd9c9226856f150c95a0b139812dcf98
From prod error logs:
Undefined index: 0 in Cite_body.php on line 396
Undefined index: 1 in Cite_body.php on line 396
Undefined index: 2 in Cite_body.php on line 396
Undefined index: 3 in Cite_body.php on line 396
Undefined index: follow in Cite_body.php on line 396
Change-Id: Id727f2fd7e72d8c4ceb74fdac42885d5c030b4af
The coding conventions suggest avoiding ==,
and for this condition definedness is actually more relevant
than whether the string has any text, but since
the string can also be '0', checking for !$text doesn't work.
Similar to I15b422d3345bf4522e68a17dce9682ff28484559 .
Change-Id: Ib823678b639bf4f1a92dffcd9e41c780b56ab128
The coding conventions suggest avoiding ==,
and for this condition definedness is actually more relevant
than whether the string has any text.
Change-Id: I15b422d3345bf4522e68a17dce9682ff28484559
In this function $text can be both false and empty string.
It is more intuitive to use a boolean operator here than
to rely on the fact that comparing to '' using == happens
to give the correct result.
Change-Id: I08248a3fcade7744287e9b9f3bc176d29ac1ecde
We've had Parser::recursiveTagParse since MediaWiki 1.8, back in 2006.
Remove code that only gets used if it's not available.
Change-Id: I76eed5570a675a14cf70ab10981661e0bc8bda99
