Publish begin- and end-date

[jrief]

In CMS3, each page had a publish_date and a publish_end_date so that pages could appear and disappear after those given timestamps. CMS4 doesn't offer such a feature anymore. We however need this, because some press releases have a time constraint and must not be published before a certain timestamp.

On 2023-06-21 I chatted with @fsbraun about this issue and asked him how to solve this. I actually was thinking about extending PageContent with a custom class, and add those two fields there. Fabian however convinced me to add this feature directly into djangocms-versioning.

There this feature is in good hands, because apparently even the django-cms blog requires this. So how do we proceed?

Proposal:

Extend model Version and add two optional timestamps publish_at and unpublish_at. If they are None the behavior remains unchanged. None in this context means that a page-content is published immediately and indefinitely.

If the page-content is versioned, these rules apply:

A Version object with a timestamp has precedence over a version without a timestamp. This rule only applies if the time constraint is active and the state is either "Pending" or "Expired" (see below). Example:

• We have two versions, 1 and 2.
• Version 1 has state "Published" and has no values for either published_at or unpublish_at.
• Version 2 has values for published_at and unpublish_at, both in the future. After saving Version 2, the status would show "Unpublished", be the list view of VersionAdmin then renders "Pending" which is more meaningful.
• Time passes and reaches the value of published_at in Version 2.
• State of version 1 switches to "Unpublished" but shows up as "Expired".
• State of version 2 switches to "Published". Content of Version 2 now is published.
• Time passes and reaches the value of unpublished_at in Version 2.
• State of version 2 switches to "Unpublished" but shows up as "Expired".
• State of version 1 switches to "Published". Version 1 now is re-published.

In Column "Status", the list view shows two more states, "Pending" and "Expired". These are just more meaningful values for "Unpublished" and can be determined using the timestamp values publish_at and unpublish_at. The state field in model Version then still has the value "Unpublished". Versions with status "Pending" or "Expired" behave just like pages with status "Unpublished". They can be reverted by clicking on the "Revert" action inside the versioning's list view.

Currently there is no editor to change any field value of a version object. Here we could add a detail (change) view to the list view when clicking on "Manage Versions…". This detail view is realized inside the existing VersionAdmin. It only contains the fields publish_at and unpublish_at. Are the proposals for other fields to be added?

The value for published_at must either be None, or precede the value for unpublish_at. The same applies for unpublished_at.

If a page-content contains more than one Version object, no two version objects may have overlapping publishing dates. This rule is enforced through a validation checker when validating a Version object before saving the VersionAdmin change view.

If all versions have time constraints and none of them is currently active, a Not-Found page is rendered.

We need four extra icons to symbolize versions with either publish_at or unpublish_at, both of them, or none of them. They shall be rendered in the list view.

Since we do not want to install an asynchronous running worker (for instance Celery) which sets the status (state field in model Version) whenever a configured timestamp is reached, this will be done by a special status_update()-method. This method will be invoked before rendering a page or the list view for versions but could also be invoked from outside by whomever needs it.

[marksweb]

This sounds worthwhile/necessary but certainly complex.

I also really think we should provide a way for integrating projects to run the status checking outside of web requests. A management command would work best as that could call a utility function like you're taking about. That way celery or cron could be used to call the same function.

[jrief]

@marksweb A management command would certainly be useful. It would have to iterate over all pages and update the status of the versions, depending on the current time.

Unfortunately I'm very new to djangocms-versioning, so I might be a bit naive here and this proposal might have edge case I never thought about. Such a feature, however is a must-have in order to proceed with the migration.

[marksweb]

That's OK, I'm no expert here either. But this is a good example of where the complexity quickly comes into play.

You'd want a command that you could pass at least a content type to. Thus limiting the intensity of the query.

It could also be a class that could be subclassed by apps which have versioned models intending to use these additional fields. Without them there's no need, that I can see, for a command to run. So the class we provide might have a get_queryset which throws a NotImplementedError or something similar.

[fsbraun]

I think we can potentially reduce the complexity a bit:

Maybe rename those fields to visible_after and visible_until so that they change the visibility of a published content element not the publication state:

1. The datetime fields are empty for drafts and archived versions.
2. They can only be set upon publishing a content model. Once published they are frozen even after unpublishing the content to document when the content was visible
3. View on site is only possible during the time window (ensured by the appropriate query).
4. On the preview endpoint there needs to be an indicator when the content was, is or will be visible.

This way no state has to be changed in the background, those datetime fields do not have to be editable. Overlapping visibilities cannot happen (to create a new timed published version, a previously published version will have to be unpublished first). No precedences have to be defined and explained.

I'd suggest adding a "Timed publishing..." menu entry for drafts to the versioning menu, which then allows for those two datetimes to be defined in a form.

Finally, this would in principle also be integrable with moderation.

PS: We would need to think about menu caching to ensure content also appears in the menu.

[jrief]

If I understand this correctly, this means that a page with timing constraints is only visible in that given time window. Otherwise a Not-Found page is shown.

In my proposal, it is possible to replace pages by another version, once they hit that timestamp.

Your implementation is nearer to that what we have in CMS3, and for us this would be enough. But I believe that my proposal adds more value to other installations of CMS4.

[fsbraun]

I agree with your assessment, but I fear your proposal is incompatible with current basic assumptions of djangocms_versioning, e.g., number of frozen public versions. Also, a good UX would not be trivial.

[Also, together with alias, you actually could create something you describe: Have separate aliases that are public in a consecutive time window and include them (both) with an alias plugin on a page. Same UX issue, though, and I would not advertise it.]

For dynamic content in a broader sense (one "version" being automatically replaced by another "version") a separate package might be a better solution, where you could arrange content on a time line.

[jrief]

Okay, then let's proceed with your proposal.

[Aiky30]

This requirement was spec'd by the V4 sponsor early on, it was superseded by an internal third party tool.

The original spec was scheduled publishing. It was designed to be a separate bolt on package (like version-locking). When installed the features would become available.

The design philosophy of V4 is to create something complex with many simple things. What happens is that djangocms-versioning becomes a huge monolithic beast that's hard to make changes to because it has many opinionated options.

Scheduled publishing comes with some very interesting problems, it needs moderation support (sign off before publishing) and it's also difficult to know what to do in some cases when unpublishing content "expires" because it can leave a page looking broken (think alias on a page here).

Scheduled publishing was also another driving factor for djangocms-alias, you could have a banner that advertises Christmas, then the day after Christmas it switches to a New Year advertisement.

[fsbraun]

Has scheduled published been done? Is it public?

[marksweb]

I'm making sure "The design philosophy of V4 is to create something complex with many simple things." is in the docs.

[fsbraun]

To discuss this with a concrete implementation at hand, I have created PR #341 to show how the V4 philosophy on separating out functionality allows implementing start and end dates easily with versioning. It automatically becomes available for all versioned models, like alias or blog (soon).

I'd appreciate your thoughts!