The difference is that for the "general LDR case" the parser is able to decide on an index number the moment the first <ref name="…" /> appears somewhere in the text. It doesn't matter if the full reference appears before or after this point. The numbers are simply incremented from the top of the document to the bottom.

Yes! We are currently in Beta, and plan to roll it out as a default feature within the next months.

I don't mind much at this point. We said we want to be able to find all pages utilizing extends="…" just in case something goes wrong. But we don't have an actual plan to use this information. So what would be the benefit of making it a category?

For the sake of completeness: The undefined indexes in T240248 are essentially just a side-effect. This here was the actual user-facing issue that silently (after we got rid of the log spam) broke content pages, as described in the commit message.

We need to split this off to a new, separate ticket. @awight, I guess you are most knowledgeable about this edge case at the moment. Can you create such a ticket so we can close this one here?

I had a closer look and learned this is not a Cite bug. The fact errors are sometimes hidden is a decision entirely made by the English Wikipedia community, via customized messages and templates:

{{broken ref

| other             = <span class="brokenref">

span.brokenref {
	display: none;
}

This issue does not occur in most namespaces, only in a few that fall under "other". That includes the user namespace.

What we have done so far:

• Some of the errors are from a parse API call, some aren't. It appears the way the parser is called is unrelated.
• Some of the stack traces I have seen happen when an article uses {{#tag:references|…}}. This triggers the rollbackRefs() and $redoStack code, undoing and redoing some previous actions. We suspected this might mess with the ReferenceStack::$refs array in a way that's not clean.
• There is a foreach loop in referencesFormat(), rendering the <ol> list of all individual <ref>s in a group. This code is using a copy of the values from ReferenceStack::$refs. Is it possible this code is using a conflicting copy and the original ReferenceStack::$refs the same time?
• We suspected PHPs garbage collection to mess ReferenceStack::$refs up.
• All the wiki pages I have seen so far contain the Cite error about a <ref> being declared twice, with conflicting content (it says "name … defined multiple times with different content"). It turns out this was indeed relevant, even if the issue might not be strictly limited to this code.
• We suspected the ParserClearState and/or ParserCloned hook handlers being involved. Both intentionally mess with the Cite classes internal state.
• Some array index errors happen in ReferenceStack::pushRef() in a place that looks like it is protected by an isset( $this->refs[$group][$name] ). With this check it should be impossible to run into array index errors, except the code between the isset() and the error is secretly modifying $this->refs. The only calls we can see are StripState::unstripBoth(), which looks trivial, and Parser::addTrackingCategory(), which does a suspicious Message call.

Yea, this is per-wiki configuration. For most wikis we get "a", "b", and so on. There is not much we need to do for these wikis. What we need to take care of is the behavior for wikis that don't have such a customization.

I would like to keep this open. Things to do:

• Check the logs for the message "Failed to retrieve import result from".
• Based on what we see we should decide on a new action, e.g. opening a new ticket.
• Possibly remove the logging.

For reference: We announced the removal of this API on 2019-12-05 via wikitext-l. We expect it to disappear in the builds https://www.mediawiki.org/wiki/MediaWiki_1.35/wmf.10 and later in MediaWiki 1.36.

At the moment, this ticket is only about the Reference Previews feature developed by WMDE. We plan to create a separate ticket for the gadget when it becomes more relevant, and we are able to suggest a fix for the community to apply on the gadget.

I did a bisect and the bug was not there before the patch https://gerrit.wikimedia.org/r/553111. That was the patch that introduced new CSS counters for sub-references.

I think I just did that in a patch that's not linked to this ticket, because I found it annoying as well.

I evaluated my arguments from the mw.org talk page and still think the character sequence … ) : … is not automatically better. I still suggest to follow PSR and enforce … ): ….

Personally, I don't really like the idea of having a strict rule for this. Not only because it's a matter of taste. From my experience the code is sometimes more readable when all boolean operators are at the beginning of the line, and sometimes when they are at the end of the line. In rare edge-cases this might even vary within a single file, sometimes even within a single if.

Personally, I don't think such an upper bound should be variable. The idea really is to have it fixed.

That looks right.

Today, we got a ping via https://github.com/wmde/mitmachen/issues/49#issuecomment-559351592 saying "Please check, it is fixed". I did.

I checked, and the module "jquery.wikibase.entityselector" still exists. But it might be that it is not loaded by default any more. You need to request it, either via "dependencies" in the definition of your ResourceLoader module, or via $parserOutput->addModules( … ) in your PHP code, or via mw.loader.using( … ) in your JavaScript code. Without knowing much about your code, I assume the last option would be the best.

Gerrit also shows bars to visualize the size of a change. This feature is quite similar to what Revision-Slider does.