🇺🇸United States @bdanin

@agbuckus, when testing the latest beta2, I'm able to add new tokens using underscores. The check now allows underscores for new tokens as well as existing it seems.

Confirmed the commit from #6 fixes this issue against the latest beta.

Not being able to edit existing token content is really problematic. I think this update should be reverted. See https://www.drupal.org/project/token_custom/issues/3507564 🐛 Can't edit existing tokens after beta1 update Active

We have a bunch of tokens with underscores created over many years, inside of blocks, paragraphs, nodes and used across thousands of pages + revisions. I'm not sure why underscores are suddenly no longer allowed. We cannot edit content inside these existing tokens, so we are going to downgrade to an older version of this module before this unexpected forced formatting was created.

Version 8.x-1.0-alpha5 worked. This issue should be reverted for now: https://www.drupal.org/project/token_custom/issues/3093275 🐛 Token (& token type) machine name requirements RTBC

mcdruid → credited bdanin → .

pameeela → credited bdanin → .

liberatr → credited bdanin → .

Yes that is the issue. How would a user know they have to collapse the sidebar menu in order to be able to use the preview functionality? This is not clear and was confusing me and a number of other people. By default the side menu is expanded as well, so you have to proactively collapse the sidebar menu for this to work.

I appreciate the screenshot. Myself and others don't seem to have that link. Attaching a screenshot from my FireFox browser install of Starshot.

bdanin → created an issue.

bdanin → created an issue.

bdanin → created an issue.

Once again hit the error Twig\Error\RuntimeError: The "Drupal\Core\Template\TwigExtension" extension is not enabled (see #8) and I replaced the patch I was originally using in #6 with the patch provided in #21, which is working for me in 10.3.6 using twig_extender.

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