We are discussing this for a long time and finally renamed the tag
on Phabricator: https://phabricator.wikimedia.org/tag/cite-extends
This patch updates only places where it can't have any negative
consequences.
This is also a direct follow-up to Ic73f1b7 where this class was
created.
Bug: T353269
Change-Id: I644fe41d3386b9bf02b83366654301633efd535f
User-options related classes are being moved to the MediaWiki\User\Options namespace in MediaWiki Core; reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: I04337d15d32c1e8bdfdcfa272f1750ffecc8e47e
ext.cite.style.css is very close to ext.cite.styles.css and is
often confusing.
In about 3 weeks (the current PC expiry time), we should be able to
get rid of the ext.cite.style module from extension.json after
removing all references to it from other repos and caches.
I don't see a reason to rename all the other language specific
CSS files since there is no room for being confused there.
Change-Id: I3a41f435b0cbe51f8c9a6dde8a9f6eb13a9879f7
This reverts commit da30b2b626.
Reason for revert: Caused a regression. Feature is not enabled on public wikis so reverting is harmless for now.
Bug: T247922
Bug: T340757
Change-Id: I83434afaf1b76425bddb575dd724f462a247c83d
The WikiEditor extension has a button and some help text that
is only applicable if the Cite extension is enabled. Move
that (with some modifications) to the Cite extension instead.
Bug: T339973
Depends-On: I8256660f9c6886d6764b45735284e00308fc56e5
Change-Id: Ib3fdc897dd3330f69c5832003d4c3cb1e6dba2f3
To warn users when they are editing a sub-reference we
add a warning containing the text of the parent reference.
This is hidden behind a feature flag.
Bug: T247922
Change-Id: I3749683d8a18e502bf16e5bd5f2fe385581625be
* reads the new attribute extends from wikitext
* saves it into the reference model
* adds a message to the VE popup of an extension as a first demo
* tests will be added in a separate patch
Bug: T247922
Change-Id: If4d309c4678022642f39e21565950dc45e557d47
This code is being silently removed from mobile pages.
This code is never utilized on mobile because a reference
drawer shows on references click so no back link is necessary,
however given the size of the code, it doesn't seem like a good
idea to split the parser for this, so we should just add it.
In future perhaps the reference drawer feature in Minerva could be
moved to this module.
Bug: T324723
Change-Id: Ib49dcd647df765524887b4f3cc4bd0ccdb5b5ff0
Extensions using Phan need to be updated simultaneously with core due
to T308443.
Bug: T308718
Depends-On: Id08a220e1d6085e2b33f3f6c9d0e3935a4204659
Change-Id: Iebc5768a3125ce2b173e9b55fc3ea20616553824
Rather than depending on a separate module with one line of generated
JS code, generate it as a prepended statement to the same module.
Should be a no-op.
Depends-On: I809951d34feb2dbd01b7ae0f4bd98dac7c3f6fe2
Change-Id: I5886bf9f82025048976b7750e8cb751681021fb4
This means that all reference nodes are treated as comparable
in the diff (provided they are in the same group) so will
not show up in the article diff if their index changes.
Changes to the reference list are already handled separately
by the visual diff.
Bug: T170235
Change-Id: I8c26686d7b2fe3bf91af7d4dcab1caf3247dbe47
This is how we handle this in othe repos; CI ensures that VisualEditor
is indeed loaded alongside the Cite extension whenever it's required,
and this significantly reduces the complexity of the code in the repo
and the processing time needed from Cite's hooks on every PHP init.
I'm leaving the "ux-enhancements" module for now, as you can't mix
static (late) module registration with dynamic (immediate) code.
Change-Id: I974654d00687b0dea6aed342d8fa9dcb6ef90768
CI already ensures that VisualEditor is loaded alongside Cite, so
the defensive check in the code isn't needed; ext.cite.visualEditor is
defined statically, it's just injected into the page dynamically in the
VisualEditor code handling VisualEditorPluginModules.
Bug: T232875
Change-Id: Ie5e096feca92f9c3ef13c732f3f1ae491e2b7d03
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
