People can still use CSS pages for this if we have JS syntax checking.

The expectation that the mainspace of the wiki is basically closed in itself is quite reasonable, and the desire to not confront unsuspecting readers with prefixes like "Disambiguation:" as well. Finally, any suggestion which requires a regular bot run to restore basic functionality is obviously out of the question.

It is basically inconceivable that this will be merged, given that it is not deployed in Wikimedia production and there are reasonable arguments why. I suggest declining this task.

I do not see any consensus to advance in that task.

I do not see any consensus to advance in that task.

Project has been archived.

Adding Continuous-Integration-Infrastructure as that's the last step that needs to be done.

It is my impression that using the template maybe lead to steps being done which should not have been – the extension is not archived in any strict sense, after all?

I mean 90% of the points here can be done without archiving a gerrit repository?

Yes, but I mean within the abusefilter extension, not within the callers.

Doesn't this just boil down to making UltimateAuthority bypass abusefilter?

I just took care of it.

The past perfect was chosen intentionally, I archived it, and just wanted to point out to be wary to not forget this before marking a task as Resolved.

Would like to point out the specific concerns and negative feedback mentioned at the corresponding talk page:
https://meta.wikimedia.org/wiki/Talk:Wikidata_For_Wikimedia_Projects/Projects/Move_Wikidata_item_link

Diffusion mirror had not been deactivated yet.

@cscott The patch in question also makes use of linear parsing, but is using the ParserOutput extension data to do so rather than the parser object itself.
It is not clear whether read-write access to ParserOutput extension data or the properties in the Parser are going away earlier, so the migration path to maintain compatibility as long as possible is not clear.

As this is truly append only and only used to check whether a limit is violated, I would estimate that this task is significantly easier than its cousins

@BertrandGorge Seems to be resolved, if you still experience this issue after upgrading, please reopen.

At the moment, I still aim to get a stance in T282499. If they decline it and parallelize parsing entirely, we can keep Variables more or less running only so long. Otherwise, they should include a dedicated mechanism for our use case.

Considering our discussions about this, let's remove this from the 2.6.0 milestone.

Tbh, I have not checked in detail whether Loops may present this issue.

I believe that this can not be caused within Variables, but only by bad callers. (Like Loops and @Universal_Omega s Universal-Omega/DynamicPageList3.

What precisely did you do to raise this error? Which version of Variables are you using?

Should these variables be only available at the same scope, or also on the child scopes? I would have a strong preference for the first option.

This should be obsolete now with
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Variables/+/856020

This states

In T282499#9389818, @MSantos wrote:

I know this topic is still open-ended and I'm looking for a solution to keep communication clear and transparent as the project advances, as of now the best places is the following wiki page https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Updates.

@cscott I would just like to bump this such that it is not forgotten, as the combination of T343227 and T300979 would make us loose our migration path for extensions building on forced linear parsing. If you decide against this, I would request two thingsÖ

This has become a bit more pressing with dynamic properties being deprecated with PHP 8.2. While MediaWiki is not compatible with that yet, it is only a matter of time. In any case, we will need to fight around T300979 and T343227 soon I guess.

In T282499#9223150, @BrownKDocs wrote:

I'm also interested in updates on this question. I manage a corporate wiki with a few thousand pages and we don't use Lua or Scribunto. I don't understand what this change will mean for me-- does my team have to rewrite everything that uses ParserFunctions? What support is being offered to help wikis that must make this change? If we have to do a ton of work in order to use a current version, we're going to be in the position Stux describes.

I am unsure, but local experts are claiming that they will require extensive testing. See WD:NEU.

It does not seem like dewiki will be able to adjust its gadgets with this on that short notice. Maybe it would be possible to delay this a few weeks?

@demon Please archive the diffusion repository only after the respective gerrit patches have been merged. Otherwise, these are not synced to Phabricator.

I would like to point out that especially on dewiki, beta is used actively downstream for development of templates, modules, javascript etc., with permissions elevated in comparison to production. It would be a pity to lose these capabilities.

Variables still works without issue in MW 1.40; and the same should hold for the other extensions. However, due to the use of #var_final it will emit deprecation warnings.

@Seb35 You should then open a task under Gerrit-Privilege-Requests do be granted maintainer status.