tabs can currently only be used at top level.
My suggestion here is to be able to use them anywhere when needed, maybe with a different UI than the top-level one.
I am not sure I understand what you are imagining. Could you describe it a bit more?
In my page fields, I want to use tabs to separate 2 (or more) content.
Let’s say I have a page for a course, with some informations and I have to show conditions if it’s for an online course, or a on-site course, etc.
They will probably have the same type of fields inside to enter some informations about theses conditions (Next dates, place, price, …).
Each type of course can be completed or not.
Actually i’ve made a conditionnal checkboxes/radio field to show each type of course we want to edit, but it’s not so great… And the page is longer.
There was an UIKit k-tabs component around the 3.5 release, but it got removed from the docs; the component is still there but a bit hard to use because it’s still factored for “top level” as you say.
See a hacky solution hee : https://forum.getkirby.com/t/panel-tabs-field-implementation-discussion/21252
A real solution could be to implement k-tabs as a blueprint field, plus using the when section/field condition to hide/show according UI fields.
A few updates:
k-tabs
ui component is back in the documentation, while almost not being documented and not optimised for re-use, it seems to slowly integrate kirby’s UIKit.Another thought: Currently k-tabs
is only used on pages with blueprints and point to a link that reloads the panel view, letting PHP update the selected tab via a “static” prop. We can change the tab visually by changing the tab
prop, but there’s no way to know which tab has been clicked without using a link ! Leaving empty tab.link
makes k-tabs
unusable.
So it would be awesome if k-tabs
supported dynamicly switching tabs.