🇺🇸United States @bdanin

Confirmed the MR fixes the issue for me as well.

Thank you, confirmed this patch works and removes the warning.

bdanin → created an issue.

This worked for me as well.

This isn't really fixed though, it should probably be closed (won't fix) or closed (duplicate).

This makes sense, I assume it will likely work when https://www.drupal.org/project/simple_sitemap/issues/3034070 → is implemented, hopefully at some point this upgrade is made.

bdanin → created an issue.

Changes we make to the XML sitemap in the vertical tabs, we would like these changes to show up in revision diff. Attached screenshot.

bdanin → created an issue.

Confirmed, the patch in comment #6 fixes this issue for me. I am also running twig_extender → .

The patch in #27 works for me. It would be nice if there was an option to output ALL tags, instead of having to add a field for each.

Also, it would be ideal to see the tokens, and not what is rendered as an option.

Finally, to know whether or not nothing is entered and is empty. That's how the formatter in the related ticket worked, which provided a lot of benefit.

See:
https://www.drupal.org/project/metatag/issues/3172117 ✨ Add field formatter to view which metatags are being rendered Closed: duplicate

see:

Thanks, this gets close, but not all the way there. For one thing, I noticed that I needed to use block__block_content_ instead of block__bundle__ to keep my existing template suggestions the same between the module and this custom theme hook.

One issue is that the previous hooks, provided by the module output this:

   * block--block-content-BLOCK_NAME--full.html.twig
   x block--block-content-BLOCK_NAME.html.twig
   * block--block-content.html.twig
   * block--block-content.html.twig
   * block.html.twig

But the custom hook in this example misses the display type template (--full).

vs.

   * block--block-content.html.twig
   x block--block-content-BLOCK_NAME.html.twig
   * block--block-content.html.twig
   * block.html.twig

I'm not actually using the display mode for any of my templates, so losing this suggestion seems ok for my uses, but wanted to point this out in case it affects other's use cases.

Here is what I'm using currently:

/**
 * Implements hook_theme_suggestions_HOOK_alter() for form templates.
 * @param array $suggestions
 * @param array $variables
 */
function YOURTHEMENAME_theme_suggestions_block_alter(array &$suggestions, array $variables) {
  // Block suggestions for custom block bundles.
  if (isset($variables['elements']['content']['#block_content'])) {
    array_splice($suggestions, 1, 0, 'block__block_content_' . $variables['elements']['content']['#block_content']->bundle());
  }
}

The 1.4.3 version simply does not work for me in my Drupal 10 site. The dev version does. I don't understand how a module not working vs. actually working isn't a big enough change to warrant a new release.

To me, this represents a very remarkable change and it would be great if there was a new version. It will likely help others not have to track down this issue and then apply patches or change to a dev version of the module as well.

When will a new release be created that incorporates this fix? I have run the dev-1.4.x version of the module and it works, so it would be really nice to have an official release and not run the dev version in production.

It's unfortunate there isn't a release for this. For now in my composer.json I have this under the require key:
"drupalcode/block_type_templates": "3286293",

And then under repositories, I have this:

        {
            "type": "package",
            "package": {
                "name": "drupalcode/block_type_templates",
                "version": "3286293",
                "type": "drupal-module",
                "source": {
                    "url": "https://git.drupalcode.org/issue/block_type_templates-3286293.git",
                    "type": "git",
                    "reference": "3286293-6"
                }
            }
        }

It's unfortunate there is still no release and the EOL for Drupal 9 is a couple weeks out.

For now, I have added this to my composer.json require key:
"drupalcode/twig_extender": "dev-5.0.x"
and then down under repositories

        {
            "type": "package",
            "package": {
                "name": "drupalcode/twig_extender",
                "version": "dev-5.0.x",
                "type": "drupal-module",
                "source": {
                    "url": "https://git.drupalcode.org/project/twig_extender.git",
                    "type": "git",
                    "reference": "5.0.x"
                }
            }
        }

@adriancid thank you so much for reverting this until further testing can ensure existing installs don't break the UI of active sites. I always support the addition of improved accessibility, so thanks for the continued effort.

At this point I can install the latest stable release without issue on my site :)

It's a paragraph inside a block that's loading.

This still errors for me with a nested paragraph:
ResponseText: Error: Call to undefined method Drupal\block_content\Entity\BlockContent::getParentEntity() in Drupal\scanner\Plugin\Scanner\Paragraph->search() (line 73 of /app/docroot/modules/contrib/scanner/src/Plugin/Scanner/Paragraph.php).

This adds a bunch of extra icons that overlap each other, unexpectedly. I've attached a screenshot. This is a fairly disruptive change. I will lock my admin_toolbar to 3.3.0 until this can be readily resolved. Otherwise, I have to add custom CSS to undo whatever change this is. Ultimately the same issue as How to remove newly added blue arrows at top level of menu ✨ How to remove newly added blue arrows at top level of menu Closed: duplicate , and reported a few times in the issue queue of this project.

This is useful for me. I need a view that shows all the posts/nodes and their respective meta description and titles. This is important for content authors looking at a bunch of posts. I have a view of several hundred blog posts, and we want to see their display titles, along with their authored meta titles and descriptions. This patch accomplishes this need.

It would be great to see this adopted and added to the main module.

The patch in comment #314 applied cleanly for me in the latest Drupal 9.5.x