I suggested this feature originally in #2450637: Block page visibility option "Show for the listed pages" does not appear to save for better UX when saving a block's page visibility with a path and the option "Show for the listed pages" selected. As a result of that bug fix, the form then presents a counter-intuitive negate selection if the page textarea input remains empty.
In other words, I can see user confusion if the pages textarea input is left empty ( no paths are added ) and the radio option "Show for the listed pages" is selected. While this radio option translates to FALSE negate condition as opposed, I can see how one might read the settings this block will NOT show any pages b/c no paths are provided.
To remove this confusion, I suggest adding #states to the negate form element to show/hide when pages form element is not empty.
Before
After - empty
After - with path
None
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 2557319-17.patch | 1.65 KB | quietone |
| #17 | Pages-after-not-empty.png | 30.94 KB | quietone |
| #17 | Pages-after-empty.png | 25.86 KB | quietone |
| #17 | Pages.png | 33.08 KB | quietone |
| #5 | hide_show_block_page-2451461-5.patch | 1.13 KB | tim.plunkett |
Comments
Comment #1
jasonawantHere's a patch for review. Feedback welcomed. Thanks, Jason.
Comment #2
wim leersLet's use
[]instead ofarray().Looks great though :)
Assigning to Tim Plunkett for review, to make sure this is the right place to do this.
Comment #3
wim leersComment #4
jasonawantHi,
Thanks for reviewing! Here's another patch using [] instead of array() syntax.
Comment #5
tim.plunkettI think this should be part of the request path condition form always, not just when it is used in the context of blocks.
Comment #6
jasonawantHi Tim,
I tested this out, it worked great! However, I discovered that negate element may need to be required.
While testing, I entered a value into the pages element, and then I could submit the form without actually selecting a negate option. Thoughts?
Jason.
Comment #7
star-szrComment #16
markdcReferencing another issue that resolves this by restoring the familiar negate checkbox.
Comment #17
quietone commentedTwo weeks ago the Bug Smash triage looked at block visibility issues and this feature request was accidentally included and got a review although not yet documented - I am doing that no. Adding tag.
The review suggested that this issue and #2301625: Incorrect behaviour for block page visibility need a Usability review to decide on what should or should not be done to clarify the 'Pages' section of block visibility. Then work will continue on their recommendations.
I have updated the patch and made before and after screenshots to help that review. Adding tag.
I'll ask in #ux for a review once I finish updating #2301625: Incorrect behaviour for block page visibility .
Comment #18
benjifisherUsability review
We discussed this issue at #3239070: Drupal Usability Meeting 2021-10-01. That issue has a link to a recording of the meeting.
I am closing this issue as a duplicate of #2301625: Incorrect behaviour for block page visibility, which discusses several different solutions to the same problem that this issue addresses. The usability group preferred one of those solutions to the one here.
Here is one problem with the solution proposed here. Suppose a site administrator wants a block to be shown on every page except three. They might give up on the task, not wanting to type in paths (with wildcards) representing all the other pages. The problem is that, until they start typing, they do not see the "Hide for the listed pages" option.