kirby
kirby copied to clipboard
Extension: Panel view buttons
This PR …
- [ ] FormButtons are currently not considered a header button but standalone. Should they?
Feature
- Panel view buttons extension https://feedback.getkirby.com/411
panel.plugin("getkirby/custom-view-buttons", {
viewButtons: {
applause: {
template: `<k-button icon="heart" variant="filled" theme="love" size="sm" @click="applause">Applause</k-button>`,
methods: {
applause() {
alert("👏");
},
},
},
},
});
Global config options:
return [
'panel' => [
'viewButtons' => [
'page' => ['preview', 'settings', 'applause', 'status']
]
]
}
Blueprint:
buttons:
- preview
- settings
- applause
- status
Deprecated
-
<k-languages-dropdown>
has been renamed to<k-view-languages-button>
.k-languages-dropdown
alias will be removed in a future version
Breaking changes
- When overwriting/extending any model view, ensure to include new
<k-view-buttons :buttons="buttons">
component
For review team
- [ ] Add lab and/or sandbox examples (wherever helpful): https://github.com/getkirby/sandbox/pull/5
- [ ] Add changes & docs to release notes draft in Notion
I like the blueprint syntax of a simple list that also allows to reorder or hide the default buttons. I'd name the extension and blueprint option headerButtons
though, otherwise it would be confusing next to the existing textareaButtons
extension. The props passed to the extension components make sense IMO.
Is it possible for a plugin to globally register a button on all pages/files? This would be helpful for https://github.com/tobimori/kirby-seo, so people don't have to add the robots indicator to each page. (of course they should be able to override it, as soon as buttons
is specified on a blueprint)
@tobimori Extended the PR to allow setting the defaults via e.g. Kirby\Panel\Page::$buttons[] = 'seo'
. It has the little downside that either you just add your plugin button name to the array and it will be added to the end. Or you overwrite the whole array with adding yours in the position you want this at. But if multiple plugins do that they'll overwrite each other's changes.
EDIT: well, if plugin developers act responsibly, they could still do
array_splice(Kirby\Panel\Page::$buttons, 2, 0, 'seo');
Or something similar. Avoiding overwriting each other's additions.
@lukasbestle I adapted the JS entry to headerButtons
for blueprint options I would really like to avoid camel-casing/too long option names. There I thought as it's on the top level of the blueprint buttons
could be fine and still would be my favourite. One could also do an option header
with a sub-option buttons
but I feel then a lot more, e.g. title
shouldn't be on the blueprint's top level but inside the header
option.
@bastianallgeier @texnixe would be great to hear your opinions on naming etc. too, so I can finalise and polish this PR. Thanks!
I like pretty much everything about it. I just wonder if the buttons shouldn't just get all the same props that the view gets or if they should rather use panel.view instead to access everything they need to know.
I like the idea of using $panel.view
. We're loosing the convenience of isLocked
as that's not a prop but a computed. But I think that'd be ok. I am not sure yet if I would let each button access $panel.view.props
itself. Or if k-header-buttons
internally does v-bind="$panel.view.props"
on each button component.
@bastianallgeier went with the "don't pass any props" approach.
The CI only fails because an rpm bug, I think we can ignore it for this PR.
There's an issue in the Header.vue where the slot is being wrapped with a k-header-buttons div but then the component also has the k-header-buttons class and the margin is applied twice:
<div v-if="$slots.buttons" class="k-header-buttons">
<!-- @slot Position for optional buttons opposite the headline -->
<slot name="buttons" />
</div>
I'm not sure how we can correctly fix it. If we remove the wrapping div, we turn this into a breaking change. But removing the class from the component would also be weird.
@bastianallgeier You are right. I think the new View/Header/Buttons.vue
needs a more specific name. How about k-model-header-buttons
?
I keep coming back to the word "action" something like k-view-action-buttons
maybe?
What about just k-view-buttons
?
I'm happy with that