Custom blocks not rendering for anonymous users

Question

I recently deployed an update to Drupal 8.6.3 from 8.6.2 on our Drupal-specific managed web host (Pantheon).

Unfortunately, I noticed after the update that our site's footer was missing, but only for anonymous users. This footer is made of custom blocks placed in a footer region.

The footer is only missing for anonymous users. When you are logged in, the footer blocks appear properly. I've tried clearing the cache, running cron, clearing the cache again, etc. There are no errors in the watchdog logs that look like they would relate to this problem.

I've tried several, escalating troubleshooting steps to fix the error. Here they are, in more or less the order that I tried them:

• I created new custom blocks (using the "basic block" type) in the footer region. For these new blocks, I left them to display the title. The content of the new custom blocks were not rendered for anonymous users, but the title of the block was rendered. To further test, I edited the existing custom blocks in the footer region to display the title. The title displayed, but not the content. This tells me that Drupal is aware of the custom blocks in the region, but not rendering their content for anonymous users.

• I then added the built-in login block into the footer. This rendered properly for the anonymous user. This tells me the problem is limited to custom blocks

• I then added new custom blocks, and existing custom blocks, with titles, to the content region. I wanted to disprove the idea that there was a problem with the footer region. Like earlier, content was rendered for logged in users, but not for anonymous users. This tells me that the problem is with the content of custom blocks for anonymous users, regardless of the region they're placed in.

At this point, I decided that the problem probably just wasn't my particular config, and I did some googling to see if others had encountered this issue.

I found a number of issues regarding updating from 8.3.x to 8.5.x, and certain update hooks not running. We had been a little behind on updates, and had updated from 8.5.6 to 8.6.2 about a month ago, and then to 8.6.3 last night. So I didn't think these would apply to my situation, but I looked at their fixes and tried them if I could, anyway.

• Basic Blocks are not visible for Anonymous users

When I looked at the databse, all of my block content and revision statuses already had the value 1. For testing's sake, I did the update anyway. Still no blocks.

• Core update from 8.3.x - 8.5.x Manual Process

A commenter linked this from the first issue I looked at, so I checked it out. I didn't thing it applied, since we already had been running 8.5.6 for a while with no problem with our blocks. I didn't have these fields in my block_content_revision table, but when I added them, it didn't fix the problem.

• Allow BaseFieldDefinition::setInitialValueFromField() to set a default value - this fixes issues with block_content_update_8400()

This seem to relate to schema update hooks for block revisions not having been run. For troubleshooting's sake, I set my block_content revision level to 0 to trigger a re-run of all the update hooks. This didn't resolve the issue.

In the issue queues that I looked at, there was also talk about the translation module. We don't have that enabled on our site.

So my site has a major issue, and it's kind of ruining my holiday. Any help would be appreciated!

Edit We rolled our site back to 8.6.2, restoring from a backup. custom blocks still not rendering. So, it seems that the core update was not causing the issue.

If anyone knows where to start adding debugging code into core to debug on local, please chime in.

Edit 2 I've recreated the problem both on my home and work computers.

Edit 3 As suggested in two separate comments, I've tried switching the theme to Bartik, and also disabling both the Page Cache modules (and clearing the cache afterwards). After creating and placing a brand new custom block (for a clean-ish test) with the title showing in two separate page sections, I still get the same behavior: for logged in users, I see the custom block title and content. But for the anonymous users, I see only the title of the block.

Edit 5 At Kenorb's sugggestion, I looked to see if we were running any block permission modules. We are running block_content_permission and block_region_permission (however we are not running the block_access module). I looked into these, and they seem to only provide permissions for administration and editing of blocks. There was one permission that looked relevant-- View restricted block content. I enabled it for the anonymous user, but that didn't fix the problem. To test more robustly, I disabled both of those modules on my local, and again, no fix.

Edit 6 regarding more suggestions: updb has been run. I tested this on a fresh local backport, No database updates required. Text filter format for blocks is Full HTML.

Edit 7 re: Block visibility: there doesn't appear to be any restrictions on the problematic blocks. (Also, when I test by adding new custom blocks, I'm not adding any restrictions to them, and their title is displaying anyway). This is a screenshot:

Edit 8 I also tried the patch, again on a new fresh backport, that kenorb suggsted:

$ git apply -vv 2997898-21.patch
Checking patch core/modules/block_content/block_content.install...
Applied patch core/modules/block_content/block_content.install cleanly.

$ drush @local.ccad updb
The following updates are pending:

block_content module :
  8601 -   Set 'reusable' field to '1' where it is NULL.

Do you wish to run all pending updates? (y/n): y
Performing block_content_update_8601                         

But sadly, again no luck : (

Answer 1

So it turns out that I misconfigured permissions on the body field of my basic block block type. I had meant to restrict permissions for it on another block type. Unfortunately, I didn't notice this when I first rolled out the configuration export to production.

Edit thanks to everyone who commented with suggestions. It feels good to know that people were trying to lend a hand and I wasn't alone in trying to figure this out.