#Needs issue summary update

Been having this issue.

I can recreate by creating a queue, adding all nodes, and rendering them. Most of my content types use a taxonomy vocab and probably like 90% use the default term. That default term also has a media attached to it.

Code isn't too bad,

- a large amount of nodes
- load them,
- then,

        $view_builder = \Drupal::entityTypeManager()->getViewBuilder('node');
        $render_array = $view_builder->view($node, 'default');
        $output = \Drupal::service('renderer')->renderInIsolation($render_array);

After like 25 nodes, it starts throwing errors. After banging my head, found https://www.drupal.org/project/search_api/issues/2913931 → which lead me to this issue.

@jonathanshaw in #183 has the best, most succinct description,

> we don't have a recursive limit, we have a repeated rendering limit.

Languages is one thing, but definitely not the only thing to consider. We need a better mechanism to map the references.

Forgot about this. Rerolled, still needs docs update and a change record.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Can we close this now that the referenced issue is in?

This one still relevant?

@kthull failing an automated test isn't the end of the world. There are often false positives. Of course it is easier if the automated tests pass.

Interesting to consider though if role=status would be sufficient substitution. Worth looking into a bit more. Thanks!

Having h2s prior to a page's h1 is not a big deal. In the case of messages, they're not really sub-sections of the page's topic anyway, right

Failing WCAG checks is the current issue I'm facing, so from that point of view, it's problematic. An element with role=status already gets announced as if it were aria-live=polite which makes the h2 overkill.

From Google search summary:

When a heading is not necessary
If the role="status" area provides a short, simple update that doesn't require further breakdown or organization (like a progress bar), a heading might be redundant or even disruptive to the user experience, according to MDN Web Docs.

When a role="status" message is intended to be self-contained and not part of a larger, navigable section, a heading might not be necessary, says the W3C.

I'd vote to keep the H2. Sub-themes might place this block in other regions.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

My inclination is to keep the h2s.

• Having h2s prior to a page's h1 is not a big deal. In the case of messages, they're not really sub-sections of the page's topic anyway, right?
• If the messages are contained within a named landmark (e.g. div role="region" aria-label="System messages", there's already semantics present that are useful for navigation. However, surveys show headings are used far more than landmarks by screen reader users for navigation.

Bumping one more time.

Since there's been no follow up going to close this one out. If still a bug in D11 please re-open

MR updated for Drupal 11.x.

jan kellermann → made their first commit to this issue’s fork.

Very cool @itmaybejj

So we can close this when Editoria11y becomes part of Core?

Is it better to loose the semantics by dropping the H2 or to retain the heading order? I'm not sure.

Can confirm that MR works on D11.2.2

Thanks for the static patch @Rajab Natshah

Attached a static drupal-core--2025-07-09--3049332--mr-12460.patch file, to this point of MR12460.
To be used with Composer Patches to patch Drupal ~11.2.0

In addition to the role, we should also change the `h2` element to a `div` element. Looking at Olivero on a stock Drupal install, the error message renders before the `h1` thereby breaking the heading order.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

I like your suggestion around use of mask-image or mask @kentr.

Committed and pushed 72c39ca98ec to 11.x and dce32095c10 to 11.2.x and 0f3a62ab851 to 10.6.x and f0525143a35 to 10.5.x. Thanks!

nod_ → closed merge request !11394

Let's actually fix the return type. At the moment this methods returns string numbers ie. '0' or '1'... however in node_access_view_all_nodes() we claim it's returning a bool.

In the core use-cases we are using the return value in if statements therefore I think we should update the implementation and documentation to return bools. This has come up in 📌 Deprecate node_access_view_all_nodes(). Move its functionality in NodeAccessControlHandlerInterface Needs work

Yes agreed, closing this as duplicate of 📌 Slowly, very slowly start OOPifying the render system Needs review . Part two is 📌 [PP-1]Allow RenderableInterface objects to be passed as the $elements parameter in RendererInterface::render* methods Active and will be more after that. This issue pre-dates the issue credit system, so just going to close it out.

We managed to finally make progress here via 📌 Slowly, very slowly start OOPifying the render system Needs review . IMO this issue is so outdated it can be closed.

Re-roll patch #17 for 11.2.x

I've tried the patch, but as with my hack, I get my homepage showing as http://mysite.com/mypathalias rather than http://mysite.com/.

Making good progress on theme.inc, down to 5 functions!

Besides UncaughtExceptionTest the other replacements seem fine. Think this one should be one that remains as FormattableMarkup

Automatically closed - issue fixed for 2 weeks with no activity.

Let's close this as outdated, as the main point was about the weird dependencies. Now that trait has been moved, that's no longer a problem.

I'll open a new issue about the strip_tags() thing.