Page Preview does not autosave page template

[janeforshort]

When editing a published page, if you change the page template and then click Preview, the preview does not show the new template choice.

[Nano8Blazex]

patch -> for Google Code In

[westi]

I would like to include this in 3.2

Need to review if we need this much code or can just set the normal post_meta key on the revision that is going to be previewed.

[nacin]

Indeed. The patch works only due to a bit of a glitch -- update_post_meta() on a revision post ID ends up attaching the metadata to the post, not the revision. Calling update_metadata() on the revision ID itself is fine, we just have to then make sure we check the revision meta key using get_metadata().

[azaozz]

That's not a glitch, it's a feature :)

This came up shortly after we added revisions, in some circumstances post meta was attached to the revision and not the actual post, so the meta was more or less "lost".

[nacin]

Replying to azaozz:

That's not a glitch, it's a feature :)

Oh, indeed. The patch itself has a glitch, in that it attempts to add post meta to the revision, but then pulls it from be post. Which works due to our API, but I'd think it'd be better to add it to the post directly, otherwise it masks what's going on.

The lower level API will never change, so it's a convenient workaround.

[nacin]

Tested, seemed to work well. Made a few tweaks.

Then decided to try this a different way, by storing the value with the revision and getting core to recognize the revised meta value.

When I tested this, I discovered what the showcase template in Twenty Eleven really looked like. The initial patch broke is_page_template() and what not, so going lower in the stack definitely makes sense.

It would have been easier if I believed I should trust $_GET['preview_id'] or that I could easily pass the ID from _set_preview() to _show_page_template_preview(). Used get_the_ID() and is_preview() instead and it's working well here.

Possibility there should be a logic tweak or two to be had here. Please review.

[nacin]

Different route, hook into get_metadata.

[johnjamesjacoby]

Tested 11049.2.diff on twentyten and twentyeleven.

Confirmed working as intended.

[westi]

Missed the boat for 3.2.

Reconsider for 3.3

[jane]

In new version, please save all meta before preview so all info is correct and up-to-date.

[westi]

Replying to jane:

In new version, please save all meta before preview so all info is correct and up-to-date.

In an ideal world this is the solution.

I wonder if this could get tricky though and will fill the db with a lot of duplicate data.

It is going to be an interesting problem to solve and I think it is the right thing to do so as to ensure that Preview is Preview and all the things you might have changed are previewed.

[johnbillion]

Replying to westi:

Replying to jane:

In new version, please save all meta before preview so all info is correct and up-to-date.

In an ideal world this is the solution.

I wonder if this could get tricky though and will fill the db with a lot of duplicate data.

This route will of course make the post meta table explode in size. I wonder whether we could serialize all the meta data for each post revision and store it in one meta field.

The latest revision for each post could have its meta data copied over (so it can be used to display the correct post template in previews, etc) and every time a new revision is created we serialize the meta data in the previous revision and store it all in one meta field. This eliminates all the additional rows we'd otherwise see in the post meta table, and it also potentially allows us to revert a post's meta data along with everything else when a post is reverted to a previous revision.

Thoughts?

[nacin]

I like johnbillion's approach, but I would probably just make it save metadata for a preview revision and nothing else. Looking back 8 months later, I don't like my patch for that one reason — it looks like it saves the page template for all revisions, rather than just preview saves.

[mbijon]

What if we create a _wp_revision_template meta value that is only used and updated by previews?

If it's tied to the post instead of the revision we could only have one per-post, solving the duplicates issue. I'm assuming it's unlikely people would need to store the template per revision or per-preview.

This fixes the need to have meta on revisions, but does open the door for adding excess meta to posts.

[SergeyBiryukov]

Related: #20564

[SergeyBiryukov]

#25276 was marked as a duplicate.

[chriscct7]

Replicated on 4.3.1

[adamsilverstein]

Related: #20299, #20564.

With the ​post meta revisions plugin and the last patch on #20299, adding _wp_page_template to the revisioned whitelist using the wp_post_revision_meta_keys filter would fix this issue. The _wp_page_template meta would be revisioned and included in previews.

Another reason we should add revisioning of post meta to core.