IDs are sometimes incorrectly counted twice for unique ID generation

Created on 10 January 2019, almost 6 years ago
Updated 16 August 2023, over 1 year ago

In at least one known situation, it appears that IDs can be counted twice such that all generated IDs have '--n' appended to them. For example

<h2>Foo</h2>
<h2>Bar</h2>
<h2>Bar</h2>
<h2>Bar</h2>

should produce:

<h2 id="foo">Foo</h2>
<h2 id="bar">Bar</h2>
<h2 id="bar--1">Bar</h2>
<h2 id="bar--2">Bar</h2>

but instead produces:

<h2 id="foo--2">Foo</h2>
<h2 id="bar--4">Bar</h2>
<h2 id="bar--5">Bar</h2>
<h2 id="bar--6">Bar</h2>

One way to reproduce this issue is to install this module and configure the filter for at least one input format, then install the Metatag β†’ module. Create a Basic page, add an H2 element, save and observe that the generated ID will end in '--2'.

The assumed reason for this is that by default, and appropriately, Metatag uses the [node:summary] token (the summary portion of the body field) for the meta description tag. If no value is provided for the body summary field, a trimmed value of the body is used as the summary and this summary contains HTML which is stripped before being inserted into the meta description but apparently not before the auto-generated IDs are created by the Auto Heading IDs filter.

I have not tracked this down precisely and I am making some assumptions so if anyone has insight, it would be welcome.

Potential solutions that did not work:

  • Initially, I thought adding Html::resetSeenIds(); to this module's code prior to generating the IDs would work to correct this issue. Incidentally, this is being done in the module's tests. It did "work" but failed in situations where multiple fields with the same headings were added on a single page (with heading numbering resetting on each usage of the input format on a page).
  • I've tried using the Smart Trim β†’ module to strip HTML from the trimmed body field value in teaser mode, but this appears to again be happening later in the page render/load process than the Auto Heading IDs filter's ID generation.
  • Changing module(s) weight(s), which had no effect.
  • Creating a custom token in a custom module that takes [node:summary] and strips all tags from it and saves it as a new custom token which can then be used in the meta description field. In doing so I confirmed that [node:summary] does definitely return HTML, but again, the problem persists, even using the new token as described here.
  • Adjusting the filter processing order in the input formats. Moving 'Automatically apply identifiers (anchors) to headings in content' to last has no effect on this issue.
  • Adjusting the heading tags passed to the XPath query in `filterAttributes()`.
πŸ› Bug report
Status

Closed: won't fix

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States komlenic

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¦πŸ‡ΊAustralia pingers

    I'm going to say this use case of rendering the same heading twice isn't something I'm going to support as part of this module unless someone writes a patch.

Production build 0.71.5 2024