@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.

I maintain my point. There is no reason to archive.

Many users provided arguments above why a solution like this would introduce additional problems both for Wikimedia as a provider and as a new avenue for harassment.

Only Gerrit administrators can add people, as requested by you:
https://ldap.toolforge.org/group/gerritadmin

Effectively, tracked elsewhere.

hmm. I mean it is an Danwe parser extension. It probably still works for now, and is installed on Wikis on 1.37.0 according to Wikiapiary.

You can check the log to understand its behavior.

I am curious: Where has this topic come up recently?

I deem it highly unlikely that a group like that would be added on a single community's request. We usually try to not bloat configuration settings to much, and your request could only be done by doing so or by adding one highly specific user permission which would not serve the potential needs of other communities.

Thank you, this is everything I asked for! From my side, this can be marked as resolved then.

I have to admit that I have not been to mindful to making this information more widely accessible. I do not consider myself a real author of the extension, so I have not added my name on the respective places. I have added respective indications now.

Thanks for the task, but it's very unclear what the problem is, and what you're wanting doing.

On dewiki, this has been used occasionally: https://de.wikipedia.org/wiki/Spezial:Logbuch?type=stable&user=&page=&wpdate=&tagfilter=&subtype=

This is the main mode of FlaggedRevs used in enwiki, and is quite popular there. In dewiki, it is used occasionally as well.

With the patch merged, is there anything immediately left to do here?

I think with the code published on GitHub, there is not really a thing left to be done here.

This has been a bug in the 1.0.0-beta version, which is still in (quite stale) development. On current master, the variable should work as expected.

Considering how Phabricator was maintained so far, I think that it might be possible for a small team to maintain it.

In T283980#7123724, @hashar wrote:

I propose we keep this task open for a week or so to let people land tokens of appreciation to Phabricator / Phacility @epriestley (creator of Phabricator and founder of Phacility) and then close it. Surely we would have a project / working group to discuss about the future.

Took care of unarchival on Diffusion.

In T250963#7076349, @Legoktm wrote:

I believe there are two issues that need solving:

1. How to implement Variables as a Parsoid extension, and if new Parsoid functionality is needed for that