DiscussionTools reply doesn't work either.

DiscussionTools reply tool problem is a separate issue, it looks like the same situation as described here: T259824: DiscussionTools's reply tool doesn't work when the comments are transcluded from another page using a template (not directly).

We’ve talked about the wrong edit links in T368095: Parsoid shows bogus section edit links. It’s because template transclusions still use the legacy parser, and so Parsoid is not aware of where the heading actually comes from. (This is also why DiscussionTools doesn’t work – it only sees data Parsoid sees. So I wouldn’t call it a separate issue.) The task got closed, but this problem hasn’t been fixed, apparently not even almost two years later.

The task got closed, but this problem hasn’t been fixed

It was filed as T387520

Noting that the issue doesn't just affect small size Wikipedias, there are similar reports on German Wikipedia as well – and likely all other projects using Parsoid as the new default judging by the number of subscribers from different wikis.

In T422291#11889795, @Johannnes89 wrote:

Noting that the issue doesn't just affect small size Wikipedias, there are similar reports on German Wikipedia as well – and likely all other projects using Parsoid as the new default judging by the number of subscribers from different wikis.

Fair enough!
We've been partly using "small size" vs "larger" as a shorthand for "places where Parsoid is already the default" vs "places where it's not", but we may need to rename these milestones now that we did start deploying on larger Wikipedias :)

The new parser is still way too buggy to be used on productive projects. There are so many bugs linked to the new parser on German Wikipedia, it's really annoying. The deploying definitely started much too early.

This basically breaks the easiest ways to edit sections for templates with documentation pages. It is quite unfortunate that there is also no way to differentiate Parsoid-rendered pages from non-Parsoid ones via CSS since I’d rather hide those edit links while this bug is still active than mislead people into thinking they lead somewhere useful, like they did before.

It is quite unfortunate that there is also no way to differentiate Parsoid-rendered pages from non-Parsoid ones via CSS

Try .mw-parser-output[data-mw-parsoid-version]

In T422291#11923669, @ABreault-WMF wrote:

Try .mw-parser-output[data-mw-parsoid-version]

You can’t target .mw-parser-output itself in TemplateStyles, unfortunately (and putting it in Common.css for everyone would probably be too much for this bug).

I read this just now in another task related to this one:

In T368095#9971720, @ABreault-WMF wrote:

Section edit links are only relevant to what we call "read views". The way the pipeline is constructed, Parsoid parses wikitext to a canonical output, which gets cached. Then, depending on the calling client, the cached output is transformed. See core's DefaultOutputPipelineFactory for the stages that are applied for desktop clients, one of which is HandleParsoidSectionLinks. These section edit links are undesirable for editing clients, like VE, or the mobile apps, etc. If the legacy parser was asked to apply them during preprocessing then they'd be in the cached output.

This made me wonder: while the links are undesirable in page views, what stops Parsoid here from doing something like exposing them in the metadata, so that Parsoid itself could then build correct edit links in read views? i.e. something like this in <h2> output (data-… attributes or even just href):

<link rel="mw:EditSectionLink" data-page="…" data-section-id="…">

This wouldn’t pollute VE or other contexts more than the existing HTML pollution we get from Parsoid, but it would ensure that it always knows what context an edit link is required in. Seems like a potential solution to this issue.

It also has wrong links in Template data's edit button. The first image is Parsoid, the second image is the legacy parser. The example is from ukwiki.

In T429038#12032359, @Repakr wrote:

Could we revert the deployment of Parsoid for ukwiki for now, before this ticket T422291 is fixed? Or prioritize resolving the ticket? Because a lot of documentation pages are broken, we prefer to have an edit link in the section, unlike enwiki, which has them only at the top of the documentation box. Then there is a problem with TemplateData that also has an invalid link if you try to edit it from the documentation box. And now users are complaining on the page Requests for administrator attention (https://uk.wikipedia.org/w/index.php?title=%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%96%D1%8F%3A%D0%97%D0%B0%D0%BF%D0%B8%D1%82%D0%B8_%D0%B4%D0%BE_%D0%B0%D0%B4%D0%BC%D1%96%D0%BD%D1%96%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%D1%96%D0%B2&diff=48222382&oldid=48220768 Section «Захищена сторінка») that they cannot edit discusions on the page https://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%96%D1%8F:%D0%9F%D0%B5%D1%80%D0%B5%D0%B9%D0%BC%D0%B5%D0%BD%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%81%D1%82%D0%B0%D1%82%D0%B5%D0%B9 through edit links, becuase the transcluded through template https://uk.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:Rename.

This is probably three different bugs. The translation of the link in the middle of this report is:

:When trying to edit any topic in rename requests, it redirects to this [https://uk.wikipedia.org/w/index.php?title=Template:Rename&action=edit§ion=T-1 page], it is indeed somehow related to renames, so if there is no protection, then it is a technical bug... --[[User:Dzmij Dzmijevich|Dzmij Dzmijevich]] ([[User talk:Dzmij Dzmijevich|talk]]) 18:28, 17 June 2026 (UTC)
: With [https://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%96%D1%8F:%D0%9F%D0%B5%D1%80%D0%B5%D0%B9%D0%BC%D0%B5%D0%BD%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%81%D1%82%D0%B0%D1%82%D0%B5%D0%B9?useparsoid=0 old parser] these links work, something in the {{tl|Rename}} template is broken, @[[User:Repakr|Repakr]] might know how to fix it [[User:MonAx|<span style="color:#F68600;">MonAx</span>]] <sup>([[User talk:MonAx|talk]])</sup> 06:08, 18 June 2026 (UTC)

The source for the Rename template is at https://uk.wikipedia.org/w/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:Rename&action=edit

In T422291#12024000, @Repakr wrote:

It also has wrong links in Template data's edit button. The first image is Parsoid, the second image is the legacy parser. The example is from ukwiki.

Filed this as T429624: Link to edit TemplateData is broken with Parsoid Read Views.

This is a show-stopper for Parsoid deployment, at least on en.WP. Clicking [edit] for a section of a template documentation page (the green section of a template page) results in an error message. A simple example:

1. Go to https://en.wikipedia.org/wiki/Template:Infobox_Chinese#Subtemplates_used_by_Infobox_Chinese with Parsoid enabled
2. Click on [edit] to the right of "Subtemplates used by Infobox Chinese"
3. Note that you are now trying to edit Template:Documentation instead of Template:Infobox Chinese/doc. The resulting URL is https://en.wikipedia.org/w/index.php?title=Template:Documentation&action=edit&section=T-5
4. See an error message: "You tried to edit a section that does not exist. Because there is no section T-5, there is no place to save your edit. Sections may have been removed or the page moved after you loaded the page. Try to reload the page, purge the page, or bypass your browser cache."
5. At the bottom of the error message is "Return to Template:Documentation." [[Template:Documentation]] is linked, and it is not where I came from, so it is an error within the error message.

Clicking [edit] inside the green documentation portion of a template page should take you to an edit screen containing the wikitext of that section.

Using https://en.wikipedia.org/wiki/Template:Infobox_Chinese?useparsoid=0 and then scrolling to the same section and clicking edit results in https://en.wikipedia.org/w/index.php?title=Template:Infobox_Chinese/doc&action=edit&section=T-5 which is correct.