Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Invalid Date" parsing dates in pages section with layout:table #6230

Closed
sciloqi opened this issue Jan 31, 2024 · 15 comments
Closed

"Invalid Date" parsing dates in pages section with layout:table #6230

sciloqi opened this issue Jan 31, 2024 · 15 comments
Assignees
Labels
type: regression 🚨 Is a regression between versions
Milestone

Comments

@sciloqi
Copy link

sciloqi commented Jan 31, 2024

Description

In the pages section, when using layout:table with custom columns, the date parsing shows "Invalid Date" for days > 12 and don't format as expected for days <= 12. Using date handler intl.

Expected behavior
Date: 2023-11-24 16:00:00.toDate('dd.MM.Y') should be 24.11.2023 (is "Invalid Date")
Date: 2021-10-05 00:00:00.toDate('dd.MM.Y') should be 05.10.2021 (is "2021-05-10")

Screenshots
Bildschirmfoto 2024-01-31 um 18 12 57

To reproduce

  1. Fresh starter-kit
  2. add intl date handler to config.php
  3. add layout:table with columns: / date: / value: "{{ page.date.toDate('dd.MM.Y') }} to blueprints/sections/notes.yml
  4. See panel "site"

Your setup

Kirby 4.1.0 (no problems with Kirby 4.0.3)

@afbora
Copy link
Member

afbora commented Jan 31, 2024

I can reproduce the issue on 4.1.0 either. Works great for 4.0.3

@afbora afbora added the type: regression 🚨 Is a regression between versions label Jan 31, 2024
@distantnative
Copy link
Member

I fear this is originating from #6147

Before the PR, this would render as a text preview - now it's trying to render as a date preview and tripping up.

@sciloqi as quick fix adding type: text to your column definition should probably solve it for you

@afbora
Copy link
Member

afbora commented Jan 31, 2024

@distantnative Yes type: text works great.

@afbora
Copy link
Member

afbora commented Jan 31, 2024

I think also following usage give outputs same with {{ page.date.toDate('dd.MM.Y') }}

columns:
  date:
    display: DD.MM.YYYY

@afbora afbora added this to the 4.1.1 milestone Jan 31, 2024
@afbora afbora self-assigned this Feb 1, 2024
afbora added a commit that referenced this issue Feb 1, 2024
@janstuemmel
Copy link

janstuemmel commented Apr 16, 2024

Bug still exists ([email protected]) when day ist < 10 in 2024-09-05 for example.

Bildschirmfoto_2024-04-16_19-23-27

For the first cell "Date Start" data is Datestart: 2024-04-09, kriby will print 2024-09-04 . So i think there is any confusion with day and month. This happens only in table columns i think.

However, it is still fixable with type: text.

Please reopen @distantnative

@distantnative
Copy link
Member

@janstuemmel What's your blueprint?

@janstuemmel
Copy link

janstuemmel commented Apr 16, 2024

Works with type: text...

# events.yml

title: Events

tabs:
  events:
    label: Events
    columns:
      - width: 2/3
        sections:
          events: 
            extends: sections/events
            query: page.children.sortBy("dateStart", "asc").filterBy("dateEnd", "date >=", "today")

# ...
# sections/events.yml

label: Events
type: pages
template: event
limit: 10
sortable: false
status: published
layout: table
search: true
columns:
  dateStart:
    label: Datum Start
    #  type: text # <- fixes display of date
    value: "{{ page.dateStart.toDate('dd.MM.Y') }}"
    width: 1/7
  dateEnd:
    label: Datum Ende
    # type: text # <- fixes display of date
    value: "{{ page.dateEnd.toDate('dd.MM.YY') }}"
    width: 1/7
<?php

return [
  'date.handler' => 'intl',
  'locale' => 'de_DE.UTF-8',
  // ...
];

@distantnative
Copy link
Member

And your event.yml?

@janstuemmel
Copy link

janstuemmel commented Apr 16, 2024

# pages/event.yml
title: Event

create:
  slug: "{{ page.dateStart.toDate('Y-m-d') }}-{{ page.title.slug }}"
  fields:
    - dateStart
    - dateEnd
  redirect: false
  status: draft

status:
  draft: false
  listed: true
  sort: false

columns:
 # ...
  - fields:
      dateStart:
        type: date
        label: Datum Start
        display: DD.MM.YYYY
        required: true
      dateEnd:
        type: date
        label: Datum Ende
        display: DD.MM.YYYY
        required: true

Example event content:

Datestart: 2024-04-10

----

Dateend: 2024-04-29

@distantnative
Copy link
Member

So your field is defining the display as DD.MM.YYYY which is also used for the date preview in the table to make sense and display the value as date, but then your value query returns the value as string dd.mm.Y. That doesn't match and likely trips up the date parser. Can you try to get rid of the value line and just add display: dd.mm.Y in the column definition? I think then the column can use just the standard field value (instead your custom preformatted one that trips up the redundante date parsing) and display it with the format you like.

@janstuemmel
Copy link

Like this?

# sections/events.yml

label: Events
type: pages
template: event
limit: 10
sortable: false
status: published
layout: table
search: true
columns:
  dateStart:
    label: Datum Start
    #  type: text # <- fixes display of date
    # value: "{{ page.dateStart.toDate('dd.MM.Y') }}"
    display: dd.mm.Y
    width: 1/7
  dateEnd:
    label: Datum Ende
    # type: text # <- fixes display of date
    value: "{{ page.dateEnd.toDate('dd.MM.YY') }}"
    width: 1/7

That leads to a empty "Date Start" column. And it makes sense, since value is undefined

Bildschirmfoto_2024-04-16_22-18-44

What works though is:

columns:
  dateStart:
    label: Datum Start
    # type: text
    value: "{{ page.dateStart }}"
    display: DD.MM.YY
    width: 1/7

@janstuemmel
Copy link

janstuemmel commented Apr 17, 2024

@distantnative

Is it now still a bug or expected behaviour? I would have assumed that table columns take exactly what's defined in my content txt files.

Is the display field documented somewhere? Can't find it in the pages table doc's?

@janstuemmel
Copy link

Can you please answer my question?

@distantnative
Copy link
Member

@janstuemmel I figured it out: it's an issue of case matching: #6473

Once I write datestart in the blueprint in your examples, it works for me.

@janstuemmel
Copy link

Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: regression 🚨 Is a regression between versions
Projects
None yet
Development

No branches or pull requests

4 participants