Proposal for 'workflow' on blogposts and cms pages

[rickybanister]

Writing down some thoughts to discuss on a lab day in the future.

Currently we do not have the ability to do workflow in apostrophe. If you edit a slot or add a new one, you are essentially making a hot-fix to the live site. If you have published a blogpost and make an edit the same is true, live hot fix.

This is a problem if: you have a high-traffic site. You modify a text slot to make reference to a picture below. But you haven't added the photo slot yet. Anyone viewing your post is seeing it change in realtime (if they are refreshing the page).

We could require that they unpublish the page or post before making a change BUT this is impractical if it's a top-level page. They would be hiding a whole section of the site while they make their fix.

The original design of the new blog had something like this feature, but we tabled it for time's sake. It needs much improvement and finesse before implementation, but the idea is still applicable.

We will have three states (or publish options) for posts and pages:

Draft—a post or page before it's been published. There will be 'unpublish' buttons that allow an admin to make published content back into a draft. It will no longer be publicly visible.
Published—the live version the world sees.
Update—when you make a change to a page or post it gets saved, but does not go live to the world. We hang onto two versions, the published one and the updated one. When all the changes are made an admin can click the big button (which now says 'Update'). For blogposts this will all happen in the sidebar. For pages I think it can happen in the page settings. We'll rework the design some, but add in a big publish button. Perhaps we can set up a session variable thing so if the last page you created defaulted to published automatically, the next one does. And vice versa.

One big benefit of going down this road is our ability to rethink History a little bit. Wordpress and others save a revision every time you hit the big button, not every time you edit a little bit of content. Our history browser is hard to use because the change between one state and another is very tiny. I think it would be more useful if a new revision is saved each time the big publish/update button is clicked. Then browsing history is more meaningful. Or perhaps there's a combination (nesting slot-level changes inside of larger changesets) for really smart and anal people.

That's a lot to think about, but Tom, Dan, and I should sit down and talk about a plan for workflow in the next few months.

[boutell]

Sounds like you want pagewide history. That has a lot of issues to be worked through.

The "publish" button is an interesting idea but do we want to force the use of a "publish" button (and therefore workflow, at least for yourself) on everyone? If not we still need a way to do history increments for people who are happy in hotfix mode.

[geoffd]

One of the solutions that we have been discussing with regards to workflow is to have a staging site where you make all of the content changes to your site. Then once you are happy with all of the changes, you hit a sync button that syncs the changes to the live/production site.

This has the added value of not requiring any editing tools on the production site. It would help with security and scaling issues. We should explore that.

My concern with a big publish button on each page is that we start to remove some of the unique approaches to content management that we have established.