[wp-hackers] Revisions API

[Dan Milward]

Wow. Thanks Mike!!!

You've given us heaps to think about. If you ever want to see the WP powered Game Creator in Action let me know - that said I definitely plan to submit a talk for WordCamp San Fran on the topic ;P

Best,
Dan

On 25/05/11 3:35 AM, Mike Little wrote:
> 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