Kirby Fieldtoggle

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 (

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

Thanks a lot @LCD344! I updated the JavaScript file to use non global variables and convert the field names to lowercase.

No problem this is what we got the community for!

anyway, I forked your plugin (for my own use - but of course its open source) -


  1. The style now looks like a switch.
  2. It’s based on a checkbox and not togglefield (because I had the switch already done for the checkbox
  3. It’s registered through the plugins directory and not fields (personal preference - trying to keep all non original kirby files in the same place)
  4. It’s installable using the kirby cli.

Fieldtoggle v2

The Fieldtoggle field just got a lot more powerful. You can now define as many options as you want. Previously you could only use the “Yes/No” and “True/False” options. This makes it possible to do something like that:

Since the syntax had to change obviously, I updated the original post, too.

TL;DR: You now add the options in show or hide and list the affected fields.


I will probably try it out in the future. Until then I have a few questions about it.

  1. What happends to the fields that are not shown, are they still saved to the content text file?
  2. Is it possible to have “nesting” hidden parts? Let’s say I want to add a category choice inside a category choice.
  3. Is it possible to use checkboxes, like match two of them to show the section? or match a specific checkbox.
  4. Is it possible to have an input text field like match while type feature?

I guess most of the above does not work with the current version but your field seems still very powerful. :slight_smile:

Feel free to add what you want from the list as issues to your repo if you like any of the ideas.

  1. The hidden fields are still there, just not visible. They are also required, since you can’t overwrite the validation.

  2. Nesting is possible, I just pushed the necessary commit for that.

    Overall it’s important to do something with the value of the fieldtoggle field. It is a normal radio button after all. So in your template you’d still need a condition to check what option was selected. That way it’s not important what the hidden fields store.

  3. After I wanted to switch from the toggle field, I initially used the checkbox. Fo my use cases this just made it way more complicated. What do you want to use it for?

  4. I see the appeal of an instant filter, but I think that would be an entirely different field.



I’m new to Kirby and think I will need this fieldtoggle plugin for a project. In the install docs it mentions to add everything to the ‘site/fields’ folder. The thing is, I’m using the Kirby starterkit and it does not have a fields folder… Does the plugin require something to be installed that is not in the starter kit or are the install docs incorrect and should I put it in the site/plugins folder?


Simply create a site/fields folder, if it doesn’t already exists.


Thank you flokosiol!

Hi, is there a way to set a default value?

Yes, you can simply set default: to whatever option should be selected by default.

For example:

label:         Link page
type:          fieldtoggle
  nolink:      No link
  internal:    Internal link
  external:    External link
  child:       First child page
default:       external
  external:    extlink
  internal:    intlink
  nolink:      intlink extlink
  external:    intlink
  internal:    extlink
  child:       intlink extlink

This would set the option external as default and make the field extlink visible by default. Remember to remove any existing content in the content files to simulate a newly created page and test the default value.