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

In T236809#7076201, @ssastry wrote:

In T236809#7076129, @MGChecker wrote:

If this is a real blocker, then, we'll have to introduce some kind of page property OR some kind of extension config option that will force full sequential reparse for any page that has that flag or extension config set.

To me that sounds like the Parsing Team is open to modifying Parsoid to support your use case.

I would really appreciate clarification on this point, since right above it is stated "However, if extensions introduce state that depends on the page parsed in linear order, yes, we cannot support that.". At the time I read this, this lead me to the conclusion that this is more of a theoretical possibility which has no real chance to be implemented.

But rereading this again, this might actually be a misunderstanding.

Sorry about using imprecise language in my comments across phabricator tasks.

High-performance and other functionality that depends on independent / decoupled parsing of fragments of a page cannot, by definition, support linear in-order parsing (To clarify: that does not mean hat the final page output won't be in the right order. It will be.). But, if we provide an opt-out mechanism in Parsoid for that to force a linear-ordered full reparse of a page, then I suppose that does mean that Parsoid supports such pages (but disable certain features / functionality on the page as well). Once again, we haven't worked through the feasibility and complexity of providing such support (that is a separate technical investigation), but hopefully that answers your question. And, all things considered, once again so we aren't offering false hopes, we'll lean towards breaking incompatible functionality in the pursuit of higher-performance and future-proofing the technology. But, we will not go down the route of breaking things simply because we can. We have attempted to minimize impacts to the extent it is practical to do so.

@RobinHood70 Since, in my experience this can be helpful to have everyone aware what is actually talked about: Is your custom preprocessor implementation published somewhere?

If this is a real blocker, then, we'll have to introduce some kind of page property OR some kind of extension config option that will force full sequential reparse for any page that has that flag or extension config set.

To me that sounds like the Parsing Team is open to modifying Parsoid to support your use case.

In T236809#7075998, @ssastry wrote:

As for this specific scenario, Parsoid is the future of wikitext processing for MediaWiki. There are no two ways about it. If wikis want to continue to use the legacy parser, we may provide options where we can package that as an extension for such wikis to use them. But, none of these changes will happen overnight and for for many reasons (Wikimedia wikis use of specific features, extensions and their dependencies, 3rd party wikis), it takes a long time. Deprecation processes, backward compatibility support, and refactoring tasks like this are some of the ways how we try to minimize impact.

There is, unfortunately, no zero-pain path available for these technical upgrades.

In T236809#7075902, @Legoktm wrote:

In T236809#7073451, @Nikerabbit wrote:

@RobinHood70 I see that you are angry about changes in the parser that will break something your organization has developed, and that causes you extra work and uncertainty about the future. Is that right?

I am not part of the team that develops the parser, but I develop the Translate extension, which is also incompatible with the upcoming parser changes. The parser developers have been really helpful for redesigning it to work with the new version.

...and they offered to do the same for Variables except it was the Variables maintainer who said they didn't want to do anything: T250963#6169439.

I like this idea quite much, as it would be an approach to incorporate Variables into Parsoid core. Exposing this caching would be a new feature, I think, which would rather be related to Variables than a replacement. I propose to bring this idea to the attention of the parsing team.

Done.

In T277883#6932372, @Ladsgroup wrote:

• "movestable"
  • Sounds useful but broken and can be simply moved to autoreview

The thing is that i am in over my head here. I was able to pick up and modernize this extensions regarding best practices, extension registration, and do some basic bug fixes and so on. However, the nuances of the MediaWiki parser and Parsoid in particular escape me. (And the parser documentation is horrible.) And these are points with significant security relevance too – at the moment I am wondering if the migration from ParserBeforeTidy to ParserAfterTidy has not introduced various security holes, since the output of these extensions is apparently no longer tidied. I do not want to be reponsible for introducing serious security vulnerabilities into thousands of wikis.

See T236809 for further information. I do not think this can be really worked around, which makes this a wontfix.

Is there anything left to do here?

@hashar Afaik, Diffusion repositories should only be deactivated after the archival commit from Gerrit is mirrored over. Otherwise, they won't be updated.

Well, whereever in Ladsgroups current code we have wgNamespaceNumber we could just have a list of all globals which need replacement. In particular, this means we do not have to visit wikis multiple times.

Wouldn't it be easier to just replace all variables at once?

I'm not 100% sure, at least I think we must clean mw namespace first before moving forward. I have been fixing cases in Common.js, we can't break a whole wiki because they are too small to have tech savvy admins.

Is it possible to add me as a subscriber to the relevant tasks, so I can take a look at them?

This sounds really promising! However, I would like to hear from the maintainers of this extension before initiating anything further.

A look at WikiApiary tells that this is the second most popular Mediawiki extension which is not deployed by WMF and the 21st most popular extension in general.

In T269718#6685174, @Kghbln wrote:

Ooops, I see that the patches are unmerged. I should have been more attentive. Now I officially published news about the issue without the fix in place. That's life I guess. In the future I personally would appreciate disclose only if the fix was merged. Otherwise I see no sense in doing so. Again this is just my personal opinion.

Diffusion needs some time to sync its mirrors so the skin is shown as archived here as well.

This is just stale…

You did not specify any extension/skin here. After doing so, feel free to repoen.

I think the way forward proposed by the patch is confusing. Either we should remove the setting altogether, or keep it functional for another version of MediaWiki. Removing its functionality without removing the setting seems unhelpful at best.

Requested public project User-Demian has been created: https://phabricator.wikimedia.org/project/view/4852/

Are you sure you are pushing to the correct URI? (http://phabricator.wikimedia.org/source/tool-commons-android-app.git) and using the correct credentials?

Done.

Considering the discussion in T236809, I am against doing anything here. There is no suitable alternative, as InternalParseBeforeLinks will probably recieve the same treatment, and the deprecation should be removed soon.