We have a custom field to allows us to use Kirby’s core single checkbox component as field in places where having a toggle does not make sense. The plugin is simple:
<?php
use Kirby\Cms\App as Kirby;
Kirby::plugin('hananils/checkbox-field', [
'fields' => [
/**
* Displays a single checkbox in the panel.
*/
'checkbox' => [
'extends' => 'toggle',
'props' => [
'after' => null,
'before' => null,
'icon' => null,
'placeholder' => null,
'text' => null,
'help' => null,
/**
* Sets the info text next to the checkbox label.
*/
'info' => function ($info = null) {
return $this->info = $info;
},
'value' => function($value = false) {
return $value;
}
],
'computed' => [
'checked' => function () {
return $this->toBool($this->value);
}
]
]
]
]);
panel.plugin('hananils/checkbox-field', {
fields: {
checkbox: {
extends: 'k-checkbox-input'
}
}
});
Everything works just fine when using this field in general. The panel stores values correctly, it displays the state correctly. But as soon as we add the field to a blocks field, the state is no longer displayed correctly: The field always displays as unselected on load. You can interact with the field and the UI changes accordingly. You can save the page and the state is stored correctly. But on reload the field will be unchecked again.
Any ideas how to fix this?
Just for context, here is how the use the field:
fields:
checkbox:
type: checkbox
label: This is the label
info: This is the info
And this is how it looks in the panel:
k-checkbox-input
inherits from k-choice-input
which has two props checked
and value
. I believe because it is also used by the radio input and there it needs to represent as well an actual value. But if checked
isn’t passed, the boolean prop type defaults to false
. I think that’s where your problem originates.
Also it looks like you are creating your field by extending an input. That mixing of two levels will cost your support for label etc.
The thing is we do pass checked
as computed value in index.php
and it works as it should when used as a plain field. It just stops working when used within a blocks field.
Also it looks like you are creating your field by extending an input. That mixing of two levels will cost your support for label etc.
That’s on purpose because we don’t want to display an additional label on top of the field (label in the sense of heading as we have them for other fields). The checkbox itself has a label already: the text written besides it (label in the sense of describing what the input does).
And have you tested whether the correct checked
prop value reaches your Vue component? TO narrow down where this problem occurs. Is it in the component? Is it somewhere between the blocks field, the single block and the field?
Yes, I started with that. But I’m not doing much Vue work: what’s the recommended way to do this?
Probably not really a recommended/bext-pratice way but how I do it often and it works for me, something like:
panel.plugin('hananils/checkbox-field', {
fields: {
checkbox: {
extends: 'k-checkbox-input',
mounted() {
console.log(this.checked);
console.log(this.value);
}
}
}
});
I can also look into it, but not before tonight.
1 Like
It seems like the problem is rather on the PHP side. If I simply return true
from the computed checked
it also displays correctly inside a blocks field. So somehow the logic there goes wrong when the content value is coming from a blocks JSON object.
EDIT: I think I am getting closer, I think for a blocks field there are two branches of data put together: on the one hand the values and on the other hand the properties for the fields inside the block. It seems though that the properties are put together without providing the values again - and this is why then any computed prop or so that relies on the value fails.
For the moment, I think the following workaround could be an option
panel.plugin("hananils/checkbox-field", {
fields: {
checkbox: {
extends: "k-checkbox-input",
template: `
<k-checkbox-input
v-bind="$props"
:checked="Boolean(value)"
@input="$emit('input', $event)"
/>`,
},
},
});
Have opened a general issue to investigate further: Block field: sub-field props computed without involving values · Issue #6946 · getkirby/kirby · GitHub
1 Like
Thanks you so much for looking into this – this blocks stuff can get complex very quickly.