Expose Fields to Visibility Conditions

[philsward]

Description of the need

Long story short, I'm coming from D7 Panels to BackDrop Layouts. It's a bit of an adjustment, but I'm finding that "most" of the things that are done in Panels, can be done pretty easily in the BackDrop (BD here out) Layouts. Except for visibility conditions on Fields.

I started a discussion on Zulip to see if this was possible; I was given some direction and found that it is not possible to expose visibility conditions on blocks from individual fields. Full discussion can be found on Zulip: https://backdrop.zulipchat.com/#narrow/stream/218635-Backdrop/topic/Panels

If you're familiar with Drupal 7 Panels, you add a field as a "panel pane" into the panel. Once it has been placed, you can add what's called a "Visibility Rule" which is a lot like the BD "Visibility Conditions". The one difference is that the panels visibility rules will expose any field as a visibility condition, based on the criteria of any other field. This allows for some crazy powerful output of the node based on the criteria of the exposed fields data.

I have views added to the Panel variants where a visibility rule is set to show or hide that view based on the value (or empty/null value) of a particular field. I also have fields that are set to show or hide based on the value (or empty/null value) of another field.

For example, let's say you have an image field and a dedicated text field that is a short description of the image. If the image doesn't exist on that page, then why show the description? With panels, you simply set the visibility on the description field to "show if -> image field NOT empty". It's a loose example, but gives the point.

Proposed solution

What we need is a block visibility condition that is tied to the fields and their field data within the layout context.

This should probably mirror the way Panels does it: 1) A setting where the condition either matches to one condition or all conditions. (1 must pass or all must pass) 2) A Boolean value to check against true or false. Example: "Field data contains -> apples" vs "Field data NOT contains -> apples" 3) Needs to accept empty/null data values (very important for my workflow). Example: "Show if NOT Empty". I use this regularly for entity reference fields and paragraph reference fields where I hide the entire pane (block) if they are empty. This cuts down the output of the page by processing it, finding the stuff that doesn't need to be added to the ouput, then only showing the stuff that actually needs to be visible. Otherwise, I end up with a bunch of empty DIVS in the HTML. "If it doesn't have data, then don't show me in the html code where it's supposed to have data."

Alternatives that have been considered

The best example as I have already described, is the Drupal Panels module.

Is there a Drupal or Backdrop contributed module that accomplishes this?

Directly, unfortunately no.

Additional information

If screenshots are needed for further discussion, we'll go from there.

An additional thought is to have a way to maybe search for the fields on the page within the visibility condition. I would imagine that the dropdown would say "field" (where you have URL Path, Node: Nid etc). When selected and added, the next screen would show a list of the fields with a search box to filter them. Once choosing that field the next screen will show the data to choose from for the "criteria".

One thing panels didn't do that I always hated, was allow more than one value. For example, if I have a list field, I have to create a new rule for each and every key value in the list. I always wished that I could select more than one. The same should be applied to other fields like references, taxonomy etc. For example the condition I want is to show fruits. I would like to be able to select apples, oranges and grapes for that one condition even though carrots, potatoes and green beans are also within that fields data set.

---

PR: https://github.com/backdrop/backdrop/pull/3449

[docwilmot]

Is this functionality coming from this access plugin you think? https://git.drupalcode.org/project/ctools/-/blob/7.x-1.x/plugins/access/entity_field_value.inc.

[philsward]

@docwilmot Most likely, yes. I forgot ctools is the backbone of Panels (and Views) which controls things like this. I'm not a coder, so I honestly can't say one way or the other though.

Here is a link to an open issue that deals with the visibility rules not working right with empty fields: https://www.drupal.org/project/ctools/issues/1188466

This might point you in the right direction.

[jenlampton]

It looks like the entity_field_value access plugin from ctools was not ported to Backdrop. I need this for a project today so I will give it a go :) I think this is a powerful feature, and should be included in a future minor release, so adding milestone candidate label.

[jenlampton]

Okay, this PR is a really rough start, but it works for simple string values.

I think we can do better with the UI. Right now the "value" field on the settings form is a simple textfield element, but I think we should switch that out based on the field type. It would be ideal if we could render the field the same way it appears on the entity form so that we're always collecting a value in the exact same format.

[philsward]

@jenlampton agreed the UI needs some work. That said, @docwilmot got a contrib started for this: https://github.com/backdrop-contrib/field_visibility_condition

I haven't checked out your PR yet, but if you can help fix the problems with the fields not playing nice with NULL values, we can get the UX going afterwards. I think it's 90% there but an issue with ctools still hasn't made it into stable that fixes the null problem which is a pretty big deal when it's needed.

See: https://github.com/backdrop-contrib/field_visibility_condition/issues/3

If someone can get that fixed, I'll get the testing on it going.

My thought is to leave it in contrib for now until there's time to pull it into core. I'm good either way though.

[klonos]

I find this a nice addition to the features of core layouts. The less features people miss when evaluating switching from D7/Panels to Backdrop, the lees they will hesitate, and the more chances we have to have them come onboard.

It would be ideal if we could render the field the same way it appears on the entity form so that we're always collecting a value in the exact same format.

Yes, this would be great, but can be a follow-up. If we have enough time, we could even polish it during the 2 weeks between the feature freeze and the release on Jan 15.

Another follow-up could be to be accounting for field cardinality (number of values entered). We could start simple, by supporting at least/exactly/at most, and then add support for more complex conditions, such as AND/OR between field values, which would essentially be a poor-man's #states (think people being able to use #states-like functionality, without having to write a single line of code!). Or that can be left for contrib if it complicates the code and UI too much.

