There's only one plugin I always "forget to install" until the project is on the server and I need it. And then to install one I need to change an .htaccess file or worse. Kirby already does cachebusting for images and panel plugin assets, it woul

It is always very easy and uncomplicated to work with pages as there are so many methods available. However, it is often necessary to use Structure fields. Here it is sometimes really very complex to add, remove or update entries. Some Structure He

My usual files/default.yml looks like this: `yml title: File fields: poster: label: Video Poster type: files query: file.page.images focus: label: Focuspoint type: focus width: 1/2 alt: label: Alt Text type:

The built-in thumb() driver always saves images in JPG format. Newer, better formats exist, and have become standardised - such as WebP. Newer, even better formats are already on the horizon - like AVIF. Some page metric tools - like Google's PageSp

It would be great to be able to create custom statuses. This would open up lots of possibilities for content editing workflows. For example there could be a status called »in review« and only certain user roles are able to change it to »listed«.

TL;DR Having the k-error-boundary component listen for an event would allow developers to "throw" (actually $emit) errors in, for example, field plugins where currently we can't. Longer version Currently we can throw (really this time)

Being able to update the content of published pages without actually publishing those changes. In the use cases below i'm specifically talking about published pages/content. Some use cases: - Editor changes content and wants to save but not publi

Pretty straight foreward. It would be nice if bleuprint fields' could be either 'encapsulated' in a (bordered)box, 'indented' or simpley 'better'/'more manually' layed out for overview purposes. Especially since 'width' does not allow non-standard

The page or file should define itself whether it can be sorted. It shouldn't be based on where (whcih section) it is listed.

If you decide for a multilingual CMS it always comes to the question, how the systems handles language versions. There are two ways to do this. Both solutions have advantages and disadvantages. # V1: Same navigation structure for every language *(w

The current system to tag content is using the tags-field. While this works in some use cases, you quickly can run into hard issues later on. E.g.: - CRUD in a centralized view or UI for terms - make sure your terms are applied consistently to th