Unable to place blocks

[Natkeeran]

Have the latest claw-playbook (commit 5d573ff8828353997a7d3f2e11405956b5dbb138). Not able to place a block on the first side bar other than the Tools block.

Steps to Reproduce

• Go to blocks http://localhost:8000/admin/structure/block
• Place an existing block on one of the block areas (ex Main navigation in sidebar first)
• Save

Expected

• Block to show up in the home page

Actual

• Block is not showing up in home page

Additional Notes

This may be issue related to an earlier issue related to placing blocks. Or it could be a Drupal 8 regression issue!

[MarcusBarnes]

I built a new CLAW instance from the latest CLAW playbook and can confirm this behaviour. Another simple way to test is to take an existing block on the landing page, move it to a different region. It will not appear. If you try to move it back to the original region, you will not be able to put it back.

[dannylamb]

I can also confirm this behaviour. I'm going to investigate our latest condition we made (Content Entity Type) and see if that's the culprit.

[dannylamb]

Yeah, wow, weird. I tried what @MarcusBarnes described and found I could move existing blocks into a handful of regions, but not others. It doesn't like the sidebars, for example, but the header was ok. New ones seem to be prevented altogether.

I switched to Stark to see if it was a theme issue and it's not. I can recreate the behaviour.

dsms in ContentEntityType don't even seem to fire for core block placement. Context will trigger them on conditions which should fail (and they do), but I cannot get a failure message out of the condition when doing core block placement.

[dannylamb]

Tests out OK in vanilla Drupal, so it's definitely something in islandora. I'm enabling just the core module and feature and seeing if it's still broken. Trying to isolate code from demo module config.

[dannylamb]

All it takes is the islandora module. Doesn't even require a feature to be imported. So it's gotta be one of our Conditions. I'm going to try pulling them out one by one and see if i can isolate the culprit.

But sheesh, this bug is totally silent. No logs of any kind.

[dannylamb]

So when a block gets saved, our conditions go right into the visibility chunk of their yml:

visibility:
  node_has_term:
    id: node_has_term
    negate: false
    uri: null
    context_mapping:
      node: '@node.node_route_context:node'

That seems to cause drupal core to not show the block, and squash any errors that may exist.

I'm going to revisit some core Condition plugins and see what's up. We must be diverging somewhere in 8.6.

[dannylamb]

So core block_form code gets all Conditions that are "ContextAware" and adds their config when you submit the block placement form. A lot of our Conditions aren't really meant for block placement, and shouldn't be included there. The least complicated way I've found to do this is to simply form_alter them out. They'll still be available in /admin/structure/context if you want more sophisticated block placement.

This won't fix a broken block, but all blocks placed after the alter is implemented is fine.

I wouldn't say this 100% solves the problem. I'd keep my eye on https://www.drupal.org/node/2284687, which is the core Drupal issue to control which conditions get displayed for block placement. Or at least to better improve the UI when # of conditions gets unwieldy.

[dannylamb]

^^ PR is up. Plugging the leak... 🚢 💧