[wp-hackers] Revisions API

[Mike Little]

On Tue, May 24, 2011 at 00:31, Dan Milward <dan at instinct.co.nz> wrote:

> Hey guys,
>
> Are there APIs/hooks for Plugins to refer to a particular (older) revision
> of a CPT and figure out what is the current revision of that CPT without
> have to do any SQL?
>
> Use case: /In our game engine a user can create a character sprite for a
> game that other people can use in their game. Once the user is happy they
> can publish their character sprite so that other people can use that in
> their games. (sprites/characters are custom post types).
>
> But if the user decides at a later date to change their sprite we don't
> want it to suddenly change for all the existing users of that sprite. We
> want them to continue to use the old revision and give them the option to
> upgrade to the latest CPT only if they want to./
>
> Any thoughts on this one would be appreciated.
>
>
>
Some thoughts off the top of my head.

* I don't think there is any specific API, revisions are just posts of
another type.
* By default, a revision is a *new* post record with a new ID and the
updated post keeps the same ID
* By default, meta data, attachments, and taxonomy info are NOT saved with
the revisions.

I created one plugin (CPT) for a client where I saved away the meta data
with the revisions, so the metadata would revert when they reverted a CPT,
some stuff I learned...

You need to do a *lot* of stuff on your hooks:
save_post - will get called first to save the revision as a new
post. wp_is_post_revision() returns the parent ID.
 1 - Go grab the meta data from the parent and copy it to the new revision.
 2 - Go grab taxonomy info and copy it to this new revision
 3 - Go grab the attachment info and copy it. Hmmm copy the image file too??
That could get messy quickly - better to have a rule to say no overwriting
images to update them. You may end up *moving* the attachment to point to
the revision (which will make the attachment the grandchild of the latest
post)
 4 - Go check if anyone is *using* the current post, and move their
relationship info to point to this new revision ID. Update a status item to
remember that they are now using an old copy, you don't want to do this step
again the next time a revision is saved.

Then save_post is called again (with the proper (parent) ID) to save the new
values, etc.


restore_post_revision - Just before this is called, the same process happens
(a new revision is created)
 1 - Go grab the meta data from the revision and copy it to the parent.
 2 - Go grab taxonomy info from the revision and copy it to the parent
 3 - Go grab the attachment info and copy/move it?
 4 - Don't update relation ship info (unless you want to handle restoring to
a revision that is being used, whereby those users are now back on the
normal version -- blimey!)

You will need to modify code that retrieves your CPT's because revisions are
normally excluded, even on the back end. You may need to modify code that
retrieves attachments because those are now children of the revision, which
is itself a child of the original.

You may want to watch status changes (published->draft etc,) too; but
probably not, unless you are forced to.

You'll need an interface to allow users to move to the new version of a CPT,
but the actual move is only updating their pointer/ and setting them back as
'normal'.

If I was a user, as soon as I had that facility, I'd want to be able to
change my mind and swap between old and new versions at will, and be able to
see all the old ones to choose from! #justsaying


Hope this helps.

Mike
-- 
Mike Little
http://zed1.com/