hafriedlander
commented
12 years ago Before we can come up with a solution we have to think about what the customer requirements are:
- When you set an embargo, what does it mean? Does the existing page (if their is one) remain until the embargo passes, or does the page disappear / become unaccessible until the embargo date? Can you have more than one embargoed version? What happens if you need to fix a spelling mistake on the current live page when there's a newer version under embargo - do you have to discard your pending changes (which might be difficult to replicate later) in order to fix the current issue?
- When you set an expiry, what happens once the expiry passes? Does it revert back to the previous version? Or to a newer version? Or just disappear / become unaccessible?
With that in mind, there's (at least) a couple of ways to approach this problem technically:
1) Right now any page in a workflow transitions from WorkflowAction to WorkflowAction via manual control. You could extend this to allow transition on a schedule. By setting a transition to only move to publish after a certain date you can implement embargo.
Implementing expiry this way is a bit trickier. Effectively expiry can be seen as an embargoed change set to happen on the expiry date, where the embargoed change is either "revert to old version" or "remove page from live". Or we can have pages maintain their workflow state indefinitely, so that a page version can move in and out of published state multiple times, and implement expiry as another transition
2) We could ignore advancedworkflow entirely. Treat embargo / expiry as an extension to Versioned instead, where instead of "publishing" from Page_versions to Page, publishing consists of updating a timeline which defines what version should be live on a particular date.
3) We could provide an underlying API that both modules hook into
An uncovered issue: how does the UI for this look? How do we clearly convey to administrators when changes will happen, and what they'll look like.
My personal feeling:
Deal with expiry has embargoed change to a newer version, not as a separate concept
Extend the Page_versions table to include a date to be published on. When that date passes, update live Page table to have that new version
Show in the tree the upcoming versions, like:
- Home
- About
- About (from 1 Feb)
- About Us (from 10 Feb)
-
(from 20 Feb)
When using advancedworkflow, each pending version will have it's own workflow like:
- About
- About (from 1 Feb)
- About Us (from 10 Feb, currently pending approval by Editor)
-
(from 20 Feb)
Instead of having embargo / expiry dates, each action can be performed in the future, i.e.
Save & Publish Save & Publish On.... Delete from Live Delete from Live On...
Internally implemented by providing IsPublishedInterface which both expiry/embargo & advancedworkflow would hook into. Example implementation:
class ExpiryEmbargo implements IsPublishedInterface {
static $version_fields = array(
'LiveFrom' => 'Date',
'LiveTo' => 'Date'
);
function IsLive($version) {
return $version->LiveFrom <= time() && $version->LiveTo >= time();
}
function LiveDescription($version) {
return "from ".$version->LiveFrom;
}
}
smagnusson
nyeholt
phptek
chillu
Some Usability Adjustments:
Embargo: 'Select Publish date'
'Select Publish time'
Expiry: 'Select Un-publish date'
'Select Un-publish time'
Maintainer note: See framework commit 585a8bc "Removed 'showdropdown' option from TimeField, use custom libraries instead (Ingo Schommer)" This is why a dropdown no-longer shows for this workflow functionality.