Allow for publication dates set in the past

Hi folks,

Our content team often moves articles around, de-prioritizing them by setting their publication date in the past, so they appear deep in the pagination rather than on the first or second pages.

Previously when we used Wordpress, they would simply do it by setting the publication date in the past. In Dato this is unfortunately not possible.

I see this feature has been asked about at least a couple of times already:

The answer, in each case was that the publication date was a read-only object representing internal state, but that doesn’t seem to be the full picture, because you can set a publication date in the future!

As advised in the above threads, we have created an additional field per model that has a configurable datetime for publication, but that has made the UX for the content editors even more confusing. If they want to use a publication date of now or in the future, they can use the standard “publish” button, but if they want to set one in the past, they have to use this other field, further down in the model.

If Dato wants to keep immutable records of creation, publication, etc. it would be great if it did this in a separate object, and allowed the publication date that is used by the big, main “publish” button to be set in the past as well as the future, and bring it in line with other CMS publication functionality.

I feel this would not only greatly improve the experience migrating from an old, established Wordpress site, but also fulfil an expected publishing behavior in the editor.

I understand your point of view (and of other people).

But publishing in the future doesn’t simply set a different date. It runs the publication script at some point with a scheduled task, so the functionality is actually to always publish at a specific point in time.

By exposing some internal data we are giving some additional information, but allowing the change on internal metadata I’m not sure if we can do it properly.

What if the internal publication date wasn’t present at all? What would you miss in the date field?

I think it’s more that the Publish button is tied to a read only field. In my opinion it would be better served to be connected to a freely configurable one. You could keep the current internal state field (and continue to expose it, read-only), but have the Publish button write to a new field, and have that field used for deciding whether a record is considered published or not.

maybe we could implement something on the plugin SDK to allow that?

That would be great actually!

Hi Frank.

I have the same situations weeks ago and the answer from the support team was:

I’m sorry but the publication date, like the other timestamps in item’s sidebar, is not user editable in that way. That modal window if used to schedule a publication in the future.

May I suggest to add, for instance, a legacy_publication_date field to your model? Then in your website you should render legacy_publication_date if present, otherwise you fallback the first published at value.

So I do that and works perfect for me right now.

I hope it helps for you

ok, we have decided to implement this, but we don’t have an ETA yet sorry. It will come though :slight_smile:


This is now live:

1 Like

Fantastic news, many thanks!

1 Like