Incorrect behaviour for block page visibility

This is not merely unintuitive/confusing, if this problem occurs, the UX is telling people they do not even need to look at this (as noted by geekygnr in #24 🐛 Incorrect behaviour for block page visibility Needs work and alison in #26 🐛 Incorrect behaviour for block page visibility Needs work ).

1. Leave "Pages" blank.
2. Have the "Show for the listed pages" and "Hide for the listed pages" radio buttons set to "Hide for the listed pages"
3. The summary of Visibility will tell you Pages are "Not restricted" when in fact it is restricted so severely it will not show on any page.

Given that fixing this ought to change the behavior in the edge cases of blank lists, we should make that change, and so will also need an update hook to do so.

Even if we do not change stored configuration we should have an update that provides a link to the change record informing people the user interface behavior has changed (whether anything is updated or not). The update hook should further specifically alert people that the configuration they have may be leading to an unexpected result of hiding their block from every page, if they have 'negate' ('hide_on_pages' => 'Hide on specific pages') checked and the Pages textarea blank.

If we don't want to allow such a confusing case (the default of displaying everywhere is fixed by the 'Show on all pages' radio button in the patch) then we need a fourth radio button 'Hide on all pages' or we need to update such blocks to be disabled. (The latter is better in my opinion, provided we let people know which blocks were in such a state. But i'm not sure how that would interact with other visibility display settings, let alone more complex modules like Block Visibility Groups.)

Where does the logic to invert the standard behavior for a blank list actually happen? I know it's sort of common in Drupal but whenever it is also paired with 'Negate the condition' the double negative (negate an empty list that is interpreted as everywhere == hide everywhere) is bound to be counterintuitive anywhere it comes up. I cannot find it in core/modules/system/src/Plugin/Condition/RequestPath.php or core/lib/Drupal/Core/Condition/ConditionPluginBase.php (which provides negate as a default option) nor in core/lib/Drupal/Core/Path/PathMatcher.php.

Block visibility based on Vocabulary (using core/lib/Drupal/Core/Entity/Plugin/Condition/EntityBundle.php i think) has the same odd behavior (you can select nothing at all, choose negate the condition, and then the block is hidden everywhere) but at least it doesn't set any expectations at all— no help text at all and no summary in the vertical tabs!

Some or all of my comments are probably for follow-up issues. A lot of work has been put into this, especially by paulocs; it would be wonderful to get this across the finish line.

MR has conflicts even with 9.x (but also needs to be redone against 11.x) -- anyway, adding "needs reroll" tag (right?)

I don't think I did it particularly well but I have started a re-roll to 11.x

Testing the UI I think it is working as expected but there is probably still a lot of fixing to do.

I cherry picked the commit but the merge conflicts were difficult to resolve. It will need additional work.

I rolled out the 11.x fix and got all the tests to pass.

samit.310@gmail.com → made their first commit to this issue’s fork.

fixed test cases. Please review.

Thanks
Samit K.

New schema option means new config key so an upgrade path will be needed. And probably a number of block config files in core that will need to be updated.

I created a simple block to see what the new config should look like for all the core install profiles and unless I missed something in the comment history I think we might want to think about what we do here.

visibility:
  request_path:
    id: request_path
    negate: true
    context_mapping: { }
    pages: '<front>'
    page_options: hide_on_pages

There being both a negate option and a page option that says "hide_on_pages" seems confusing and redundant when compared to the UI.

I am still thinking through what I would propose as a solution. Maybe someone else has a suggestion.

Right now, the UI is confusing. It does the exact opposite of the plain-language meaning of the UI text. Fixing that should be the priority.

This can be done without an update hook or any changes to the config schema. Just have the UI display what will actually happen using radio buttons for "Show on all pages" and "Hide on all pages" whenever the list of pages is empty.

It would make sense to have an update hook that would convert "Hide on all pages" to having the block be disabled. Getting that implemented is more complicated. It should not hold up getting the confusing UI fixed. A change like that should be in a follow-up ticket.