The use case we care about is this:
<ref extends="some_book"> </ref>
It doesn't make sense that works, but the following doesn't:
<ref extends="some_book"></ref>
We decided that both need to behave the same.
For consistency this patch is applying the same change to all references,
no matter if they use the extends attribute or not. This is an actual
change and might make existing wikitext render differently. However, I
would like to argue that all wikitext that was using this was broken. The
effect of a <ref> </ref> with some whitespace is that the <references>
section at the end of the article will contain – well – an empty footnote.
Bug: T237241
Change-Id: Iaee35583eabcb416b0a06849b89ebbfb0fb7fef9
Note this codebase appears to be dual-licensed. Some files mention MIT,
but extension.json and some other files mention GPL.
Since WMDE typically uses GPL, I will continue to mark the files we
created as such.
Change-Id: I126da10f7fb13a6d4c99e96e72d024b2e5ecee06
Note how this code was broken since 2018 (Iff480bc). In this execution
path, $val is a string. There is no $val['dir'].
Luckily, this was dead code since 2008 already. See
https://phabricator.wikimedia.org/rECIT448a99da5108c26ce88d3df7cf5df2b5b5b1d1d3
line 283 on the right.
Bug: T237241
Change-Id: I671f3379a124a2644a9b0eac38d46c59106980a7
1. Most existing CiteTests can be unit tests. They run so much faster
this way.
2. I modified some test cases to cover all trim() in the code.
3. The strict type hint in CiteHooks is removed because the parameter
is not used. Having a hard type hint for what is effectively dead code
makes the code more brittle for changes done outside of this codebase.
Change-Id: I1bff1d6e02d9ef17d5e6b66aeec3ee42bba99cf4
This fixes a series of issues:
* There is nothing about a "frame" in the Cite class any more.
* There is no addModules() call in the Cite class any more.
Change-Id: I20c814d46c26825c5c07eab0a5586de3a531eee7
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
Two motivations:
1. I want the two deeper nested functions guardedRef() and
guardedReferences() to have less side effects.
2. In guardedReferences() guardedRef() is called. Both set the
property. That's redundant. The new code avoids this.
Change-Id: I48146f8b6d91122a904be0a552ffe3b03bc0481f
Main motivation is to make the code easier to test, and easier to
extract to smaller services.
Does this make sense? I'm not sure any more. One can argue that
everything Cite does happens in the context of a specific Parser. Why
shouldn't the code have access to this Parser?
Change-Id: I9d0cb44d96ec70a56af57f86aeb1f264f52c8bc4
Note it doesn't make a difference if this is behind the feature flag or
not. It should always be forbidden, and in fact is: Either the follows
attribute is unknown, or the combination is forbidden.
Bug: T236256
Change-Id: Iebbb2d1d5bab183ab0590b8a7a7f6e79d319b72c
Any time the book referencing attribute is used in a page,
permanently tag that page with the `ref-extends` property, so
that it can be watched and cleaned up if necessary.
Bug: T237531
Change-Id: Ice5d9d8f7a305702cdc7c2a55d4147c4f79b5881
Incremental patch which extracts the refines attribute from the tag.
Doing this now to allow the calling function to have responsibility
for doing something with the attribute value.
Bug: T237531
Change-Id: I59bb409bedd8e6ed06268e705e02e8ffb45b1f0e
I was particularly suprised by the conditions that checked if
`$parser->extCite !== $this`. This can never happen. Maybe it was
possible in a very old version of this code, but it is not any more.
Change-Id: I049ff4109a747eb9dbf325c24cf20f65753827dd
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
Renaming to $text since this is also already used in the array structure
to store the references and seems more intuitive than $str
Change-Id: I4dbe5d10ddc355b4587d195b50cf078ac01fac55
The text could be null if we're stacking a re-used reference there.
Also content is a more precise word for what was forwarded here.
Change-Id: Ic78fb4744314c40360a61c21e92462b6eb2ae1ab
