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
This code has been developed over three years now in the repo of MediaWiki's
integration of VisualEditor. It has grown and developed significantly during
that time, but now is pretty stable. A number of hacks inside the MediaWiki-
VisualEditor code base have been used to prevent this code from being loaded
on wikis where the Cite extension is not deployed, but this state of affairs
is and always was meant to be temporary.
This code is under the MIT licence which is a tad messy, but not impossible.
It's clearly labelled as such. The list of authors has been updated to take
into account the influx of new functionality.
Bug: T41621
Bug: T104928
Change-Id: I39936ed83d5a60471a0a75da753f498e80aef234
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
Update grunt-banana-checker to 0.4.0
Update grunt-jsonlint to 1.0.6
Update grunt-jscs to 2.5.0
Also support looking into sub folders for jshint and jscs.
Also fix some js code so
Replace
} ) ( mw, jQuery );
with
}( mediaWiki, jQuery ) );
Also remove a blank message that should not be there in gu.json
Also remove two blank messages in tl.json.
Change-Id: Ib8390de6fd6adfc4a9ad22c48c7872aac332d4ae
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