I've done some initial tire-kicking:

• tried to add a field visibility condition to the default layout (then tested with other OOTB layouts; it's the same) -> only one available was the User account: User account field has value -> selected that -> the "Field name" select had no options 👎

  

• The node/entity title is not a "proper" field, but I think we should still have it work as a field for the purpose of this feature. Come to think about it, could this be related to the empty "Field name" select I reported above? 🤔

• We need a "negate" switch, so that we can configure visibility conditions when a field value is NOT something we specify.

• (can also be a follow-up) For text fields, we need a "contains"/"begins with"/"ends with" switch: I created a layout with node/% context

  • added a condition to a block for the body field of posts, and set the value to You may edit or delete it. -> didn't work 👎
  • changed the condition to This is a page with static content. -> didn't work 👎
  • changed the condition to the full This is a page with static content. You may edit or delete it. -> worked as expected this time 👍

• For text fields, do we need a "raw text" vs "formatted text" switch? ...continuing my testing with the same layout/block/condition as the previous feedback point, I edited the OOTB "About" page, where the test block I had added was shown:

  • I bolded a random selection of the text -> saved -> block was gone 👎
  • I edited the node again, and removed the bolded text -> saved -> block still gone 👎
  • I edited the node again, this time I switched to source code edit, and removed the <p> tags that were automatically added around the body text when I bolded some of it earlier -> saved -> block shown now 👍

• I checked and made sure that the test block I was using was shown on the "About" page node, whereas it wasn't shown on the "Your first post!" post node 👍 (because the text This is a page with static content. You may edit or delete it. is what the body text field in the "About" page has). I then blanked the "Value" text field for the visibility condition:

  • Condition description said The Body field on Page is set to "" 👍 (but would be better if it was saying The Body field on Page is left empty or The Body field on Page is blank)
  • When viewing the "About" page, the block was shown, despite the fact that the body field was not empty 👎
  • I edited the "About" page -> deleted the text form the body field -> saved -> the block was shown 👍
  • I visited the "Your first post!" post -> the block was shown 🤔
  • I edited the post node, and reduced the body text to You may edit or delete it. -> saved
  • also edited the "About" page, and reduced its body text to You may edit or delete it. -> saved
  • (now both nodes had the same text) -> edited the visibility condition -> added You may edit or delete it. in the "Value" field -> save the visibility/block/layout
  • block is gone from both the page and the post 🤔 ..."Those bloody <p> tags again!" I thought
  • either edit both nodes and switch to source mode before saving (to make sure that no <p> tags are added)
  • or: edit the visibility condition, and change the value of the field to <p>You may edit or delete it.</p> -> save the visibility/block/layout
  • either way, the block is shown when viewing either node 🤔

  Now is that a feature or a bug? 🤔 🤔 🤔 ...I think that since we do have a visibility condition of Content: Type, we should make the condition content-type-agnostic (in other words, go by field name - not by field instance). ...but if we do that, what happens with other entities/bundles 🤷

That's it for now 😅

[klonos]

I think that if we polish the functional bits, we should get this in as is, even with the "Value" field being a plain text field. The rest of the things, like a "negate" switch, a "raw/formatted" switch, "contains"/"begins with"/"ends with" switch, can all be left as follow-up improvements if too hard to implement, or not enough time to get it done by Jan 15.

Thanks for starting work on this @jenlampton 🙏

[docwilmot]

Seriously, this is contrib solution. In 6 years only two people have asked for it and it is available in contrib. Why would this be an 80% use case?

[philsward]

@docwilmot here's some thoughts:

I do not need this functionality on all of my sites which yes, means it would be better left to a contrib.

However...

If Core has the ability to override a layout to manually build the output by individual field, then I think this functionality should also live with that ability. Someone who needs to manually build the layout, probably needs conditions on the individual fields as well which would make this a better candidate for core.

I'm not advocating either as long as I can get what I need, but I personally would love to see this in core.

[jenlampton]

My argument for putting this in core is that it should have been there to begin with, it was overlooked in the port along with a handful of other visibility conditions (or maybe always intended to be added as a follow-up). This is another one of those things that most sites would probably use if it were available. My use case is for a separate layout, but these conditions are also used for block visibility, where I expect it would be much more common.

Gregory I suspect all your concerns are addressed in the contrib solution (since it uses the same approach as views filters).

And thank you for that Andy, not sure how I missed it :)

[philsward]

Just to be clear so we aren't doing double efforts on the same task, which issue should be the primary one? This one for core or the contrib?

I don't know how far along the core work is, but the contrib is working fine except for null/empty values which I think just needs the ctools patch pulled in to fix it.

[docwilmot]

I hadnt released the contrib module at the time of this original issue since I thought it was being pushed for core, but its been bumped repeatedly since. I still consider this a contrib solution. Should I bother to release, or is someone going to work on this for coren this next minor release.

[klonos]

This is @jenlampton's baby I think. It depends on her availability, or if anyone else has the capacity to pick up the work from where it's left.

[indigoxela]

Should I bother to release, or is someone going to work on this for coren this next minor release.

Good question. The PR is in "needs work" state since late 2020, so I wouldn't expect a lot activity in the next few weeks.

It seems that the release has happened. Should we close this issue? Or at least remove the milestone?

[jenlampton]

yea, sorry everyone. I haven't had the time I was hoping this summer. I'm happy to remove the milesone, and we can re-evaluate in the future.