Understanding the confusion between Created and Published Dates in Umbraco

The node creation date used as a date of publication can be confusing for Umbraco editors. In this article, I will try to explain the issue of created, updated, and published dates.

A Deep Dive into Umbraco's Date Fields

Each article regardless it's a news or blog post should include a date of publication also known as a date of first publication.

It's definitely a crucial information for users.

From the beginning of Umbraco for each published node we can access the CreateDate and UpdateDate properties.

Properties are available through the IPublishContent interface.

When playing with published content the UpdateDate is interpreted as the date of last publication also known as the last modified date.

The same properties are available through IContent, but we need to access a node by ContentService which shouldn't take into action during rendering pages.

However, the UpdateDate of IContent has a different meaning when a node has pending changes.

It's worth mentioning that there is also the PublishDate property available only through the IContent which indicates when a node was last published.

The CreateDate property is displayed in Umbraco's back office as a Created date as follows:

The CreateDate property of node in Umbraco backoffice

How Umbraco Manages Content Dates

Generally, from the business perspective, the date of first publication and last modified date are the crucial dates of any article.

Moreover, it's recommended to share those dates as the datePublished and dateModified properties in the article structured data, but it's related to SEO.

Based on my experience and what I have seen in various projects, I can say that the built-in created date of the node is commonly used as a published date which is crucial for articles, news, or blog posts.

Just to clarify:

  • There is no any property in published content related to the date of first publication.
  • We can't relay on the UpdateDate property, because it changes every time a node is published.

Unfortunately, once a node is created, it may take some time before it is published. Therefore, editors sometimes need the ability to override this date.

Basically, to solve the issue an additional Created date field is implemented by developers. Often, there is no description provided for this field.

Of course, the purpose of this field is obvious for developers, but it could be confusing for editors.

Recently, I have noticed in one of the projects that an additional field is used alternately with the built-in created date even though the field is not set as mandatory. 

Therefore, I can say that this date can be confusing for some developers as well because it's not used consistently.

Recommendations for Optimizing Date Management in Umbraco

Created date is used as a published date, so if we need to introduce an additional field for overriding this date then we should rather create a Published date field instead.

Of course, Determine published date or Provide date of publication as a description would be really helpful for editors.

For some projects, the published date could be crucial. Therefore, it would be better that the published date will be set explicitly by editors, so the new field should be considered mandatory.

Key Takeaways on Umbraco's Date Dynamics

When the published date field is introduced then it should be used properly in the code while displaying it on the page or providing in the article structured data.

The date should be taken into account during the rendering listing page with article cards ordered by date of publication.

Of course, when the additional date is not set as mandatory the fallback to the built-in created date should be implemented.

🌐 Explore More: Interested in learning about Umbraco and web development insights?

Explore our blog for a wealth of information and expert advice.

↑ Top ↑