Kirby Fieldtoggle

Resources Plugins
1

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.

Show image
showimage.gif?raw=true800Ɨ294

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.

Multiple Days
multidays.gif?raw=true800Ɨ294

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.

Structure
structure.gif?raw=true800Ɨ767

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
2

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

1 Like
3

Great! :slight_smile:

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

1 Like
4

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?

5

@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.

6

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.

7

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

8

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

9

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.

10

Yes, thatā€™s right. I wouldnā€™t recommend that solution.

11

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.

12

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
13

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.

14

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:

15

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:

16

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

17

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

18

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?

19

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?

20

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: