Now it is "composer/installers": "^2|^1.0.1", so, I think, resolved.

After enabling Tag emulation mode for any connector, moving some features from the EDConnectorExe to EDConnectorBase class and adding presets, with Dockerfiles docker-compose.yml, the task, for which this feature request was created, — that is, moving server-side programs, especially, multimedia, to microservices — is, more or less, fulfilled; although not literally with ShellBox, which I did not like, when I studied it.

This is now fixed, thank you Alexander

@BlankEclair - thank you for the analysis, and the fix!

Change #1077142 merged by jenkins-bot:

[mediawiki/extensions/ExternalData@master] Fix new ExternalData installations by dropping post_vars

https://gerrit.wikimedia.org/r/1077142

In T376241#10194644, @BlankEclair wrote:

I reckon we should drop the post_vars column, I don't think we ever used it

Change #1077142 had a related patch set uploaded (by BlankEclair; author: BlankEclair):

[mediawiki/extensions/ExternalData@master] Fix new ExternalData installations by dropping post_vars

https://gerrit.wikimedia.org/r/1077142

I reckon we should drop the post_vars column, I don't think we ever used it

Change #1076722 merged by jenkins-bot:

[mediawiki/extensions/ExternalData@master] Fix type mismatch in EDConnectorDb::processField()

https://gerrit.wikimedia.org/r/1076722

Change #1076722 had a related patch set uploaded (by Alex Mashin; author: Alexander Mashin):

[mediawiki/extensions/ExternalData@master] Fix type mismatch in EDConnectorDb::processField()

https://gerrit.wikimedia.org/r/1076722

Change #1075236 merged by jenkins-bot:

[mediawiki/extensions/ExternalData@REL1_42] Fix "Cannot access offset of type string on string" with Scribunto

https://gerrit.wikimedia.org/r/1075236

Change #1075236 had a related patch set uploaded (by BlankEclair; author: BlankEclair):

[mediawiki/extensions/ExternalData@REL1_42] Fix "Cannot access offset of type string on string" with Scribunto

https://gerrit.wikimedia.org/r/1075236

Change #1075150 merged by jenkins-bot:

[mediawiki/extensions/ExternalData@master] Fix "Cannot access offset of type string on string" with Scribunto

https://gerrit.wikimedia.org/r/1075150

Change #1075150 had a related patch set uploaded (by BlankEclair; author: BlankEclair):

[mediawiki/extensions/ExternalData@master] T375469: Fix "Cannot access offset of type string on string"

https://gerrit.wikimedia.org/r/1075150

@alex-mashin: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

In T282499#9731215, @Func wrote:

In T282499#9730874, @cscott wrote:

1. Current Parsoid calls back to the legacy Parser to handle various types of content. That can cause there to be multiple $parser objects used on a given page. Most *present* issues with "linear parsing" are due to the fact that, even though the parse is technically in order, data being attached to the Parser object is lost because there are multiple parsers in play.

I saw that the DataAccess class would use the same legacy parser object for all calls to extension tag when the PageConfig remains unchanged, basically it means within the same page? Do you mean this is going to be changed soon, or did I miss some concept about the PageConfig etc.?

In T282499#9730874, @cscott wrote:

1. Current Parsoid calls back to the legacy Parser to handle various types of content. That can cause there to be multiple $parser objects used on a given page. Most *present* issues with "linear parsing" are due to the fact that, even though the parse is technically in order, data being attached to the Parser object is lost because there are multiple parsers in play.

Two orthogonal issues here: