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
The iodea is to make the code simpler and easier to read. If no
code uses this feature, all it does is making the code unnecessary
complex.
Change-Id: I22747712a691443a29b57831d3a6926275ad986b
When used as {{#tag:ref|...}}, references can contain strip markers,
and different strip markers can hide the same text, so unstrip before
comparing to avoid false warnings.
Bug: T205803
Change-Id: I059fd853d1eea07aa06cc85f80e463dd97fd171a
Because of how arrays are handled, phan-taint-check thought all
return values from refArg() were escaped, where really only $dir
was. We also split the error method into the parse and noparse
case as separate functions so that phan can better analyse these calls.
In linkRef() we suppress the double escaping as the escaping used
is appropriate for inserting into wikitext.
Bug: T195009
Change-Id: I3e04c8cceae727e5470d4ae4fdb2404639f9bf33
@static is intended for use only when the language does
not support the concept of static methods natively
Change-Id: I9a0bf7db493d5667b22508e65a34034cefdbcbfa
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
The Cite extension already had a recursion guard around the parsing of
`<references/>`, to prevent another `<ref>` containing `<references/>`
from producing a weirdly nested references list.
When an explicit `<references/>` tag is not included in the page, or
`<ref>` tags exist after the last explicit `<references/>`, the extension
automatically adds a reference list at the end of the page, to make the
references still displayed.
This automatic references list creation was bypassing the recursion
guard, causing the weirdly nested output *and* a PHP Notice from
`mRefs[$group]` becoming undefined. This commit sets the recursion guard
state during that automatic references list creation to prevent this.
Bug: T182929
Change-Id: I87737dcf39a4fc15e119a1090a9c34d6b9633c21
The motivation for this patch is to make the code less complex, better
readable, and less brittle.
Example:
public function onExampleHook( Parser &$parser, array &$result ) {
/* This is the hook handler */
}
In this example the $result array is meant to be manipulated by the
hook handler. Changes should become visible to the caller. Since PHP
passes arrays by value, the & is needed to make this possible.
But the & is misplaced in pretty much all cases where the parameter is
an object. The only reason we still see these & in many hook handlers
is historical: PHP 4 passed objects by value, which potentially caused
expensive cloning. This was prevented with the &.
Since PHP 5 objects are passed by reference. However, this did not
made the & entirely meaningless. Keeping the & means callees are
allowed to replace passed objects with new ones. The & makes it look
like a function might intentionally replace a passed object, which is
unintended and actually scary in cases like the Parser. Luckily all
Hooks::run I have seen so far ignore unintended out-values. So even if
a hook handler tries to do something bad like replacing the Parser
with a different one, this would not have an effect.
Removing the & does not remove the possibility to manipulate the
object. Changes done to public properties are still visible to the
caller.
Unfortunately these & cannot be removed from the callers as long as
there is a single callee expecting a reference. This patch reduces the
number of such problematic callees.
Change-Id: Ib3a9da257b50326d569ab1973b523c952963c16b
This is the default for many years now. Returning true does nothing. It's
identical to returning nothing (null). The only meaningful value a hook
handler can return is false, and even this is meaningful only for very
few hooks.
TL;DR: A "return true" in a hook handler is always meaningless, dead code.
I'm interested in this because we (WMDE) might start working on this
extension soon and I want the code to be small and easy to maintain.
Change-Id: If4f32a55cdc38a3cc8af286d1cca7c0089bbfc43
Adding option for dir attribute in ref tags. The value must be a valid
direction ('ltr' or 'rtl', case insensitive) or the direction will be
stripped out.
The directionality of the li element is set using a css class accordingly.
Bug: T15673
Change-Id: Iff480bc8cc4f81403b310e8efecd43e29d1d4449
Without this change it would no longer load in safe mode (T185303)
because the module would be missing.
I think this has been copy-pasted from VisualEditor, see commit
I6d097ccbf1dc2462843219adcf96bf8313e30289 there for explanation.
Bug: T185303
Change-Id: I6f6857ec50e7b8c6e25022024c29b59726c656e3
Since Cite requires 1.25+ now, the checks for PPFrame::setVolatile(),
which was introduced in 1.24, can be removed.
Change-Id: I91df2e91b2f7a21b2b1147aa6af194980527f86b
Message indicates that a preview of the reference is missing,
instead of implying that the user was trying to edit it.
Bug: T188682
Change-Id: I5f5f8d5d0910ab2608696bbed380d4592cb6c7f1
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
This will allow them to auto-update, and be used in the
visual diff.
We record a templateGenerated attribute to prevent them
being edited, and to ensure they roundtrip back to
templates.
Bug: T52769
Change-Id: I4460d2c98166581e942e35921b20091990f5f6c7
Don't use the \Database alias, use the namespaced version when calling
Database::getCacheSetOptions.
And document why the remaining issue is suppressed.
Change-Id: I80a102f2e82efedcfa999d8e714bfe049263ffeb
Line 334 of Cite/includes/Cite.php contains two preg_match () calls. The subject lines for them are produced by Cite::refArgs () and are set to null or false when no name or follow attribute is provided in the <ref></ref> tag.
However, preg_match () is supposed to accept only strings as its subject, and the nowhere in the documentation it is said that it is nullable.
At least, in HHVM 3.12 this causes an exception.
The enclosed patch adds simple checks making sure that preg_match () is not called when $key or $follow are null or false.
Change-Id: I3e00d31d6bf216271ace7e851d88c68c4fd5ed00
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
If a ref node is highlighted as changed because its index
has changed (e.g. because an earlier reference was inserted
or removed), describe this more elegantly.
Bug: T170235
Bug: T171377
Change-Id: I2513bb82099a92529516e4e217e61a2d0a2dd43b
