drupal_block would be easier to use just with the id

Solved in merge request adding drupal_block_by_id() function.

This can be done as follows.
{{ drupal_entity('block', 'block_id') }}

Thanks Chi. However, drupal_entity() does not process the block rendering the same as drupal_block(). As a result, drupal_entity() bypasses the cache contexts while drupal_block() does not.

Right now users are facing the following problem:

1. Create a custom block and add it to the Block Layout page and configure it, disabled.
2. Add the block to twig template using {{ drupal_entity('block', 'my_block_id', check_access=false) }}
3. Go to the page and see the block appearing there
4. Edit the block, change some text or the title for example, and save
5. You will not see the changes appearing in the page!
6. Clear cache. Now you can see the changes

This shouldn't be happening, and I don't know if that has a solution inside drupal_entity() processing, or this is part of the way it is designed. If this have a solution, we should open an issue for that. But if not, the user is forced to use drupal_block(), and so for, users have to deal with the difficulty that I described in this issue and motivated me to contribute a solution.

Edit the block, change some text or the title for example, and save

Content blocks don't have titles. They have block description. That field is used as default value for the block in layout. Once you place the block into layout it'll use title from config block not from content block.
As of text (body). It should be updated automatically. I've just checked it using anonymous account. It worked well. The block rendered with {{ drupal_entity('block', 'my_block_id', check_access=false) }} was updated instantly upon changing the corresponding content block. If it doesn't work for you, please file a ticket with steps to reproduce.

Thanks for taking the time to review this.

Content blocks don't have titles.

Sorry I meant a custom field. I was using a custom block type and there I found the problem.

As of text (body). It should be updated automatically. I've just checked it using anonymous account.

The workflow would be to edit it from the page you are viewing (quick edit) with an authenticated and authorized account and then saving. It goes back to the main page, but not showing the changes, needs a cache clear.

Maybe something else from my site configuration and implementation is messing around. Maybe we don't need an issue because it is not a specific issue of this module. But the problem we are facing is that drupal_block() works well with cache where drupal_entity() doesn't. They do different things, from example, with drupal_block() you just have the option "edit" with quick edit, while with drupal_entity() you would have more.

So we need drupal_block() to avoid this cache problem, drupal_entity() is not exactly the same and doesn't work. And drupal_block() as it is painful to use for that need of the plugin, which requires to find the resource in the the config directory. drupal_block_by_id() work just fine, it's easy and straightforward, and it's adding value to the project. We could contrib a new module just with that addition (I already implemented it), but I thought this improvement would belong better to this original project.

What do you think?

Sorry I meant a custom field. I was using a custom block type and there I found the problem.

Any fields should update automatically when changed. If you develop a custom field plugin it needs to be supplied with correct cache metadata for the page to be refreshed.

The workflow would be to edit it from the page you are viewing (quick edit) with an authenticated and authorized account and then saving. It goes back to the main page, but not showing the changes, needs a cache clear.

Tested it with Quick Edit. Also worked for me.

I think you have some issues with your site configuration. Try to reproduce them on fresh Drupal installation.
So instead of creating a new Twig function I would figure out the caching issue. If it belongs to Drupal core or some contrib module it needs to be identified and reported.

Any rendered fields should be update automatically when changed. If you develop a custom field plugin it needs to be supplied with correct cache metadata for the page to be refreshed.

Thank you, but it is not the case.

Tested it with Quick Edit. Also worked for me.

I think you have some issues with your site configuration. Try to reproduce them on fresh Drupal installation.

Thank you for testing that. It also worked for me locally sometimes, not always, and never in our development server for example. So something else could be messing around.

What is true is that using drupal_block() solves this when this problem appears, so we can't use drupal_entity(). So that makes this new function simplifying drupal_block() signature a need.

Switching from drupal_entity() to drupal_block() does not just solve the caching issue. If also makes the blocks not to take the right template and configuration, so the blocks are not styled properly. This is because drupal_block() does not use the configuration of the block by default, you would have to provide it in the second argument.

In the solution I'm providing, I'm not only simplifying drupal_block() use by allowing to identify the block by id and not plugin. I'm also solving this problem by loading the configuration of the block by default, allowing it to be overridden.

I think all these improvements are really needed to make drupal_block() better and more usable.

Rendering blocks in Twig is not quite straightforward. I am afraid drupal_block_by_id will make things much harder to understand. Consider it's name. What does ID it mean in that context? Config entity ID, block content ID, plugin ID? It probably has to be named as drupal_block_by_config_id(), but that name is too long for Templates.

Note, that such function already existed in Twig Tweak 1.x.
https://git.drupalcode.org/project/twig_tweak/-/blob/8.x-1.10/src/TwigEx...

I dropped it in 2.x branch to make things less confusing. The current naming convention is that drupal_block for block plugins and drupal_entity for entities. The drupal_block_by_id will violate this agreement.

Thank you, I respect your decision.

I've released a module with this function so everyone can benefit of this improvement: https://www.drupal.org/project/twig_block_by_id →

Makes sense. Thank you.