I would like to argue that calling the current state of this codebase
"version 1.0.0" is plain wrong. A more meaningful version number can
easily be introduced later if one is needed.
Bug: T213066
Change-Id: I4854263592784feb072acea2d9efe99f1f04ab28
Only create a Cite object if we need one. Never clearState, just
destroy and recreate later.
This makes it less likely that we leak state between parsers, and
saves memory and processing on pages without references.
It's also preparation to decouple Cite logic from state.
Change-Id: I3db517591f4131c23151c76c223af7419cc00ae9
I was able to track this code down to I093d85d from 2012, which was done
right after the ParserAfterParse hook was introduced. I believe the
redundant code path was left to keep the Cite extension compatible with
old MediaWiki versions that did not had this hook yet.
I also noticed this code path is most probably entirely redundant with
the current version of MediaWiki. The *only* thing this code does is
blocking the ParserBeforeTidy hook from doing the same thing a second
time if the ParserAfterParse hook was called before. But it does *not*
block any other compination, e.g. if the two hooks are called the other
way around, or the same hook twice.
In core, it looks like it is impossible for the ParserBeforeTidy hook
being fired without the ParserAfterParse hook being fired before. If this
is true, this is in fact dead code.
Change-Id: Iacf8b600c7abdeaf89c22c2fc31e646f57245e47
This API was never used in Wikimedia production, and would have caused
performance problems. Removing the dead code will simplify our refactoring.
Bug: T238195
Change-Id: I7088f257ec034c0d089e0abdaa5a739910598300
This patch does intentionally not touch any file name. Some of the
file names are a little weird now, e.g. \Cite\Cite. These can more
easily be renamed in later patches.
I used https://codesearch.wmflabs.org/search/?q=new%20Cite%5C( and it
looks like this code is not used anywhere else.
Change-Id: I5f93a224e9cacf45b7a0d68c216a78723364dd96
To be honest I don't get why this lazy registration was done in the
first place. None of the 4 other hooks should ever be called before
the ParserFirstCallInit hook got called.
Also, under which circumstances can the ParserFirstCallInit hook be
called more than once?
Both scenarios would be wrong, as far as I'm concerned. Either I'm
missing something, or this code can indeed be simplified. Maybe it was
something to make it more compatible with older MediaWiki versions?
The only reason I can think of is: in all situations that do not
involve a parser, having the 4 extra hooks registered is pointless.
Does this waste space and/or runtime in the $wgHooks registry?
Change-Id: I5ef1495f4ce7bce940fa5f8e700af3d2c4851a01
As of now, this patch does not touch the existing code. However, the
goal is to remove a lot of the related code from the Cite class. This
will be done in later patches. This here is a separate patch to make
reviewing the later patches much easier.
The existing parser tests should be proof enough this chain of patches
is not changing any behavior.
Change-Id: I27ae972f81071bb4036bd452560768fae409417b
All other hook handlers are in the dedicated CiteHooks class.
Main motivation here is to make the huge Cite class smaller,
especially by removing static code that does not rely on anything
else the class does.
Bug: T236260
Change-Id: If0b3f6c989e44283428cda4b2c4d8d5303385d22
Main motivation here is to make the list easier to read. We are not
going to have more than a single hook handler per hook anyway.
Bug: T236260
Change-Id: I72357a89402e6febfa1e99f825a3fd699c5561b7
There are so few users with this configuration that we need to stop
sampling in order to get data. Sampling is still in effect for
"baseline" users with the feature disabled.
We use separate schemas to simplify analytics on the two populations.
Bug: T214493
Change-Id: I16e4ed236e50e1e246ff28ff0dba3e52e4b56caf
This is a rebase mistake introduced with I7461ffd. Since If83420a this
module is not defined in extension.json any more, but in the
ResourceLoaderRegisterModules hook in PHP. This is done to be able to
dynamically change the contents of the module, depending on the
availability of anotehr extension.
I'm not exactly sure what happens when a module is defined twice. I
tried locally and it seems to work, with no visible error message.
Bug: T234605
Change-Id: I209e19bbc2184a6d58086a703145ad58671060b6
As stated in the patch I26fe41c: "The separate ext.cite.a11y module
is kept for (temporary) compatibility with cached HTML, and should be
removed in about a month." That was almost a year ago.
Bug: T205270
Change-Id: I7461ffd61bea0b79a56b6ee9ce8315f5f6c39b7b
Collect EventLogging metrics for footnote and reference link
interactions, so that we can compare behavior with and without
Reference Previews enabled.
This tracking will be reverted once analysis is complete.
A mostly arbitrary sample rate of 1/1000 is hardcoded here. This is
loosely based on the latest tuning of Popups sampling at 1/100,
divided by a conservative factor of 10 to ensure headroom.
The sample is skewed by skipping clients without sendBeacon support,
but we're avoiding the mw.track synchronous fallback, which injects an
image tag and introduces lag any time the user clicks external links
in the references.
Bug: T231529
Change-Id: Iad32b64114f88675eecbb01712418c968e3cf661
There are multiple formats for these IDs:
cite_ref-1, cite_ref-2, and so on for anonymous <ref>s without a name.
cite_ref-name_1-0 for named references, where "name" is the custom name,
and "_1" is the sequential number for the reference (same number as above).
The final "-0" is counting the usages. If a named <ref> is only used once,
there is no cite_ref-name_1-1 anywhere on the page.
The later was already checked by the code. But we forgot about unnamed
references! As a consequence IDs like the cite_ref-1 above got misdetected
as reused references.
This patch tries hard to extract code into named functions, so it becomes
much more clear what they do, and why.
Bug: T215317
Change-Id: Iedb5b0c3dffae19bad7df9a43ed2d4512b3921ec
This changes the a11y support on the main backlinks by introducing the usage
of title and aria-labels. The support for these elements increased a lot since
the topic was first tackled and seems the appropriate way to go.
A new message was introduced for the link that will be set when directly
coming from a clicked refrence to emphasize that the can jump back to where
he came from.
Bug: T206323
Change-Id: Ifa56d41bcdb8100e19f29619796b62bb3c886d2f
The separate "ext.cite.a11y" module is kept for (temporary)
compatibility with cached HTML, and should be removed in about
a month.
Browser tests will be added in a separate patch.
Bug: T205270
Change-Id: I26fe41c328157233cc5b06d38d2ba0f7b036a853
This allows on-wiki use to be migrated to the standard icons rather than
in-repo ones, so that they can (later) be removed.
Change-Id: I19bec075c77396f163977962bbe1afb69a231c1e
This was briefly enabled in WMF production in 2009 and found not to work.
As far as I know, it's been disabled since then. Retaining it requires
maintaining the complex "half-parsed serialization" feature in the core
parser, which I'm deprecating in I838d7ac7f9a218. The core feature was
added solely to support this Cite caching experiment and is not used for
anything else.
Change-Id: I446e0c46913a390dbdf7b49b84040bf47ed6c2f9
SPDX released version 3 of their license list (<https://spdx.org/licenses/>),
which changed the FSF licenses to explicitly end in -only or -or-later
instead of relying on an easy to miss + symbol.
Bug: T183858
Change-Id: I77bf3f7910b083ff8a09ebc4c556ab60f500803a
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
Current Minerva skin is purposely restricted to 55.8em
This means references will never be split into 2 columns as 30em*2=60em.
Dropping it to 25em would mean the CSS applies here and no more than 2
columns would ever be used to display references.
Bug: T160497
Change-Id: I6f9b85cd6cfdb055692b1f537d569c158900f7c9
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
When VisualEditor is not installed, there is no point in registered
resource loader modules that depends on it. A use case is trying to run
tests for the MediaWiki tarball. It comes with Cite but without
VisualEditor.
The patch is based on GuidedTour patch by Matthew Flaschen
https://gerrit.wikimedia.org/r/#/c/305691/ for T143297
Change-Id: Idf769e0149f93c099a94b1b7a6cb203273dab881
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
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
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
