Conditionally show fields and sections with WhenQuery

Hello Community!
I normally don’t spam my plugins, but I know some people have been waiting for this one for some time.

Similar to the standard when property, the WhenQuery plugin let’s you show and hide sections and fields. But it does so by evaluating an expression, which enables greater flexibility.

I’ve tried to design the expression language as powerful and easy as I could. If however you have a genius idea on how to simplify or empower it further please let me know, either here or on github.

Here’s an example blueprint:

fields:
  blocks:
    type: blocks
    
  confidenceBooster:
    type: info
    label: Number of images
    text: >
      Good! You have at least 13 images in this post.
      This will be a **great** post!
    theme: positive
    whenQuery: blocks ::count($.type = 'image') >= 13
3 Likes

This is awesome! Thank You so much! <3

1 Like

:whale2: :sparkles:
@rasteiner wow, such a great plugin, i am literally using it everywhere!
thank you so much for your work on this.

feature request

it would be so cool if this plugin could handle conditional field visibility based on the page status as well. so for example: show fields, when the status is “listed” and hide fields when the status is “unlisted”. maybe this might be an interesting add-on for you?

That’s indeed an interesting idea, unfortunately there is no way I know of getting a reactive value to the page model in the panel.
I’ll add an issue to my repo anyway to keep track of it when I discover a way.

1 Like

Turns out that sleeping helps. :slight_smile:

0.2.2 gives you access to some of the model props. The page Status is one of those: https://github.com/rasteiner/k3-whenquery#model-variables

2 Likes

:partying_face: :tada:
just saw this on github.
wow sooo good, thank you so much!

1 Like

Great plug-in @rasteiner. I’d like to implement a feature toggle which means on site level there are certain toggle fields e.g. “feature-categories”. Then on page level an additional categories field shall be shown depending on the toggle value.

Would that be possible with whenQuery? It seems no as it gives “just” access to predefined variables, correct?

The plugin only has access to what the panel gives me. That is the current model content an some of its properties. Your idea would need access to another model’s content and that won’t work, unless you create something like a custom hidden field that receives its value from the backend.

But it seems like you don’t actually need to have it update in realtime, so what you want is probably more like “programmable blueprints”.

@rasteiner may i ask why _template is available with the new file properties, but not with the new page properties? because i would actually love to show/hide fields based on the selected template of the page! :sunflower: :sparkles:

I simply forward the model properties that get sent by Kirby to the panel: kirby/Page.php at 04127160ed1ab8dc277763cd8ba4ebc5a097bc18 · getkirby/kirby · GitHub
And the template isn’t one of them for pages. I didn’t bother to much about the missing template property because I assumed that “showing/hiding fields and sections based on the template” would be primarily done by using different templates.
What’s the use case?

:partly_sunny: :sparkles:

i am actually reusing sections & fields as described here. so this is where it makes sense. using the same section in two different blueprints. but controlling which fields within the section are visible based on the template of the page. hope that makes sense? it got quite late yesterday.

but anyway, i did find an alternative solution to my use case already. no need for you to dive into it more. i was more curious where these properties are coming from and now i know! thank you so much!

1 Like

@rasteiner hey again :stuck_out_tongue: would it be somehow possible to use a function for the query? i would like to only show a field whenever a custom user method returns true, so something like

warning:
    type: info
    text: xyz
    whenQuery: _user.customMethod = true

Hello :wave:
i don’t think so. 2 reasons:

  1. My queries are run only on the frontend, they don’t have access to the PHP functions.
  2. My queries are unable to run any functions (not even frontend functions), the security model would become too complicated.

It looks like programmable blueprints are what you need.

In general the rule is:

  • React to changes in the same model in realtime → whenQuery or when property
  • React to anything else, “on load” → programmable blueprints
  • React to backend changes in realtime → not possible
1 Like

@rasteiner thank you so much. always a pleasure to talk to you. i learn a lot!
i was hoping to not use a programmable blueprint. but seems like it’s the way to go here.

:white_heart: :sparkles: