-
-
Notifications
You must be signed in to change notification settings - Fork 20
feat: ParsoidModule implementation #166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
|
The latest commit c036061 actually fixes the Parsing issue, such that wikitext is parsed properly to HTML when it is passed to the template for display. That fixes the most major bugs, and we essentially have PortableInfobox for Parsoid working. One issue that did crop up, however, is that Parsoid automatically inserts h2 or h3 and wraps them.
This corresponds to the section the infobox exists on the page (I assume this is to signal to VisualEditor which section on the page the infobox is at, so when a section is edited, it knows to pull the infobox in. This issue did not crop up during development as I - this seems like an idiot move - was using the VisualEditor primarily to see the result from Parsoid. Obviously, the VisualEditor API does not return these section tags, but they are returned when using the ParsoidMigration extension. I can't figure out a way to disable this behaviour, so I'm going to ask on Phabricator if anyone has any ideas. |
…aWikiParser::class and parsing it early causes Parsoid to just return the infobox src.
… base class to reduce duplication
feat: deal with complex arguments
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #166 +/- ##
=======================================
Coverage ? 44.48%
Complexity ? 613
=======================================
Files ? 43
Lines ? 1850
Branches ? 0
=======================================
Hits ? 823
Misses ? 1027
Partials ? 0 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This PR is a draft implementation of a ParsoidModule for PortableInfobox; it displays PortableInfoboxes for reads on Parsoid (and also has the benefit of displaying them in the VisualEditor, and they are editable.) It supersedes #165 with a more robust implementation. It closes #132
It's a bit of a draft at present, and could probably be refined. A few of the classes (such as the
PortableInfoboxRenderServicehave been copied and adjusted, and are namespaced underPortableInfobox\Parsoid.It's still a work in process, and hasn't been tested against complex infoboxes. But it's a MVP that works at present. There are some issues:
Issue No. 2 is the most problematic. It feels a bit like a catch-22 situation. Doing everything in the
->extTagToDOMis too early, as we don't know the parameters the user passed to the template on the page, so we rely on getting it later in thewtPostProcess, however this seems to return just plain wiki text and there doesn't appear to be any way to re-feed this to Parsoid to get the parsed value back.I'm PRing what I have for now, and will continue to work on it - but if there are any ideas how we can get this Parsed, I'm all ears. May need to ask on WMF Phabricator if we can't figure it out.
Changes to wider PortableInfoboxes
NodeFactory::newFromSimpleXMLandNodeFactory::newFromXMLnow accept an$externalParser. This should either be theMediaWikiParseror theParsoidMediaWikiParserthis is needed so we can differentiate between whether we are in aParser.phpcontext, orParsoidcontext. Mostly for the<image>and<media>tags, becauseNodeImagecurrently calls out to the legacy parser functions which we don't want. It is null by default, so that no change needs to be made for the legacy implementation.MediaWikiParserService::addImageto add the image to the HTML output for selection byPageImages. InternallyPageImagesrelies on several Parser.php hooks which are not guaranteed to be supported. Further investigation is needed to whether this can be supported when/ifPageImagesis made Parsoid-compat.