Problem/Motivation

Hello,
After updating the core from 8.5.6 to 8.6.0, the custom block library appears empty. Custom block types still exist, but the custom block list is empty. Yet, they still exist in the database.

On the Block Layout page, custom blocks are listed in their place in the regions, but they do not appear with the message :

This block is defective or missing. The content is missing or you may need to activate the original module

.The TypedConfigManager.php file is identical to https://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Core/Config/Type... and I restarted the server without success.

The update operations for the blocks ran successfully :
block_content 8600 hook_update_n Add 'reusable' field to 'block_content' entities.
block_content add_views post-update Adds a 'reusable' filter to _reusable Custom Block views. _filter

The drush command php with

$ service=\Drupal :: service ('config.typed');
get_class ($ service);

return :

=> Drupal\Core\Config\TypedConfigManager {# 917
     + "_ serviceId": "config.typed",
   }

And after a press on entry :

=> "Drupal\Core\Config\TypedConfigManager"

Commenting out the line $context->setTypedDataManager($old_context->getTypedDataManager());in the core/lib/Drupal/Core/Plugin/Context/Context::createFromContext() file does not solve the problem.

Thank you for considering this case

Steps to reproduce

None have been provided for starting at install Drupal core

Proposed resolution

Workaround

Running this command drush sqlq "update block_content_field_data set reusable = 1;" | drush cr fixed it. From #9

or

the patch in #21

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ohmdesbois created an issue. See original summary.

ohmdesbois’s picture

Component: base system » block.module
larowlan’s picture

Have you run update.php?

larowlan’s picture

rick.kowal’s picture

I'm having the same issue

cilefen’s picture

Priority: Normal » Major
Issue tags: +8.6.0 update
ohmdesbois’s picture

Emptying the caches, updating the entities and the base do not solve the problem.
I tried to disable the modules one by one to determine which one is problematic, without success at the moment.

Blackice2999’s picture

Hi @all,

i solved this for my by editing the database manually. In 8.6.0 the column "reusable" in the table "block_content_field_data" has been added.
The value for new entries is 1 - the old entries have NULL

After setting this to 1 and a cache clear, it works like expected.

I think here is a update hook is missing to fix already existing block_content entities ?!

dcam’s picture

Component: block.module » block_content.module

We had this problem with all of our D8 sites too. block_content_update_8600() was run and the reusable field was added to block_content_field_data, but for some reason the field didn't get populated and all of the reusable field values were NULL.

Running this command drush sqlq "update block_content_field_data set reusable = 1;" | drush cr fixed it.

Unfortunately, I don't have any explanation for why the field doesn't get populated. I'm having difficulty locating the logs on the server.

dustin.gates’s picture

Thanks, dcam! #9 solved the issue for me as well.

I ran the update on my local with no problems, but ran into the problem when migrating the config changes to another server.

dkrockville’s picture

Hey, dcam, this solved our issue after an update of core from 5.7 to 8.6.1. Looked like several custom blocks were gone, but this fixed it. Thanks to all who contributed the solution.

mhmd’s picture

Thanks, dcam! #9 solved the issue for me as well.

robpowell’s picture

Hit this too, running the update statement worked.

Annelies Van der Wee’s picture

Thanks, dcam! #9 worked like a charm!

DamienMcKenna’s picture

Issue tags: +Regression, +Novice

So this needs an update script to set the "reusable" field to "1" if it's NULL:
UPDAT block_content_field_data SET reusable = 1 WHERE reusable IS NULL

DamienMcKenna’s picture

It seems that the problem stems from block_content_update_8600() in block_content.install.

DamienMcKenna’s picture

Version: 8.6.0 » 8.7.x-dev

Given that the field was added in block_content_update_8600(), I think it'd be perfectly fine to add a new update script to set the value, like I showed in the query above.

robpowell’s picture

Let's give this a shot. I am not sure if this is necessary but I copied it from block_content_update_8400():

  $definition_update_manager = \Drupal::entityDefinitionUpdateManager();
  $entity_type = $definition_update_manager->getEntityType('block_content');

  $database = \Drupal::database();
  $database->update($entity_type->getDataTable())

We could hard code the table name instead but kept it consistent incase I was missing a best practice.

robpowell’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 18: 2997898-18.patch, failed testing. View results

robpowell’s picture

Sorry about that, error in my patch. Let's try it again.

robpowell’s picture

Status: Needs work » Needs review
DamienMcKenna’s picture

alexandra.vecher’s picture

PtrTon’s picture

The provided patch works perfectly in my installation +1

volkswagenchick’s picture

Issue tags: +fldc19, +sfdug, +dcnj19

Tagging for upcoming contribution days.

stephencross’s picture

I cannot recreate this issue with the following steps:

1. Install 8.5.6
2. Create new custom block type
3. Create new custom block of new type
4. Place block on content region
5. Upgrade to 8.7
6. drush updb
7. drush cr

In 8.7, Blocks appear in regions and on Custom block library page. They can also be placed on other page regions.

shaung75’s picture

+1 for provided patch #21 solved the issue for me. Thanks!

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

zJoriz’s picture

Sorry for reviving this old case, but I have a somewhat extreme case of this problem... the entire block-content page is missing. Searching for anything containing block in the database yields no results. And yet the block module appears to be active on the Expand page.

EDIT: looks like I'm a retard. There's a separate module for custom blocks and the block library. Found that out after reinstalling Drupal.
My apologies for wasting your time.

robert_t_taylor’s picture

Thanks, dcam! #9 solved the issue for me, too! I can push to prod tonight after all.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

mradcliffe’s picture

I am removing the Novice tag from this issue because it isn't clear to me the status of the issue. There is a report of not being able to reproduce it in a later version, but also reports of successful patch. 8.5 and 8.6 are no longer stable release branches.

This probably still is useful for some site owners, but might not apply to Drupal 9.1 or 8.9?

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

NWOM’s picture

I had the same issue in a D9.07 environment. #9 fixed it perfectly. Thank you! Does applying the patch in #21 make sense still in a prod environment until it gets committed?

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Closed (cannot reproduce)

Closing out as cannot reproduce in D9.5

If you still feel this is an issue please reopen with updated steps and summary.

quietone’s picture

Issue summary: View changes

Updated the IS with the workarounds.

acbramley’s picture

Removing tag