Error: Call to a member function getCacheTags

Same issue here, from 8.x-4.0-beta2 to 8.x-4.0-beta5.

Can confirm this issue, from 8.x-4.0-beta4 to 8.x-4.0-beta5.

Ok, I had a context where a block was referring to a non existing context_id. I edited the config yml file imported it again and the problem was fixed.

Hi @all, could somebody with the issue, if still present, post steps do reproduce the issue?

Hello @all,
Did you run the update.php when upgrade it to the 8.x-4.0-beta5 version?

@Promo-IL and @elgandoz, can you see if the config yml from your context are referring to a non existing context_id like @robin.ingelbrecht said?

I got the same problem with one of my context, reviewing the conf file of the context the problem is in the context_id key, in my case the value was saved translated.

I've catched the error editing the context saving the block and reviewing the conf diff.

I believe this issue is related to #3122023: Notice: Undefined Index Errors All Over

We came across this issue too which brings the entire site down.

Here is a patch for a quick fix.

Todo:
A update hook to update all reactions in which the context id is missing.

Reopening this issue to draw the attention of the maintainers. This has broken multiple sites hosted on the GovCMS platform. Please review the provided patch.

The patch #13 is for 8.x-4.0-beta5 which doesn't fit in 8.x-4.x-dev.

Here is the patch for 8.x-4.x branch for now.

Patch for 8.x-4.0-beta5 with fixing to avoid PHP notice messages.

I ran into this when I changed the machine_id of a context after it was created and configured. In my case the context_id for the block reactions in the context configuration yaml file were still pointing to the old context machine id. Updating this to the new context id and re-importing resolved the issue.

Context_id is always required, so I do not see a need to check if is set, as it needs to be set. Following the steps that @sonfd provided, I could reproduce the issue on the edit context page itself. So if I have a context named test and I add a reaction block to it everything works, then I go back and I edit the machine name (with the click on the edit), then I get the above described error for the getCacheTags(). But that is because the test context entity no longer exists, but debugging it I still get the context_id, just not the correct/new one, but the old one.

I added additional check for the tags in $block_build to get cache tags only if context_entity is not null/empty, otherwise set empty array. Then the update of the new machine name goes through, with the "error page" of test context page not existing on the structure/context/test url/page, but with the message that test-new context was saved/created. If I then visit the structure/context/test-new, everything is working normally, with no errors.
But the issue here is, as also @sonfd describes, that the blocks reaction is still pointing to the old context_id, which means the $context_entity is still going to be null/empty, even tough for some strange reason the reactions are displaying correctly. If you then go to the block click on edit and update the block, it updates to the correct context_id for the block reactions.

So the question here is, should the module/code handle that update after a machine name change (without additional updating of the blocks by user), or if that falls on the user end?

#16 - context-3173470-16.patch worked for me. Added the patch to my composer.json. Composer install etc.

I had the exact same error as listed above. It only effected one content type, event.

Update #16 worked for me as well.

I tested #18 and it looks good.

I agree with @DeaOm. And in my opinion we should update the block context_id when the context machine name is changed.
I pushed a commit so it can be done.

I also think we can keep the verification in line 255 from Drupal\context\Plugin\ContextReaction\Blocks.php so it will prevent the errors.

Latest changes (Merge request !7) worked for me.

The added hook_ENTITY_TYPE_presave() updates the block_id after a machine name change, which can also be seen with the exporting of the configuration, so marking this as RTBC.

Small change so $context->save(); is not called unnecessarily.

I revert the commit because it doesn't work.

I merged it into the last dev version.
Thanks!

Patch #16 also fixes an undefined index error, which is reported by

https://www.drupal.org/project/context/issues/3204399#comment-14074606

It seems that that issue still remains.

Is it considered?

It seems is still an issue so I have created another patch that can be applied to the latest context version (8.x-4.1 as of the writing of this comment)