Kirby Fieldtoggle

A field that toggles the visibility of other fields

After lots of threads and issues regarding this functionality and the obvious benefits, I decided to create it myself. I hesitated at first, since it was part of the Kirby 2.1 milestone and Daniel Rivers already reached out to Bastian with a solution last year. There must be a catch. :fearful:

I desperately needed it for a project though, and everything seems to work fine, at least for my use cases. If there’s anything wrong, please add an issue on GitHub or comment on this thread. Thanks! :heart:

The field on GitHub: https://github.com/medienbaecker/kirby-fieldtoggle

Image field

In this very simple example we’re toggling the visibility of a single field.

We can use whatever number of options we want. For this example we’ll stick with yes and no, though. Setting the options works exactly as it would with a regular radio field.
In the additional show and hide lists, we can show or hide fields for any of the defined options. In this case we want to show the field imagefield when yes is active and hide it when no is active.

imagetoggle:
  label:       Show image?
  type:        fieldtoggle
  options:
    yes:       "Yes"
    no:        "No"
  show:
    yes:       imagefield
  hide:
    no:        imagefield
imagefield:
  label:       Image
  type:        image

Full day events

This use case is a little more complex, but also more reasonable.

This time we’ll do the exact same thing, but show or hide multiple fields at the same time. When Multiple days is activated, both start and end are shown. When Single day is activated, only day is visible and start and end are hidden.

eventtype:
  label:       Event type
  type:        fieldtoggle
  options:
    multidays: Multiple days
    singleday: Single day
  show:
    multidays: start end
    singleday: day
  hide:
    multidays: day
    singleday: start end
day:
  label:       Day
  type:        date
start:
  label:       First day
  type:        date
  width:       1/2
end:
  label:       Last day
  type:        date
  width:       1/2

The value of the multidays field is still available, so you can use an if/else condition in your template and display different things like you would with a regular radio field.

<? if($page->eventtype() == "multidays"): ?>
  // Code for event lasting multiple days
<? else: ?>
  // Code for event on a single day
<? endif ?>

A fieldtoggle in a structure field

The fieldtoggle field works in structure fields, too.

This time, we’ll have a lot of options to choose from. Depending on the category of the product, fields will be shown or hidden. Just have a look at the blueprint yourself. It may be a bit longer, but it’s pretty self explanatory:

products:
  label:              Products
  type:               structure
  modalsize:          large
  fields:
    name:
      label:          Product name
      type:           text
      width:          1/2
    price:
      label:          Price
      type:           text
      icon:           euro
      width:          1/2
    category:
      label:          Category
      type:           fieldtoggle
      options:
        digital:      Digital good
        animal:       Animal
        subscription: Subscription
        service:      Service
        coupon:       Coupon
        food:         Food
      show:
        digital:      filesize
        animal:       species diet
        subscription: start end
        service:      date employee
        food:         bestbefore
      hide:
        digital:      shipping species diet start end date employee bestbefore
        animal:       filesize start end date employee bestbefore
        subscription: shipping filesize  species diet date employee bestbefore
        service:      shipping filesize  species diet start end employee bestbefore
        food:         shipping filesize  species diet start end date

    shipping:
      label:          Shipping cost
      type:           text
      icon:           euro
    filesize:
      label:          Filesize
      type:           text
      icon:           download
    species:
      label:          Species
      type:           select
      icon:           paw
      options:
        - Cat
        - Dog
        - Bird
    diet:
      label:          Diet
      type:           textarea
      icon:           cutlery
    start:
      label:          First day
      type:           date
      width:          1/2
    end:
      label:          Last day
      type:           date
      width:          1/2
    date:
      label:          Date
      type:           date
    employee:
      label:          Responsible Employee
      type:           select
      options:
        - Lorena Ipsmann
        - Dolores Singh
        - Achmed al Consetecur
        - Ali Lipsing
    bestbefore:
      label:          Best before
      type:           date
14 Likes

Brilliant.
The first thing I would test is whether or not it’s possible to have required fields hidden behind the switch!

1 Like

Great! :slight_smile:

This is one of those features I would prefer to have built in.

1 Like

Yes, definitely an important question. But does it make sense to hide required fields? What functionality would you expect? An error? Disabling the hidden required fields?

@thguenther: Perfect, I agree with @jenstornell that this functionality should be part of the core, but in the meantime it’s really great to have that field :slight_smile:

