dotCMS / core

Headless/Hybrid Content Management System for Enterprises
http://dotcms.com
Other
864 stars 466 forks source link

FTM: Add Support for dotCMS Containers to Display Future Content Based on Publish Date #30552

Open fabrizzio-dotCMS opened 1 week ago

fabrizzio-dotCMS commented 1 week ago

Parent Issue

https://github.com/dotCMS/core/issues/30551

Task

Following the initial investigation into container rendering logic, the goal of this issue is to extend support for dotCMS containers to allow them to display future content based on the publish date. This will enable containers to hold content that can be viewed in a future state, supporting dynamic content updates in dotCMS environments.

Proposed Objective

Same as Parent Issue

Proposed Priority

Same as Parent Issue

### Acceptance Criteria
- [ ] dotCMS containers correctly interpret publish date values to conditionally display future content.
- [ ] Content updates scheduled with a future publish date are displayed as expected without impacting other container functionalities.
- [ ] Documentation on modifications and any notable code dependencies is provided.

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

No response

Assumptions & Initiation Needs

No response

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

fmontes commented 1 week ago

Future Time Machine Feature in the Page API

The new Future Time Machine feature in the Page API of dotCMS allows developers to request the "live" version of a page for a future date. If any content has a "working" version with a publish date set in the future, the API will return that "working" version instead of the current "live" version. Below are examples that illustrate how this works:

I want to ensure clarity around our latest feature. Below is an overview of how the new Future Time Machine feature in the Page API is expected to work:

Content Legend:

Imagine we have these 3 contents on a page.

Content A
-- status: Live, Working
-- publishDate (Working): 2024-11-15

Content B
-- status: Live, Working
-- publishDate: None

Content C
-- status: Live, Working
-- publishDate: None

Content D
-- status: Scheduled (Working only and Live while in the publish range)
-- publishDate (Working): 2024-11-18
-- expireDate (Working): 2024-11-25

Here is how the page API should return the content based on the parameters sent:

  1. Request with mode "live" and no future date:

    /page/home
    -- mode: live
    -- publishDate: none
    returns: [Content A (Live), Content B (Live), Content C (Live)]
  2. Request with mode "edit" and no future date:

    /page/home
    -- mode: edit
    -- publishDate: none
    returns: [Content A (Working), Content B (Working), Content C (Working), Content D (Working)]
  3. Request with mode "live" and a future date (>= 2024-11-15 but < 2024-11-18):

    /page/home
    -- mode: live
    -- publishDate: 2024-11-16
    returns: [Content A (Working), Content B (Live), Content C (Live)]
  4. Request with mode "live" and a future date (>= 2024-11-18 but < 2024-11-25):

    /page/home
    -- mode: live
    -- publishDate: 2024-11-20
    returns: [Content A (Working), Content B (Live), Content C (Live), Content D (Live)]
  5. Request with mode "live" and a future date (>= 2024-11-25):

    /page/home
    -- mode: live
    -- publishDate: 2024-11-26
    returns: [Content A (Working), Content B (Live), Content C (Live)]

[!NOTE]
We should also take into account content pulls and not only content direct inserted

fmontes commented 6 days ago

We need to enable the expiredDate

github-actions[bot] commented 21 hours ago

PRs: