Kirby 2.1 beta is here!

I have been very quiet with updates over the last weeks, but behind the scenes a lot has happened. Originally I had planned to release smaller updates more often, but now things turned out a bit differently and I decided that we are making an instant jump from 2.0.6 to 2.1. This bigger step means that we need to do some more testing and that there will be a small beta starting today.

You can find all the changes in this massive changelog on Github:

As you can see there are LOTS of new things and still not everything is in there, which I wanted to have in 2.1. But please be assured that 2.2 is near and more stuff is coming soon :slight_smile:

I also want to use this chance to say a HUGE thank you to @distantnative who helped me out over the last weeks and is about to become a more regular/offical contributor to the core of Kirby, which is super awesome.

So if you’d like to help us test 2.1 please just grab the latest versions from the develop branches of the kirby, toolkit and panel repos and let us know how you like it.

The most simple way to get started is again with the starterkit or with the plainkit:

git clone -b develop --recursive


git clone -b develop --recursive

You can also use an existing Kirby installation and checkout the develop branches for your submodules like this:

git submodule foreach git checkout develop
git submodule foreach git pull

or you can grab the nightly build from here: and replace your kirby and panel folders if you are not working with Git.

You can submit any feedback here or post issues on Github.

Thanks for your support and happy testing :slight_smile:


So far it’s all looking great on a test site… and patch notes show a lot of great additions.

Regarding the new “Site Files”, it would be nice to specify the directory it uses, so it could point to “assets/images/” instead of “content/”. I don’t like the idea of cluttering that directory with images personally.

Looking great! I noticed some text strings have been added to the EN language file, and are missing when other languages are used in the interface. Should we already make pull-requests to update other languages?

I’m on the exact opposite site on this question: I’d see assets/ as developer territory, same as site. But everything, which is editable through the panel, is for users – so it should go into content.


That´s right. And if I think of my git setup and workflow, the content folder is not in the main repository for the website (for a good reason - it will mess things up). So I do not want to have user changeable content in the assets folder.
Just to add another aspect of this as well.

1 Like

That’s a good point, indeed, these parts should be clearly separated.

The site files only work within the content folder. They share the same code and logic behind page files and thus also share the same APIs. Moving them into assets would be very complex to achieve.

The reason to add site files in the first place was to offer editors managable global files for their site/content. Stuff like global header images, background images for sites with fullscreen backgrounds, global downloads or something like that. They are not meant for design assets, such as the icons, the logo or other stuff only the designers and developers should touch. So storing site files inside the content folder imho makes clear that this is user generated/administrated content.


Oh, great!

But running the panel, after adding a second user and going to the panel root, I get the following message two times:

Warning:  trim() expects parameter 1 to be string, array given in E:\xampp\htdocs\test_kirby_2.1_000\kirby\core\children.php on line 90

This error is not solved in “kirby-nightly-2.1.0-20150404145847”.
But now after going to Panel it shows only once.

Then I want to add a new page in the root of the website. When I click at “Status: unsichtbar” to change that to “Status: sichtbar” I get:

The text in the dialog is missing. The dialog works correct, if I hit “Ändern”.

This error is solved in “kirby-nightly-2.1.0-20150404145847”.

I use as my DEV system on Win7:

  • XAMPP Version 1.8.2-5
  • Apache 2.4.9
  • PHP 5.4.27 (VC9 X86 32bit thread safe) + PEAR

Thanks and good luck!

I get the same result if I switch from English to German, so it looks like the translation is missing … the English version works fine.

[Edit] This is already an issue on Github

Just wow! Awesome update. :thumbsup:

Testing it right now.

For me the panel search (/panel/#/pages/search/) does not work. When entering valid URLs only the “There are no search results…” message appears.

(OS X 10.10.2, PHP 5.5.14, PHP web server)

While that is indeed a valid point, and I can appreciate where you and @distantnative are coming from, having seemingly unorganized files all in the content folder without the ability to organize them into sub-directories rubs me the wrong way. Perhaps moving the files into “content/files” and adding support for sub-directories would be another solution that allows the developer assets and user assets to remain separated, while also allowing the obsessive compulsive to organize content better?

This isn’t a huge priority for me at the moment, I am just trying to think long term where there could be hundreds of files in the content folder.

1 Like


Anyone tried the optional widget function yet?

Great release @bastianallgeier !

Have a look at this post, a visitor stats widget: Stats plugin / Hit counter

Tnx! I will give it a go!

I believe there’s a conflict between Parsedown and Smartypants. My config file:

c::set('smartypants', true);
c::set('markdown.extra', true);

Attempting to create a Markdown link with title:

[Kirby 2.1]( "Kirby 2.1 is Awesome")

Will parse [Kirby 2.1]( “Kirby 2.1 is Awesome”)

What’s wrong with that? Check the quotes on the title, they’re curly quotes because Smartypants converts them. I turned Smartypants off and the links worked as they should.

1 Like

There seems to be a bug with pagination:

$pagination->prevPageUrl() and $pagination->netxPageUrl() ignore URL parameters like tags or search queries.

Not sure if it is me, but is the /panel/#/metatags/ widget missing in 2.1?

thanks, @thomas

It has been removed, see the changelog:

The site options have moved to the menu and are no longer available as widget in the dashboard. This makes the dashboard clearer and the menu serves as a better/more logical entry to the options.

1 Like

Could you open an issue over at GitHub:
Also some code / error messages / description what or how it is not working, would be of great help. Thanks!


1 Like