extension.json only removes top level and "config" keys that start with
@, so this "comment" was actually being passed onto ResourceLoader and
eventually being ignored at that stage.
But since it's not a recognized value, it causes validation of the
extension.json file against the schema to fail.
Bug: T128311
Change-Id: Ibed94e1818c8fc9c3afdc3e09d0af5e84c49a342
* The query request prop=references will return a JSON blob of all
references in the page
* Conveniently references are returned with an array id key that corresponds
to an anchor tag in the HTML
* When references storage is disabled the API request will trigger an
error.
Bug: T123290
Change-Id: I81a965bcb47d17df18f1e415e3c25f88f6b48ffc
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
This merges the content of the LinksUpdateConstructed hook callback
into the LinksUpdate hook callback since it's fine to defer saving
to the cache.
Change-Id: Iad6008a31aaf659af3c560858df278335bc57c8f
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
Avoid unstubbing $wgUser during ResourceLoader actions by getting
messages in the language specified in the ResourceLoaderContext.
Bug: T127916
Change-Id: If4034ef7f5a98723cb8d526a067ddcc571a43b76
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
Clarified error message by changing it to "The opening <ref> tag is malformed or has a bad name".
Bug: T115810
Change-Id: I0c9cb8f5e81ebdb194c57f24a5792b682dd290dc
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
