Did you try the usual condition: true (without quotes)? Or even condition: "true" or condition: 'true' (as docs say, it can be strings)? Why the double quotes? This should literally parse to 'true' (string with quotes in it and not just as string true)
The conditional field type is used to conditionally display some other fields base on a condition.
The term “fields” is quite ambiguous, but my first interpretation is “input fields” which excludes “tabs”.
The final verdict might be given by the Grav-team…
Alternative ‘conditional’ approach:
You didn’t share the intention of using a ‘conditional tab’, so maybe the following alternative might not work in your use-case.
You could display a tab conditionally by conditionally publishing the overriding blueprint.
Usually a plugin publishes its blueprints in the event onPageGetBlueprints. E.g.:
public function onGetPageBlueprints(Event $event) {
$types = $event->types;
$types->scanBlueprints('plugin://' . $this->name . '/blueprints');
}
To publish the blueprint conditionally you could:
Subscribe to event onPageGetBlueprints only when condition is met.
if ($condition) {
$this->enable([
'onGetPageBlueprints' => ['onGetPageBlueprints', 0],
]);
}
Or you could wrap the code inside onPageGetBlueprints with an if-statement:
public function onGetPageBlueprints(Event $event) {
if ($condition) {
$types = $event->types;
$types->scanBlueprints('plugin://' . $this->name . '/blueprints');
}
}
IMHO, this approach is much cleaner and less error-prone than messing around in YAML form definitions.
@unmick, I just read your question on Github in which you explained you use-case:
In fact, i use the same yaml for standard pages or blog ones and i would like to display the tab dedicated to the blog only if the parent is a blog
I’m wondering why the typical use of file names: blog.md (defining the blog) and item.md (each blog item) does not work in your use-case. Would you mind sharing why the use of blog.md/item.md doesn’t work in your use-case and the conditional tab is a necessity?
Hi
Thanks to take care of me
In my blueprints folder, i have a gallery.yaml which imports the fields related to the gallery: import@1: type: partials/gallery context: theme://blueprints
Not important in this explanation, in my blueprints\modular folder i have a gallery.yaml which import the fields related to the gallery
For my blog, i have also the item.yaml which imports the blog-fields.
Instead of using item.yaml, i can use also the first gallery.yaml where i would like to insert the blog-fields only when the parent is a blog.
I don’t want to see the blog-field outside a blog and i don’t want to create a itemgallery.yaml for maintenance reason.
At each time i need a new parameter for the gallery, i add it in only one yaml.
At each time i need a new parameter for the blogitem, i add it in only one yaml.
// partials/gallery-bits.yaml
form:
fields:
gallery_options:
type: section
title: Gallery Options
underline: true
header.gallery:
type: text
label: Gallery field
Notes:
The only duplicate code is the definition of a tab in gallery.yaml and gallery-item.yaml. I guess however, that that piece of code will hardly change over time. The changes will be in the partials/gallery-bits.
Mark the different extends@ blueprints gallery.yaml and gallery-item.yaml use.
Any changes in item.yaml and partials/blog-bits will automatically be available in the blog tab of gallery-item.yaml.
Any changes in the partials/gallery-bits.yaml will automatically be available in the gallery tab of gallery.yaml and gallery-item.yaml.
You wanted:
At each time i need a new parameter for the gallery, i add it in only one yaml.
At each time i need a new parameter for the blogitem, i add it in only one yaml.
I like to think I have achieved above requirements…
Sorry for the delay.
It’s effectively the best solution. I cannot avoid to duplicate gallery.yaml in gallery-item.yaml and may be in a second time to create a gallery-eshop.yaml
i have too many kind of pages
