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

Sorry for the long explanation in advance, but it needs a little more detail to be understood :-) Current behavior of creating multilingual pages: Setup: - Multilingual project, configured with [en] and [de] as languages - [en] is defaul

->ts() shortcut for ->toStructure() like ->kt() which is the shortcut to ->kirbytext() would be great.

A split parameter to the $pages->groupBy() method would be helpful for grouping items with multiple tags. Consider: Title: Banana ---- Tags: fruit, yellow Title: Strawberry ---- Tags: fruit, red ` Title: Radish ---- Tags: veg

Non-interactable fields (like gap, line, icon, info, headline etc.) should be addable without defining a name for it. That way it can be combined with it's shortcode to create a neat one-liner. Example currently: `yaml headline4: ty

Showing markdown highlighting directly in the textarea field, e.g.: \\bold\\ as \\bold\\ \italics\ as \italics\ \link as \[link]() \#headings with bigger font etc. Depending on

I would love to have a field property "help" for headline fields which should be placed below the headline. (https://getkirby.com/docs/reference/panel/fields/headline#field-properties) It would allow to describe the following block and would save t

The current permissions system, as simple and reliable as it is, can become quite limiting for more complex projects. This has already been pointed out by various users. For example, user-based permissions, which are necessary e.g. to prevent access

I'd love to have to login form as a template file, too. We would like to change the look of the login page (logo, additional text information for example for contact etc). Idea: maybe just check if a file "login.php" exists, and if so, take this i

Actually it's a pain for content editors that there's no built in revisioning or backup system. A simple versioning for files to move backwards 2 or 3 steps would be awesome! A simple content lifecycle as found in plugins (publish later) would be

My editors sometimes have to work with tabular data. This can be needed in a textarea-field, or an editor-field (block?) or could even be in a dedicated field ( or even third party field via plugin - which doesn't exist afaik). I know in a `t