Extension: Panel view buttons

[distantnative]

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

[lukasbestle]

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.

[tobimori]

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)

[distantnative]

@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.

[distantnative]

@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!

[bastianallgeier]

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.

[distantnative]

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.

[distantnative]

@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.

[bastianallgeier]

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.

[distantnative]

@bastianallgeier You are right. I think the new View/Header/Buttons.vue needs a more specific name. How about k-model-header-buttons?

[bastianallgeier]

I keep coming back to the word "action" something like k-view-action-buttons maybe?

[distantnative]

What about just k-view-buttons?

[bastianallgeier]

I'm happy with that