Error in panel, if date.handler = 'strftime'

I want to build a blog using German dates (e.g. März) and the new config c::set('date.handler', 'strftime');.

Step 1

I have installed kirby-nightly-2.1.0 - 2015-07-25 12:12:30 and set the config to German. These settings depend in part on the web server, and therefore I do not specify here.
To verify this error, you can choose any language, just as you like.

In the default blueprint site.php I changed the line:

pages: default


    - default
    - blog

I have build a new blueprint blog.php, which looks at the decisive section like:

  sortable: true
  sort: flip
    - blogarticle
    mode: date
    field: created

I have build a new blueprint blogarticle.php, which looks at the decisive section like:

pages: false
    label: Created
    type:  date
    required: true
    default: today
    format: DD.MM.YYYY

I have added the templates for these blueprints.

I have added the content of the blog page and of some visible blogarticles using the panel.

All is ok, especially in the panel.

Step 2

I set “c::set('date.handler', 'strftime');” in the config.php.
Now I have done the changes in the templates for these blueprints to use ‘strftime’. They look fine.

Step 3

But if I go to the panel and e.g. want to change the visibility of one of my visible blogarticles all blogarticles get invisible (the date parts of the directory names of all blogarticles are deleted) and the directory name of the processed blogarticle now starts with “Ymd-”.
If I want to change the visibility of the processed blogarticle once again, the directory name receives “Ymd-” once again at the beginning.

Something is wrong.


The created fields in the content files of the blogarticles are saved in the format “YYYY-MM-DD”, which is ok especially in step 1.
I think this could be documented too, as it is described at different locations (e.g. in the forum) as an error.

I could reproduce this and created an issue on Github:


Thank you very much!

No, I don’t agree!

This issue is not solved!

It has to remain open, until the related issue on Github is closed and this error is solved!

@HeinerEF Maybe someone was in too much of a hurry, but please don’t get all upset, there is no reason to shout at people in big bold letters all the time, especially if you can undo it easily as you have already done.