Date-based numbering not sorting entries correctly

I’m trying to sort my entries by date, using:

pages:
  template: fairsitem
  num: date
  field: openingdate

in my “fairs” blueprint (which creates “fairsitem” pages), but I get all my entries dated with the current date and thus incorrectly sorted.

My date field (“openingdate”) however does work and it displays the selected date correctly on the frontend.

Has your

a correct format in the blueprint of the subpages (template: fairsitem)?
Look for format: Ymd!

Good luck!

I had:

openingdate: 
    label: Opening Date
    type: date
    format: dd.mm.yy
    default: today
    width: 1/2
    required: true

I tried Ymd but it doesn’t help. Actually, it makes funny things happen in the panel.

For the record, when I use format: Ymd this happens in the panel:

(takes me by default to the year 2 and it seems to always add a “Y” to the date)

… is wrong. Use my

  format: Ymd

[edit:]
in the blueprint of the parent page!

Good luck!

I don’t think you can use Ymd in the blueprint for the date picker, the default is YYYY/MM/DD, while Ymd is the default for the date format prepended to the folder name. Valid formats for the folder number date are php date formats as described here: http://php.net/manual/en/function.date.php.

@anon77445132: Format dd.mm.yy is perfectly valid as date format for the date picker field, while Ymd cannot be used there

@texnixe:

Yes, I was wrong.

Thank you very much.

Which "openingdate"s are stored in your

content files *.txt?

Which "openingdate"s are stored in your content files *.txt?

This (which is the specified value):

Openingdate: 2014-10-16

However the folder of that same entry has the name:

20150325-frieze-london

As you can see, dates don’t match.

Where exactly in the parent blueprint shall I put the date? I tried this:

title: Fair List
pages:
  template: fairsitem
  num: date
  field: openingdate
  format: Ymd
files: false
fields:
  title: 
    label: Title
    type: text

But still doesn’t seem to fix the problem.

PS: everytime I try something new, I create a new entry to test this. Shall I log out and log in again as well for proper testing?

is different from your

  format: dd.mm.yy

Why?

Delete your subpages and build them new.

The format as displayed in the panel is different from the date displayed in the text file, so if you put format: dd.mm.YYYY in the blueprint, it will still translate to 2015-10-16 in the text file, that is perfectly all right.

The format Ymd is default anyway, so you don’t need to specify this in the blueprint, you need to do this only if you want to use a different format.

Anyway, I’ve been testing so many things in the last few hours, it could be that I had yyyy-mm-dd before on my blueprint. Doesn’t really matter. The issue here is the content. It’s storing the right date in the content file but the wrong date on the folder filename. Why is that?

And you know what’s really funny? All the subfolders (the subpages) used to start by 20150324 yesterday and today they start by 20150325. I have like 20 entries (subpages) and I’m sure I did not edit 90% of them (I’m testing everything only with one entry). How’s that all folders got renamed to today’s date?

Is it perhaps storing the value today literally instead of interpreting today’s date and storing its numerical value?

I briefly tested this and it seems that the date you enter in the text file via the date picker has no effect whatsoever on the folder date. Looks like it takes the day you set the folder to visible is taken as the date, i.e. if you set the article to invisible and then change back to visible, it prepends 20150325, i.e. today

However that doesn’t correspond to what is written on the Kirby Docs:

By default dates for numbers are taken from the date field. You can change that with the field parameter:

…
pages:
  num: date
  field: added
…

[Edit:] http://getkirby.com/docs/panel/blueprints/page-settings#numbering-of-subpages

Maybe its a bug, because it works perfectly with the default date …

If I change the name of my openingdate field to the default date, then it would work?

I tried, and indeed, having a date field simply called date fixes the problem. :smile:

1 Like