On a Drupal 8 site, I see an error on a block which says:
This block is broken or missing. You may be missing content or you might need to enable the original module.
How can I resolve this error?
Add a comment
|
8 Answers
You have created a Custom block and the custom block was placed in a region, then you lost the custom block maybe was deleted or you made a Config Export from one environment and a Config Import in other. So the custom block is no longer exists but in the Block layout page (admin/structure/block), the references exist.
So, remove the missing Block from the Block layout page (admin/structure/block) and create again the Custom block and place it again in the region.
There is a core issue open discussing this problem: https://drupal.org/project/drupal/issues/2756331
This can also be overcome by using this module: https://www.drupal.org/project/recreate_block_content
answered Jan 31, 2018 at 19:17
-
1Thanks, What can be done to resolve the issue? Do I need to recreate the block with same ID/class? Jan 31, 2018 at 19:20
-
1
-
1Thanks for the suggestion, I will try this out and let you know. Jan 31, 2018 at 19:24
-
1The problem here is that the instance of the block is content while the configuration of the block is config. This means that the block itself doesn't get transferred between environments while the config for the block does. I'm pretty sure there is a Drupal Core issue about this somewhere. Jan 31, 2018 at 19:25
-
4@lukedekker This is the core issue: drupal.org/project/drupal/issues/2756331. Someone's written a module to help with the process in the meantime: drupal.org/project/fixed_block_content– Clive ♦Jan 31, 2018 at 20:02
The placement of the block is stored as configuration. This is what gets exported and synced between environments. The actual content of the block is considered exactly that: content. This means that when you import your new configuration into a different environment (or delete the block and then re-import the configuration) there is a mismatch between the configuration for the block and the actual block instance (which no longer exists).
To resolve this issue, you simply need to delete the configuration for the missing block and then recreate the block. This allows your site to resolve the discrepancies.
Another option would be to use the fixed_block_content contributed module to manage this process for you.
There is a Drupal Core issue discussing this very thing. https://drupal.org/project/drupal/issues/2756331
I had the same problem with Views. After trying a different theme, some of my Views blocks were gone. I checked and the actual Views was disabled. I was able to restore it by going to the views page and "enabling" the Views and all the blocks displayed as expected.
-
That is right, thank you, your comment helped me. I was pulling my hair because the blocks in my view simply wouldn't display as available in the blocks admin interface. After I read your comment, I checked and... That was the reason, the view had been disabled by Drupal (I don't know exactly why, but I think it had to do with a field I had deleted from my content type, but was still available in the view). Nov 30, 2019 at 14:26
This happens because when a block is created, a unique id is generated (uuid). This can be seen from the block_content table.
A custom block is a piece of content similar to a Node, so if you create a block in one environment (dev for example) and recreate the block manually on a different environment (Production or QA). The block will have a different uuid.
The Configuration Synchronization will be looking for an uuid that doesn't exist. In order to fix this, you need to import the data from the database. Or simply update (id and uuid) on the following tables:
block_content;
block_content_field_data;
block_content__body;
block_content_field_revision;
block_content_revision;
block_content_revision__body;
I encountered this myself, using modules or patches did not work for me.
Doing the Database fix route, thinking this has something to do with UUIDs or IDs. Everything seems fine.
What worked for me to fix this is to modify the block_content_field_data table and made sure all the existing blocks for the field reusable is not NULL
Then do a cache clear for the site and you'll see the missing custom blocks. So far this workaround worked for me.
Oh and i'm at 8.6.13 at this time.
My problem was caused by a block existing only on dev and then configuration pointing to a block that did not exist elsewhere. It came up in Layout Builder. I'm on Drupal 8.7.6 and I was able to simply go in to the layout builder, remove the bad block reference, re-add the correct block and the problem was solved. I just had to be sure to re-export my configuration and update my repo so as not to recreate the problem.
(Expanding on Marcelo's answer)
Steps to reproduce:
- Block is created
- Block is added to Block Layout
- Configs are exported
- Block is deleted (or does not exist on target)
- Configs are imported to target
- Import contains: [warning] The "block_content:[UUID]" was not found
Steps to fix:
- Copy the uuid from the error
- Find the correct block in the database table - block_content*
- Update the uuid of the block in block_content with the one from the error
- Make sure the block is removed from the Block Layout
- Re-import configs
*It can be difficult to figure out which entry in the block_content table is the correct one. If necessary, copy the block data and metadata somewhere, delete the block and then re-add it. The highest id number in the block_content table will now be the newly created block. Change the uuid on this entry.
Make Sure the BLOCK ID is the same as in the productions database.
I solved this issue which occurs while importing the production database to lower environments by deleting the block and creating/configuring it again with the same block id that is in the production database.
