In the old CMS, setting a past publication date for content was standard functionality—when this behavior broke on a previous patch level, it was treated and resolved as a defect:
LPD-56362.
The Publication Date is the core field driving chronological sorting in listings, archive widgets, search filters, and the date displayed to end users. Restricting this field creates significant operational challenges across common business scenarios:
Historical Content Migration: When migrating historical articles, press releases, or documentation from legacy systems, preserving the original publication date is essential so archive timelines remain intact rather than flooding new feeds with old content.
Legal & Compliance Requirements: Formal disclosures, policy updates, and financial statements must accurately reflect their official effective/release dates, even if uploaded to the CMS retroactively.
Retroactive Publishing: Editors often need to backdate material originally released offline, in print, or distributed across external channels prior to CMS entry.
SEO & Metadata Integrity: Structured metadata and search crawlers rely on accurate publication dates for proper indexing and content freshness evaluation.
Preserving Out-of-the-Box Functionality: Using custom date fields introduces data redundancy, increases editor friction, and forces teams to build custom sorting/filtering solutions instead of leveraging standard OOTB display widgets.
Given these core requirements, allowing past dates on the Publication Date field is critical for standard editorial and architectural workflows.
Hey @Ludovic, thanks for opening the thread. This scenario is already covered, in the import process, this content behave as other objects, that already supports the publication date in the past. What is the process you are trying to follow to import these entries?
The idea there is similar to author, where we allow you to bring the original author when importing, but not allowed to change in the UI, same for publication date. As publication date has less importance on governance than author, we can allow to add a past date, but for your scenario this should already be solved, can you confirm?
Hi @Luiz_Jardim, thanks for the answer and for the context on the author parallel.
Import does cover migration, but that’s only one of the scenarios in the original post. The one that blocks editors day to day happens in the UI:
Retroactive publishing: an article about an event that has already taken place, or a press release / regulatory disclosure already issued on another channel, needs to carry its actual date. Running an export/import cycle for a single article isn’t a realistic editorial workflow.
Correcting a date: fixing a publication date entered by mistake, or aligning it with the official release date after the fact.
Editing imported content: could you confirm how the edit form behaves on an imported entry whose publication date is already in the past? If saving a body change triggers the same validation, every migrated entry ends up locked in the UI unless the editor moves its date forward.
On governance, I get the parallel with the author, but as you point out, the publication date doesn’t carry the same weight. If the goal is to avoid uncontrolled backdating, a dedicated permission (or a configuration toggle) would keep the default restrictive while giving trusted editors the capability they had in the old CMS, where losing it was handled as a defect (LPD-56362).
Would a permission-based approach work on your side?
Hi @Luiz_Jardim , we’re still with the old CMS, but we’re actively using this feature - as @Ludovic said - for retroactive publishing. There are content types where this date must be set according to regulations, like Press Releases, Publications, official Statements etc. It is also important for ordering, which is crucial for official communications.