Sat, Mar 23
As we start porting more and more components and want to run large scale tests against production pages, we will run into this requirement quickly since we don't yet have a way to test it with core. So, good to get this done sooner than later.
We are targeting 7.2
Fri, Mar 22
Thu, Mar 21
Oh 7.0? Isn't production on PHP 7.1 / 7.2?
Google had asked us about what dsr information means because they were using it for some reason and I added https://www.mediawiki.org/wiki/Parsoid/Internals/data-parsoid to document it with lots of caveats that we will and can change internals without warning. But worth at least giving them a heads up by tagging the relevant phab accounts on this ticket.
Wed, Mar 20
Tue, Mar 19
Thanks! So, I am going to mark this stalled. But, if priorities change and you need this sooner, please update this ticket accordingly.
Mon, Mar 18
Fri, Mar 15
We are right now heads down in porting Parsoid to PHP and would prefer not to undertake any development on the JS codebase unrelated to the porting itself. So, clarity around priority would be helpful for us to figure out how and when to engage with this request.
Thu, Mar 14
This is flagged for editors via the https://www.mediawiki.org/wiki/Help:Extension:Linter/unclosed-quotes-in-heading category.
Looks like our numbers are now more in sync after you disabled xdebug. But, here is the script I used.
Wed, Mar 13
Tue, Mar 12
Mon, Mar 11
That is correct. This can be closed and discussion can continue on that wiki page.
Sun, Mar 10
The discussion on this topic: https://www.mediawiki.org/wiki/Topic:Uueiraicppplzvm6 might help clarify.
Sat, Mar 9
I was trying to figure out the reason for the difference reported in failing test #1 in https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/494253/10//COMMIT_MSG.
I suspected one of (a) file reading (b) Remex parsing (c) XML Serializer.
Thu, Mar 7
All this speaks for us all to consolidate behind a common solution for HTML parsing and DOM manipulation on the PHP side. That could be Remex + the DOMCompat code that is currently in review ( https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/491892 ). One of the original suggestions @cscott made was to release this dom compat code as a composer lib but we just went with it being a Parsoid-internal compat layer for simplicity. But, if there is broader immediate interest, perhaps we could make it a composer lib which everyone can build upon.
Bonus points: sync file generation and options between transformTests and domTests .... i.e. both should probably take a common output directory flag and compute the file name from other options (prefix, page, transformer name).
Wed, Mar 6
Tue, Mar 5
A wrapper 'env' class around the different configs (site / wiki, parsoid, page) might still be useful so we can pass one object everywhere where needed.
Mon, Mar 4
Alright, I'll make this decision since it seems we have been going round and round a bit.
Sat, Mar 2
Fri, Mar 1
Wed, Feb 27
Tue, Feb 26
Mon, Feb 25
So, our pre-deploy testing has a hole for lang variants since rt testing doesn't cover this feature. Presumably, this would have been caught on beta cluster but that is currently readonly. In any case, @cscott, this is a testing gap currently.
Sun, Feb 24
A few comments:
- No need to use promises since all requests will be synchronously satisfied. Is there a reason you see for using promises for potential future async modes in PHP?
- Currently, usePHPPreProcessor is false for parser test runs in Parsoid. It uses the Parsoid-native template expansion and parser functions code. That has always existed since the beginning, but had too many edge case bugs and performance wasn't considered good enough to actually develop it further. But, using mediawiki api for parser tests runs would have been excessive given how frequently they run and it would have slowed down parser test runs greatly. But, the qn of what to do now with integration with Parsoid remains. I don't see a reason to not use the same core preprocessing code for everything (including parser tests).
- We need memoization support for sure for perf reasons. But, we probably do not need batching of template and extension requests any more.
- But, we do need batch query support to avoid hitting the db for every single image/link. The "redlinks" and "mediainfo" dom passes make these bulk metadata requests. So, we need support for these bulk/batch requests.
- As for linting, yes, you could use any existing interfaces provided by SiteConfig.