In T241377#6006776, @Bugreporter wrote:

MediaWiki-Parser should also be merged or archived once the original MediaWiki parser is gone.

It is close to the end of the quarter, and we can get this done next week whenever you get a chance. No reason to wait till end of April.

In T248646#6005159, @Arlolra wrote:

Anyway, I git bisected and https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/583424 is the culprit.

That doesn't look like the right commit

For some reasons I never put together the thought that this could be because of the code we were rt testing itself :-)
Anyway, I git bisected and https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/583424 is the culprit.

In T245408#5994037, @Marostegui wrote:

...
The testreduce database isn't included on those, do you want me to include it too?

We should chat about the risk profile of this work in the context of covid19.

In T235307#6003888, @Arlolra wrote:

Noting so I don't forget. The use of Env in DataAccess::logLinterData is also suspect,
https://github.com/wikimedia/parsoid/blob/master/extension/src/Config/DataAccess.php#L331-L355

With that last patch in the long chain, here is what the Parsoid class imports looks like:

[subbu@earth:~/work/wmf/parsoid/src/Ext] git grep -h '^use ' */* | grep Parsoid | sort | uniq -c
      2 use Wikimedia\Parsoid\Core\DomSourceRange;
      1 use Wikimedia\Parsoid\Core\SelserData;
      1 use Wikimedia\Parsoid\Ext\ContentModelHandlerExtension;
      7 use Wikimedia\Parsoid\Ext\DOMDataUtils;
      7 use Wikimedia\Parsoid\Ext\Extension;
      8 use Wikimedia\Parsoid\Ext\ExtensionTag;
     16 use Wikimedia\Parsoid\Ext\ParsoidExtensionAPI;
      4 use Wikimedia\Parsoid\Ext\PHPUtils;
      3 use Wikimedia\Parsoid\Ext\Util;
      2 use Wikimedia\Parsoid\Ext\WTUtils;
      9 use Wikimedia\Parsoid\Utils\DOMCompat;
      7 use Wikimedia\Parsoid\Utils\DOMUtils;

In T247406#6001995, @Bawolff wrote:

Parsoid however, isn't in the critical path for rendering pages for view at present (I don't know what the full plans with the PHP port is though).

In T248343#6000187, @matmarex wrote:

(Sorry, I forgot to comment about that yesterday.)
Everything in VE works without RESTBase and its caching, including switching editors.

In T248343#5999141, @cscott wrote:

One of the issues flagged by the VE team was stashing/switching support. Needs investigation to see what needs to be done/could be done here. If switching doesn't work reliably w/o RESTBase, we should turn it off in the default configuration, so that whatever we ship in the LTS "just works", even if it doesn't have 100% of features.

Anyway, so it looks like the bulk of the proposed work is going to be in the ForeignRepo related code in MediaWiki (changing API so batching isn't defeated by dimension parameters, and caching).

Also, while this isn't immediately relevant for the GSoC project proposal, do note that it may be 15-18 months or longer before Parsoid replaces the MediaWiki core parser in the Wikimedia cluster. And, for third party wikis, there is the added caveat their own wikis + extensions should be ready for Parsoid.

I propose changing the image rendering code in Parsoid to lay off doing any image information requests to the last, postprocessing stage in the pipeline, somewhere around redlink checking. I think that has already been proposed (comments in code suggest that), but never implemented. Some necessary code (like the ability to make batch requests) is already in place, so this probably wouldn't require deep changes to Parsoid.

It is odd that when I click the Edit link, I get the 504 pretty quickly (< 15 s). And, I turned on XHGui in my Wikimedia-Debug extension and issued a request to the MediaWiki API and as https://performance.wikimedia.org/xhgui/run/view?id=5e7a3f3b3f3dfa0b0a8a3788 shows that request completed in ~8s.

In T248343#5995500, @Arlolra wrote:

So far, this is what I've been using,

wfLoadExtension( 'Parsoid', 'vendor/wikimedia/parsoid/extension.json' );
$wgEnableRestAPI = true;
$wgParsoidSettings = [];
$wgVirtualRestConfig['modules']['parsoid'] = array(
	'url' => 'http://localhost/rest.php',
	'domain' => 'localhost',
);

In T248343#5995032, @JTannerWMF wrote:

We are assuming the Parsing team is going to work on this

Sorry, I didn't communicate the entirety of why this is not an issue in my previous post.

Looks like is a case of wikilink-in-extlink / image-in-extlink wikitext. In the output, there are multiple link fragments instead of just one.

In T245408#5991238, @Marostegui wrote:

@ssastry any follow up on this task?

In T248186#5993118, @cscott wrote:

I'm treating the subtasks here as "candidates" for now, we can always remove stuff as LTS nears but it's harder to find or remember stuff we might want to do.
T236809: Refactor Parser.php to allow alternate parser (Parsoid) in particular has a lot of subtasks. I think we should make progress on those subtasks, even if we don't do 100% of them. I thought it was better to add T236809 for now than to add all or some of its subtasks.

I would say T236809 is a soft dependency, i.e. we can still release Parsoid in the LTS without that task getting to 100%.

In T241961#5993030, @cscott wrote:

Added T248343 and T237773 as parent tasks based on the two main options for fixing wikitech; note that only one or the other has to be done to unblock this task.

I am going to say: let us go with "good enough" since this feature is primarily for local testing -- and on large pages, this feature is mostly unusable since all API requests get serialized unlike Parsoid/JS. RT testing and beta testing is always our authoritative source of testing.

We added those baseline modules long back and it is possible we have gone out of sync with changes in core. Can you submit a patch that matches what core parser does wrt baseline styles?

@cscott adding this fix to Parsoid as well. T247804: Move Sanitizer from core into Parsoid will ensure we don't need to do dual duty in the sanitizer in the future and will be another step in the integration.

Parsoid handles the {{!}} parser function in the tokenizer and interprets it as a pipe character early before table cells are built whereas presumably this parser function is expanded later in the pipeline in the core parser. This one is a bit tricky and will need a bit of thought. One workaround for now would be to use <nowiki>...</nowiki> around the N|W|S| snippets everywhere on that line.

I am going ot mark this declined for now. We will probably revisit some of these discussions in the future based on these rfc / irc sessions, wiki pages, dev summit talks.

This was a dev summit session from 2017 which is all done now.

T247696: Tweak P-wrapping (tokenhandler pass OR DOM pass) to avoid swallowing trailing style tags that follow a template opening tag (and ditto for leading style tags that preced a template closing tag) is related.

In T245868#5929537, @Aklapper wrote:

In T245868#5913009, @ssastry wrote:

I don't think the Services applies any more for Parsoid since it is part of core.

@ssastry: Would you edit the project description to reflect the current situation?

We could possibly tweak the paragraph wrapping algorithm to be smarter about style tags that trail the paragraph and push it out of the paragraph. We had to add this logic for meta tags in the first place so, we may just have to treat templatestyle style tags similarly.