[BUG] Blocks disappear after being edited because of visibility constraint "node_has_ancestor"

[bstrakosova]

Hi, I hope someone can help me with this issue:

Everytime I open the Configure block form of any block at Block layout page and save the form, it affects the visibility of the block. It seems like the block then only shows up on the front page. When I export the config of the block, I see this code at the end of the config in the "visibility" section:

node_has_ancestor: id: node_has_ancestor negate: 0 ancestor_nids: false parent_reference_field: field_media_of context_mapping: node: '@node.node_route_context:node'

When I remove the code and reimport the config, the Block behaves normally and is displayed where it should based on its visibility settings.

For example, when I go to block Main navigation on the Block layout page, click on Configure and then Save block, the Main navigation block disappears from all pages except from the front page.

Which version of Islandora are you using?
2.11.0

Which method did you use to install your Islandora instance? (manually, ISLE, playbook, etc.)
playbook

-->

[Natkeeran]

@bstrakosova
Can you please see if you can reproduce this issue in https://sandbox.islandora.ca?

[DonRichards]

We've encountered this issue several times before, so much so that a temporary fix was added to the isle-dc Makefile under the command "fix_views". This command initiates a bash script, patch_views.sh, which retrieves a list of enabled views and then disables and re-enables them, similar to the approach you're taking.

Isolating the issue has been challenging, but my best guess is that it stems from how Drupal Views can depend on fields, entities, or functions provided by other modules. When editing configurations—whether manually, through the UI, or during a config import—problems can arise if these dependencies aren't loaded or recognized correctly. Resetting the views can sometimes help Drupal to properly resolve these dependencies.

Additionally, Drupal's configuration system, which manages settings for modules and components including views, might experience mismatches. These mismatches could be corrected when a view is disabled and then re-enabled, as this process triggers a re-import of the view's configuration.

Occasionally, conflicts between modules or specific bugs in the code can cause issues with views. Disabling and enabling the view might temporarily bypass these conflicts or bugs due to changes in the initialization sequence or by resetting internal states.

[bstrakosova]

@bstrakosova Can you please see if you can reproduce this issue in https://sandbox.islandora.ca?

I wasn't able to reproduce it in the sandbox. But I did find out what the issue was. I removed the Repository Item content type, including field_member_of. So the default value in Node has ancestor - Direct parent reference was field_media_of, which caused the issue. I recreated the field_member_of and everything works okay now.

[rosiel]

I created a PR, linked above, that would just remove this filter from the block placement list. That's what we do for several other of our filters that were designed to be added from the Contexts Conditions menu, and don't work (as evidenced here) under Block Placement.

If anyone has a better solution for this or for all our conditions, I'd love to see a PR. But the one I posted could be applied as a patch if you need a quick fix for this.