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
Comment | File | Size | Author |
---|---|---|---|
#21 | 2997898-21.patch | 884 bytes | robpowell |
#18 | 2997898-18.patch | 884 bytes | robpowell |
Comments
Comment #2
ohmdesbois CreditAttribution: ohmdesbois commentedComment #3
larowlanHave you run update.php?
Comment #4
larowlanRelated #2997807: Can't place blocks to regions after upgrade to 8.6.0 ?
Comment #5
rick.kowal CreditAttribution: rick.kowal commentedI'm having the same issue
Comment #6
cilefen CreditAttribution: cilefen as a volunteer commentedComment #7
ohmdesbois CreditAttribution: ohmdesbois commentedEmptying 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.
Comment #8
Blackice2999 CreditAttribution: Blackice2999 commentedHi @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 ?!
Comment #9
dcam CreditAttribution: dcam commentedWe had this problem with all of our D8 sites too.
block_content_update_8600()
was run and thereusable
field was added toblock_content_field_data
, but for some reason the field didn't get populated and all of thereusable
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.
Comment #10
dustin.gates CreditAttribution: dustin.gates commentedThanks, 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.
Comment #11
dkrockville CreditAttribution: dkrockville as a volunteer commentedHey, 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.
Comment #12
mhmd CreditAttribution: mhmd as a volunteer and commentedThanks, dcam! #9 solved the issue for me as well.
Comment #13
robpowellHit this too, running the update statement worked.
Comment #14
Annelies Van der Wee CreditAttribution: Annelies Van der Wee commentedThanks, dcam! #9 worked like a charm!
Comment #15
DamienMcKennaSo 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
Comment #16
DamienMcKennaIt seems that the problem stems from block_content_update_8600() in block_content.install.
Comment #17
DamienMcKennaGiven 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.
Comment #18
robpowellLet's give this a shot. I am not sure if this is necessary but I copied it from
block_content_update_8400()
:We could hard code the table name instead but kept it consistent incase I was missing a best practice.
Comment #19
robpowellComment #21
robpowellSorry about that, error in my patch. Let's try it again.
Comment #22
robpowellComment #23
DamienMcKennaComment #24
alexandra.vecher CreditAttribution: alexandra.vecher at EPAM Systems commentedComment #25
PtrTon CreditAttribution: PtrTon commentedThe provided patch works perfectly in my installation +1
Comment #26
volkswagenchickTagging for upcoming contribution days.
Comment #27
stephencross CreditAttribution: stephencross commentedI 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.
Comment #28
shaung75 CreditAttribution: shaung75 commented+1 for provided patch #21 solved the issue for me. Thanks!
Comment #30
zJoriz CreditAttribution: zJoriz commentedSorry 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.
Comment #31
robert_t_taylor CreditAttribution: robert_t_taylor commentedThanks, dcam! #9 solved the issue for me, too! I can push to prod tonight after all.
Comment #34
mradcliffeI 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?
Comment #36
NWOM CreditAttribution: NWOM commentedI 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?
Comment #40
smustgrave CreditAttribution: smustgrave at Mobomo commentedClosing out as cannot reproduce in D9.5
If you still feel this is an issue please reopen with updated steps and summary.
Comment #41
quietone CreditAttribution: quietone at PreviousNext commentedUpdated the IS with the workarounds.
Comment #42
acbramley CreditAttribution: acbramley at PreviousNext commentedRemoving tag