Page Drafts

[tablatronix]

Implementing Feature Page Drafts
Ability to draft changes to pages without affecting public or private pages until ready to publish

[tablatronix]

Discussion on implementation of page drafts.

Looking for input on how drafts should work.

Primarily should drafts be draft of a page, or some separate thing that can replace a page.
I think each page should have 1 draft available, tied to the page.

How do we handle page options, will they be tied to drafts, or can page options be editable for page in real time and not drafted. If drafted how would that work. What will be handled by drafts ?
Content fields, what about plugin content fields? I proposed official support for plugin content fields in another issue. #506
This would complicate things in both aspects.
If we allow page options to be changed live, then those changes wont be in the draft.
If we do not allow drafted options, then the process of making a draft live is more than moving a file, there will be a splice operation to join the pieces togather.

How do we publish drafts?
How do we publish a draft when the page is published, when it is not published.
Do we leave the publish flag for page untouched, and simply replace page with draft ?

What is the terminology we want to use for drafts?
publish draft can be confusing because we will have separate publish flags for pages themselves.
push to page, make live, make draft page, copy to page, replace page, enable draft.

Backups, how will this affect backups. Do want to keep draft backups and page backups ?

Editing pages, this will be dependent on how drafts work namely the page options.
When clicking a page, do we goto the page normally, read only the content and allow page options to be modified.
To edit you have to exclusivity click edit, at which point we create a draft.

Or do we automatically assume you are editing and draft it when saving, this would keep it fairly the same as it is now. Then if a draft already exists, do we go to it automatically, and label the page with some draft header. And show it along side the page options, which are not draft, or are?

[PrplHaz4]

full disclosure: I have no idea how versioning works in GS now.

I would expect the model to follow something similar to Sharepoint, where a draft is actually an unpublished version of a document. In order to publish the draft, a new version number is given to the document, and the draft version is promoted in place of the existing published version. Only one published version of a page can exist at any given time. Versioning is opt-in, to allow lightweight editing without the additional features/bloat (ie, requiring a new version/draft for fixing typos).

Metadata required to manage at this level would be:
Status: Published, Unpublished, Draft
Version: sequential, numeric - based on publish date

Versioning may also help with storing page options, as well as plugin settings - associate with a given version only (may prove to be complex without a db though!)

[tablatronix]

I doubt we will use versioning too complex.
There is currently no versioning in gs.

I do like the option of disabling it.

[aoloe]

drafts would be a nice addition!

some thoughts...

personally, i'd like to be able to choose to create a draft after i have started editing a page and not to have to actively thinking about it, before clicking on the edit button.

btw, once i've started editing a draft, it's more important to me that i don't publish it by mistake, than having a very easy way to publish it.

as long as the options are as simple as they are now, i don't have a need to have them "drafted", too... but if they will be growing in the future, it's not a bad idea to already have a solution ready...