IMHO it does not make sense to make hidden fields required, otherwise you would have to fill them all in, even if they are not needed. Or you would have to make them required on a conditional basis, if you choose one option, that option is required, otherwise the other.

Making fields conditionally required is trickier than it sounds. It’s sadly not enough to deactivate the JS side of validation.

If you remove the required attribute, the PHP validation throws an error anyway. That’s super secure for other situations—for this plugin it makes things difficult. Maybe @lukasbestle or @bastianallgeier can help finding the place where this validation is defined, though.

I think it’s defined here but I’m not sure wether and how to override this with JavaScript.

Hm, the validate() methods reads the option from the blueprint … so if you remove it from the input field via javascript, that is ignored.

The only way would currently be to create custom extensions of all used fields that override the required method.

Every change to the required method and new or custom fields would break that functionality. Right?

I personally don’t need required fields that can be toggled on or off. At least not right now. Maybe the required method will be adjusted, or such a functionality will make it to the core at some point.

Yes, that’s right. I wouldn’t recommend that solution.

Maybe at this point, you could just add it to your docs to not use required fields in fields that can be hidden if you haven’t already done so.

It’s already mentioned in the “additional comments”.
Maybe I’ll try to display a custom warning, that explains what’s happening when there’s a hidden required field someday. But I hope a fool proof core functionality regarding this will be faster than me. :sunglasses:

1 Like

Well, my comment led to a whole conversation I see!

I was going to test the required specifically because I’m quite sure it’d make the fields bug.
I’ve had bugs already with the tabs plugin that doesn’t work well with required fields (when the field is not visible on clicking save button).

When do I think required field would make sense is, for instance, your example with the events. If it’s a multi-day event, I think it makes sense that the start and end be required. There are many examples like this.

Yeah, but then it is better to not require the field rather than having a bad UX like in the tabs field.

Instead of requiring the field, we could use the help option to tell people to fill out all fields.

And wait and hope for a native solution :pray:

For sure, preventing errors on save and trusting the user is the easiest way to go!
I mentioned testing this in my original reply to poke around and see if it had been somehow implemented by the OP. I was wishful but didn’t have the opportunity to look at the code or test. I was just expressing interest for this edge case that’s been bugging me off several times :slight_smile:

3 posts were split to a new topic: Require field in tabs field

I am the developer behind the original solution referenced in the OP (Github Issue).

I have had lengthy discussions both in chat and over skype with Bastian in the past about this functionality. There was one issue which Bastian found that if I recall correctly was to do with field casing changing within core which prevented it being rolled out as built in. The discussion ended with him saying that he will look at resolving the casing issue before adding to core. This being said it was fully implemented and working from the implementation of the feature, but has just not been included in core as yet.

This implementation is a basic but functional implementation of what my implementation covered, with mine supporting few extras like multiple criteria and regular expression checks to name a few.

It have recently tried to contact @bastianallgeier to try to push the functionality into core, but not been able to progress as yet. Hopefully soon, I will review my implementation and ensure that its still functional in the latest panel and resubmit a pull request to ease any transition. He has acknowledged that its still ‘on the list’ to be implemented.

Hopefully this adds some context to the delay on the implentation

Thank you @DanielRivers for the explanation.
I don’t fully understand what the “field casing error” is, much less if this Fieldtoggle field is affected by it. But it’s still very helpful to get some “behind the scenes” information.

How did you manage the empty “required” fields that are hidden?

No problems @thguenther

I believe if you have a field name which is mixed case, and match the mixed case in your rules, you will run into the same problem which caused it to be held off being added to core by Bastian, though I could be wrong. If I recall correctly Kirby changes all field names to be lower case. This may have changed in the last year though, if it has then it resolves the issue which stopped my implementation.

I am going to look at a couple of options around the required fields, I don’t believe my implementation did cater for that. In the past I have used client side validation and used the :isvisible to determine if it’s to be validated. This I feel could be utilised potentially?

Yes indeed, I just had this problem and edited the fields js to change everything to lowercase. so you should definitely lowercase everything.
Another comment about the js is that you should probably add the “var” word when you define variables, as to not pollute the global namespace (http://stackoverflow.com/questions/5398766/when-to-use-var-in-javascript)

So far liking the field though! I might fork it with a different style :slight_smile: