Kirby 2.4 wishlist - What would you like to see?

There are already issues at Github of your things you want.

My wishlist for Kirby 2.4

I always want bug fixes and good security but I’ve not added it to the list.

  1. Panel - Panel customizations
  2. CLI - Install other branches
  3. Core - Clever stuff that makes Kirby bend even more to our needs. Hooks, pages methods, collection filters, controllers, components etc are examples of clever stuff that’s implemented already.

What do you want the most in Kirby 2.4?

This is a wiki post, so feel free to add your suggestions to it. You can discuss below. -Lukas

hahahah, I knew it, Jens :slight_smile:

There’s a German saying from a famous former soccer coach: after the game is before the game. It can be easily translated to: after the release is before the release :smiley:

Just keep those wishes coming. We won’t make any promises. But as written in the blog post, we will most likely turn to shorter release cycles with smaller chunks of features, in order to move a bit faster. I hope it works.

4 Likes

after the release is before the release

Haha! :smiley: At least I gave you an hour before posting. :wink:

we will most likely turn to shorter release cycles

It’s seems to be a trend in the CMS world. You don’t follow trends now do you? :wink:

To be serious, if you intend to have shorter release cycles you need to set the scope much smaller than you think. That’s because the final release will be about 3 times bigger than calculated. I know this from own projects and client work.

I wasn’t aware that it is a trend, but it makes sense. In our case, we often get too ambitious about new releases, because of the great community feedback. It feels bad when you have to leave out a lot of stuff you really would love to add. But as you said, the bigger the scope, the more complicated it gets. You have to do more testing and things are more likely to break and in the end it takes forever to release something, which started as a small release.

With shorter release cycles, we really mean smaller scopes. The general idea is to prioritize a limited set of features first and then work exlusively on them for the next version. We are not planning to release new versions every other week. I don’t think that’s very helpful and puts a lot of update pressure onto users. But a stable release every 1.5-2 months would be quite a great goal to achieve in my opinion. 2.3.0 took more than 5 months. That’s just too long.

4 Likes

Don’t do it the Drupal way. Drupal 7 took 3 years, so we said we would turn to shorter release cycles. Then Drupal 8 took 5 years :wink:

To answer Jens’ question:

  • User permissions. There was a lot of activity on the permissions branch on Github last winter, let’s hope it won’t be frozen. Maybe not in 2.4, but at some point in the future?
  • A way for editors to enter Kirbytags easily, without having to remember the name or syntax. I have no idea how it could be done to be honest, perhaps a menu/button with a list in textareas? Something visual.
  • A user field that displays the real name when available, instead of just the username :wink:
1 Like

I have made the first post a wiki post. Feel free to add your suggestions there.

Not really sure if it is “Kirby”, but I’ld love a good way to handle tables in the panel for the editors.

Right now we have 2 options (which both aren’t really nice compared how kirby otherwise works):

  • dump the table html element soup in the textarea
  • use the markdown table syntax which becomes very hard to read when multiple times edited and impossible to see syntax errors in the textarea. It is also limited (e.g. no colspan or th in a column instead of in a row).

I kind of like how redactor.js handles this.

1 Like

i already have write whit @jenstornell about that,

it would be really cool to have Checkboxes to select and delet a number of pages or the files

Hi @bastianallgeier,
I was browsing the release and the changes to try and understand before dropping the kirby and panel folders on one of my localy hosted websites what I should be worried about. Basically trying not to break anything or at least try to assess in advance what I would be breaking. It may be overkill and even impossible to ask that for each release but I’ll shoot ahead. This is what I’d love to see:

Upgrade instructions - changes that’ll break a site

In the case that a change has to be made on a website prior to it being able to be upgraded, it’d be great to know it in the release notes.
For instance in 2.3, I’m looking at the changes and see that all blueprints in the plainkit have been converted to yml. Is that something I need to do? I’m always happy to first break it and then fix it but in some situations it’s nice to have a warning. I do realize that it’d be impossible to guarantee a website won’t break upon update. We don’t live in that world :open_mouth:

Other than that, I haven’t spent enough time with 2.3 to start my wishlist for 2.4.

It’s a good idea to add a “possible breaking changes” to the next changelog entry. For 2.3.0 we are only aware of one very specific breaking change so far, which involves using $thumb->source in your code after running the thumb generator. Other than that you should be fine.

It’s super hard for us to really know about all breaking changes, because we can only track our official fields and test it with the sites we built. With more and more plugins there will be more and more edge cases though.

The yml extension for blueprints is entirely optional. PHP will keep on working fine. It’s just the nicer format and your editor will give you better syntax highlighting.

It’s always recommended to install a new version locally first, test your site and then publish it, if everything works.

2 Likes

Thanks for the reply @bastianallgeier. I’m glad to know that nothing should break and completely understand that it’s impossible to track all third party plug-ins and whatnots for potential issues.

I’ll hop onto the panel customizations train. Something like “widget views” (just like field views) would open a whole new category of possibilities for us developers. Just to be clear, I’m not dreaming of some WordPress like economy where all sorts of plugins clutter your UI, I’m talking about the possibility of letting us create ad-hoc, single use, per site, custom panel views for all those cases where the user action isn’t bound to “changing files in the contents folder”.

Of course we can today create any application outside of the panel, but considering the awesome work that has already been done for the panel (look and feel, routing, transport protocols, authentication, etc…) it always feels like a bit of a waste to recreate all of that.

Do you know that you can create dashboard widgets yourself? But yes, even more ways to customize the Panel (e.g. with views that can use the whole window) are always great. Dashboard widgets are of course always a bit limited in complexity.

Yeah, I did mean “full window views”. I just called them “widget views” because I thought they could be packaged with a widget, just like you can do currently with custom field types.