nice to have: a way to undo publishing a draft and get back to the previous version (eventually by losing the page's own backup)
not sure if having a backup of the draft itself is really that needed... personally, i'd prefer putting the effort in an ajax way of saving, that would keep the undo steps while editing...

[tablatronix]

I agree creating a new page should be essentially creating a draft, at the point of saving we could simply offer save or publish or something similar. It would not be something convoluted or change the flow of creation from how it is now.

[hameau]

What I would use:

• Single draft version of a page (either a draft revision of an existing page, or a draft for an as-yet-unpublished page).
• Ability to undo changes to draft pages, as is currently possible with published pages.

These drafts are never available or visible from the front-end (unlike current private/not-in-menu pages).

For a draft (revision?) of an existing page, it will be necessary to have slug management, such that when the draft is eventually published, it inherits the existing slug to maintain, for example, inline links.

[tablatronix]

Some finalizing draft spec, not much input on drafts so far.

drafts will be as simple as possible, no new methods or procedures

NOTES

drafts are NOT unpublished pages. The word publish can be confusing here as we do not have a better phrasing for what is actually "make this draft live" opinions welcome ❓
page publishing is a different concept and feature
drafts can be in unpublished state, this is not to be confused with published pages, pages may be also in unpublished states in the future.
at some point drafts may be auto publishable ( but this is a feature of publishing )
publishing will offer ability for page publish dates, right now this functionality is similar to public/private page status. expanding this to drafts would add full version publishing as well. But drafts themselves are only single modified versions of a page that can be pushed to overwrite the live page ( being published/public/private or not, is irrelevant.

Drafts cannot allow slug modification at this time, this would require slug tracking and would present numerous issues we don't want to solve right now.

specs

• drafts will operate exactly like pages do now
• drafts will be the default editing mode if enabled (optional)
• new pages need to be saved first to show up in pages, new functionality can alleviate this but this adds complexity. Do we want never published drafts to show somewhere, not simple ❓
• drafts will have option to publish
• drafts will have option to preview, front end querystring logged in only check
• drafts will have undo capability just like pages
• drafts will have some form of publish undo, (restore page, restore draft) ❓
• drafts will have their own backups, problematic with autosave ❓
• drafts will autosave, this will affect draft backups, so considerations needed
• versioning hooks refactor backups add capability #757 plugin support or something similar, separate save hooks for drafts saves
• drafts are page edit, with a draft indicator
• publish hook, plugins can hook this like they do changedata-aftersave
• disabling GSUSEDRAFTS , will leave page editing exactly the same as it is now

todo

• backup methods cleaned up and universal
• new method for publish
• undo publish or retract, unpublish the last draft. essentially restore page backup
• filesystem structure, using autosave for now
• file naming, same naming, slug cannot be changed for drafts
• toggle constant GSUSEDRAFTS
• draft save hooks, to avoid plugins doing stuff on edit hooks
• publish hooks
• new i18n strings
• new notifications
• draft backup
• draft backup restore
• draft backup delete
• draft error reporting and undo
• backup view draft indicator
• draft delete and undo
• reimplement autosave with drafts
• figure out backup solution
• page draft slug follows page slug changes
• page draft restore, on page slug change restore

Input from other issues

#188 mvlcek

• show draft for logged in user on frontend (optional)
• autosave on leave (instead of warning now), might be difficult cross browser using beforeunload
• autosave on preview
• indicator on pages list view of draft available etc. also New fields for pages #506
• publish all ( probably not, plugin preferred)

indicators

There is alot of information we might want to convery, but it is not clear how to do so cleanly and simply

• in draft edit mode
• draft mode - draft not exist, so we can know if we are actually seeing a draft with differences
• draft mode - page not exist, is this draft never published
• draft mode - if it is published, when, more info ?
• live edit mode - FYI THIS IS PUBLISHED VERSION you are editing!
• pages view, draft exists
• draft front end preview indicator ?draft, eg. FYI this is a draft or leave to themes

see figures below for interface i am experimenting with to show this additional info without modifying the normal appearance and flow of editing pages

problems

Are there any possible problems with other fields from publishing changes to them ?
Obviously there are needs to

• rebuild sitemap
• rebuild page cache
  anything else we need to check or perform ?

Flow

possible flow with drafts enabled

• Create New Page
  • save as draft [default]
  • save as page first, then edit draft (until we have some kind of draft enumeration and pages display)
• Edit page
  • draft [default]
  • publish draft
  • edit current (published version, live edit)
• Edit Current
  • edit draft
  • live edit warning
  • clone options remain

[tablatronix]

#188

[tablatronix]

Additional Features

• ability to still edit original page directly for minor changes if draft exists or multiple drafts , very difficult to make simple however. A quick edit mode (edit current/live) that bypasses draft is probably the easiest to handle , we just add a 'no draft' tag to the edit, and provide the link somehow. this should contain a warning though as it has some caveats, mostly being that a draft will no longer contain some changes that were made in the live page, also we could show a warning that a draft is older than a page, but where to put all these warnings. We also need nomenclature for this stuff ❓
  Page stacks seems to solve this very elegantly
• ability to discard draft, does not affect published pages, handling just like bottom of page edit, hard to get to, but not used often. other actions
• A single view for a page similar to how restore shows a page with all info at once. So you can look at a page without editing or creating a draft. Perhaps implemented as a back end preview or popup, similar to how we show a readonly overview of a backup page. Probably needs a new issue for this feature.

[tablatronix]

Alot of cms, show a toggle between publish and draft, which is ok, it lets you edit both, but I am not sure I like this.

[tablatronix]

plumbing work

To make drafts and page management easier, I have reworked all filio operations in core, and rewritten all backup and restore methods.
Any data file can now be backed up by simple calling a backup function on it. ditto for restoring.
All file functions exist and contain a new debugger, there will be some error handling to impement, when do we fatal, when do we catch, when do we ignore.

#896

[tablatronix]

[tablatronix]

Input welcome
I dont know if published it the right label to use here, since we might have page publishing on the front end.

It is more like Live or Current non-draft version. I am having a problem deciding how to name this

some antonyms

final
release
live
current
active

I am in favor of published and draft, they probably translate well.
We should use private public etc that we already have for public publishing anyway.

[tablatronix]

hooks

changedata-save changedata-save-draft
changedata-aftersave changedata-aftersave-draft
draft-publish

filters

page-save
draft-save

#719

[PrplHaz4]

I am in favor of published and draft, they probably translate well.
We should use private public etc that we already have for public publishing anyway.

This makes sense to me, and I'm pretty sure translates to WP pages...etc. I'm thinking private/public...etc is more for access rights or visibility to users, vs draft/published governs visibility at a higher level (Published is always what the system will see/map to)

[tablatronix]

FYI, this is fairly stable to play with if anyone wants to test it out. The unchecked items will be a phase 2 probably , maybe even after i merge this into master after thorough testing and of course some feedback.

https://github.com/GetSimpleCMS/GetSimpleCMS/tree/feature_570_page_drafts

[tablatronix]

• published on , by author is empty when no author, index page on new installs )

[tablatronix]

0d0e379
4e1519f

[tablatronix]

Made some changes, fixes some bugs, cleaned up page stack css, simplified styles etc.

Bugs

• always says author unknown in footer
• added some handling for new pages and ajax saves, redirecting new pages so background processes can run if needed, just too much to ajax update atm and no clean mechanism yet.
• draft preview broken if fancy urls is off

New

• page stack is optional
• ability to invisibly use drafts, customization etc.
• optional default edit mode for pages, draft or published
• add draft querystring, required for above, since nodraft only works when draft is default

Made the page stack optional, added default stack mode,
since you can now toggle default stack, or disabled page stack entirely,
I had to add ?draft querystring to be used in those cases.
This allows you to force draft or nodraft or use your own clutterless interface for drafts editing, when page stack is off. usedrafts must be enabled to use drafts in this manor regardless.

'GSUSEDRAFTS'          => true,                           
// (bool) use page drafts
'GSUSEPAGESTACK'       => true,                         
// (bool) use page stacks for drafts, else qs `nodraft` or `draft` only
'GSDRAFTSTACKDEFAULT'  => true,                           
// (bool) default page stack editing to drafts if true

[tablatronix]

There won't be a draft indicator on pages for a while, but you can toggle labels and filter on draft for now.

• add draft label to pages

[tablatronix]

Merged into master

[flexphperia]

Please add these drafts constants to gsconfig.php file it would be easier to change its value without any typos.

[tablatronix]

gsconfig won't be tweaked until at least alpha release, and then it will be a decision what to include by default.

[tablatronix]

It is a bit hard to theme front end draft previews,
... Otherwise best option might be to load some kind of frame or inject js, but I am not sure that is fair to do, mess with the theme, or do something out of themers control.

• add $data_index->draft
• make theme function page_is_draft()

[tablatronix]

• when usedrafts is false hide draft flag in pages.

[tablatronix]

• reduce bold labels, too heavy

[tablatronix]

• when changing page slug, draft is lost, draft must be updated and renamed

changeDraftSlug()

[tablatronix]

add save and publish to page actions.
submit and redirect to publish post redirectto
move code around to support save then publish ?

[hameau]

Current master seems to include a useful implementation.

I would like to see this feature enabled in 3.4.

[tablatronix]

here are the pertinent configs, not sure what final defaults will be. I am fairly sure we want GSDRAFTSSTACKDEFAULT false, since it is annoying when editing a small or new dev site.

	# DRAFTS -------------------------------------------------------------------------------------------------------------------------------------------
	'GSUSEDRAFTS'          => true,                           // (bool) use page drafts
	'GSUSEPAGESTACK'       => true,                           // (bool) use page stacks for drafts, else manually pass `nodraft` or `draft` qs
	'GSDRAFTSTACKDEFAULT'  => true,                           // (bool) default page stack editing to drafts if true
	'GSSDRAFTSPUBLISHEDTAG'=> true,                           // (bool) show published label on non draft pages if true
	'GSAUTOSAVE'           => true,                           // (bool) auto save enabled, disabled if false, only used for drafts currently
	'GSAUTOSAVEINTERVAL'   => 6,                              // (int)  auto save interval in seconds,  only used for drafts currently