Preview changes on a published post makes all post meta "live"

[jakemgold]

Here's the use case. Client wants to preview an update to a published post (as the Preview Changes button correctly implies they can). This post has some important post meta that impacts that preview.

Here's the problem - because post meta is not saved to a revision (it looks for the "real" post), when the preview button is pressed, save_post runs, and saves the meta data to the real, published post, even though the user only intends to preview the change.

Without realizing it, the user has updated the published version. That can be prevented by not saving post meta to revisions (when using custom save_post hooks), but then there's no non-hacky way to actually preview the full changes.

I believe this bug has been present for a while, we just rarely use the Preview function on published posts, and when we do, probably never tested it with critical post meta.

[johnbillion]

Could you show the code you're using to save your post meta?

[bookwyrm]

This is being done by the update_post_meta function:

    // make sure meta is added to the post, not a revision
    if ( $the_post = wp_is_post_revision($post_id) )
        $post_id = $the_post;

Why wouldn't you want the postmeta data saved to the revision?

[coocoomoo]

added

[ryanduff]

So instead of updating the actual post_meta values with each revision, how about it saves an array of the post meta in one row of the post_meta table with the meta key being something like _revision and the id being that of the revision and not of the actual post?

The preview could work with that since you're essentially viewing that revision and we could grab the meta array for that and expand it out. The actual post would continue to use the unmodified entries in the post_meta table. On save the values would finally be pushed to the respective entries in post_meta.

The other option is a full blown post meta revisions system that Alex King proposed over in #20564

Either way, one route or the other needs to be picked before something can be implemented.

[jakemgold]

I think some branches (pun intended) need to be shaken on this one. I think this is in many ways a serious bug, at least if we want to have a serious Preview feature.

Solution proposed by @ryanduff seems a bit janky to me, and risky (size wise) if a significant amount of post meta is stored.

I think @bookwyrm solution is where my mind is going - it's not immediately clear to me at all why that block of code that prevents post meta from saving to revisions is in there (preventing database clutter... ?).

Like the deeper solution @alexkingorg is proposing in his related ticket, but not sure it even has to be that involved.

[SergeyBiryukov]

Version number indicates when the bug was initially introduced/reported.

[mintindeed]

You'd probably want to exclude some post meta that are specific to the main post, like edit locks. I imagine the patch would look something like this:

$exclude_meta_keys = apply_filters( 'revision_meta_do_not_copy', array(
	'_encloseme',
	'_pingme',
	'_edit_last',
	'_edit_lock'
) );
$current_meta = get_post_custom( $GLOBALS['post'] );
if ( is_array( $current_meta ) ) {
	foreach ( $current_meta as $meta_key => $meta_value ) {
		if ( in_array( $meta_key, $exclude_meta_keys ) ) {
			continue;
		}
		
		update_post_meta( $revision_id, $meta_key, $meta_value );
	}
}

[wonderboymusic]

You want to ignore everything starting with _
Those are supposed to be "private"

[jakemgold]

Replying to wonderboymusic:

You want to ignore everything starting with _
Those are supposed to be "private"

This isn't quite right.

First, it seems to me that some keys (like thumbnail id) should be revision specific (although this might open up another can of worms - I find it disturbing that selecting a new thumbnail immediately updates a published post without clicking "update").

Second, many developers use the prefix to prevent meta data from showing up int he free form "custom fields" meta box.

I think @mintindeed is more on the right track, explicitly ignoring certain keys, in a filterable way.

Are there any other keys we're missing that need to be attached to the "real" post?

[nacin]

This and #20564 would block #23314.

[WraithKenny]

#20564 blocks this ticket, but if/when that goes in, the show preview functionality would have to somehow pull the meta from the $preview instead of the $post :

In revision.php -> function _set_preview($post)... maybe set $post->preview_id = $preview->ID (or use a global) then set up a filter on 'get_post_metadata' to pull out the right data.

[WraithKenny]

rough pass, not tested. Will test when I get home

[WraithKenny]

worked with patch from #20564 ('versioned_meta') and the recent 23842.

[WraithKenny]

v2 uses get_versioned_meta_keys from the patch on #20564

[WraithKenny]

23842 included the gist of my 20299-2.patch (with an improved 'get_post_metadata filter, nice work kovshenin).

I think making _wp_post_revision_meta_keys() filterable, as well as adding some other core meta to the list (like thumbnail maybe) would solve this finally :).

[SergeyBiryukov]

Replying to WraithKenny:

I think making _wp_post_revision_meta_keys() filterable, as well as adding some other core meta to the list (like thumbnail maybe) would solve this finally :).

Related: #23973

[azaozz]

I think making _wp_post_revision_meta_keys() filterable...

_wp_post_revision_meta_keys() is specific for post formats, won't work for arbitrary meta. Even thinking it should be renamed to _post_format_meta_keys().

[ocean90]

Let's revisit this in 3.7.

[sanchothefat]

I have some code that gets around this problem for previews that doesn't feel too horrendous. It's a problem that's been really bothering some of our clients who want to preview changes to custom post types (eg. events) with lots of metadata.

Here's the gist: ​https://gist.github.com/sanchothefat/498ed66a48a4a56d349d

You don't get post meta for each revision rather the preview meta data is stored against the original post with a prefixed meta_key as others have suggested. It gets overridden on each update/preview and you won't end up with orphaned post meta. Works fairly well so far but those sound like famous last words...

[adamsilverstein]

test saving post meta to autosave wp_create_post_autosave

[adamsilverstein]

As far as I can tell - in trunk - the post meta is not saved to published posts when clicking preview. Testing using the 'Custom Fields' section of the edit post page, the values are not saved until I click publish (when a post is in the draft state, the meta is saved when I click the preview button).

I believe the ticket description is (no longer) accurate when it states "when the preview button is pressed, save_post runs, and saves the meta data to the real, published post".

The bigger, remaining, issue is: "there's no non-hacky way to actually preview the full changes". This is because the wp_create_post_autosave function does not save the post meta - when the preview is loaded from the revision, post meta is pulled from the parent post.

(The function post_preview calls wp_create_post_autosave for published posts, creating an 'autosave' revision, and returns a url for previewing this autosave. )

The current patch for #20564 (Framework for storing revisions of Post Meta) includes _wp_preview_meta_filter to display revisioned post_meta fields with the preview. Landing #20564 will go a long way towards fixing this and #23314.

[azaozz]

The "gist" of the problem is that clicking "Preview" submits the whole form, i.e. quite similar to clicking either Save or Update or even Publish, without changing the post_status.

For drafts this works well. It is equal to clicking Save Draft + View Post in a new tab. All data from all form fields (including those added by plugins) is saved.

However for published posts this is not ideal. The filters that run on updating and inserting posts can trigger all sorts of related tasks and many plugins are not aware that the post is not being updated, only previewed.

This needs standardizing. Thinking that best would be to limit what is being submitted on clicking "Preview" and "Preview Changes" only to post_title, post_content and excerpt. Then add a filter for additional form fields that will be saved and included in the preview. This could work by filtering $_POST. Even maybe set DOING_AUTOSAVE or perhaps DOING_PREVIEW.

[adamsilverstein]

Notes on 20299-3.patch​:

• First take, feedback welcome!
• Requires the ​wp-post-meta-revisioning plugin
• Changes wp_updating_autosave hook to wp_creating_autosave when creating autosave
• Adds wp_updating_autosave hook when actually updating autosave
• Sets DOING_PREVIEW so plugins know not to save meta on previews
• Includes revisioned meta field values as part of autosaves (expects key name to match element ID)
• Localises the list of revisioned meta keys so autosave.js knows which fields to add to the autosave
• When doing preview, uses the autosave revisioned post meta
• Includes a unit test verifying the fix, uses an include to pull in the wp-post-meta-revisions plugin

Testing:

• You can test the current patch using this ​simple plugin; set the theme to twenty-fifteen and choose a background color. Changing and previewing you will nee the new color, but the original post will remain unaffected. Notes: checks ​DOING_PREVIEW to avoid saving meta during preview; uses the wp_post_revision_meta_keys filter to ​specify meta for revisioning

[adamsilverstein]

[attachmen:20299.4.patch]:

• Update against trunk
• Cleanup
• Update for namespaced plugin

Note: Requires the latest version of the ​wp-post-meta-revisioning plugin

[azaozz]

Replying to adamsilverstein:

Looking at 20299.4.patch, there are some inconsistencies:

• Autosave has nothing to do with previews, maybe better to patch it in a separate ticket. Also, the patch just "pokes a hole" in it letting plugins pass through arbitrary data. Maybe that needs some structuring.
• $( document.getElementById( meta ) ).val() should probably be $( '#' + meta ).val(), or document.getElementById( meta ).value if you don't want jQuery.
• Namespaces are not supported in PHP 5.2, fatal error :)

Having a patch that makes core dependent on a plugin feels off. I understand it is just for testing, but thinking we need a better way.

[adamsilverstein]

Thanks for the feedback, much appreciated!

A few comments below:

Looking at 20299.4.patch, there are some inconsistencies:

• Autosave has nothing to do with previews, maybe better to patch it in a separate ticket. Also, the patch just "pokes a hole" in it letting plugins pass through arbitrary data. Maybe that needs some structuring.

Yes, this takes advantage of autosave to add the meta for the preview, that seemed like a natural progression from the current code. I will try adding structure. Not exactly sure how :)

• $( document.getElementById( meta ) ).val() should probably be $( '#' + meta ).val(), or document.getElementById( meta ).value if you don't want jQuery.

good suggestion, thanks. jQuery we have, I'm using document.getElementById out of habit, because it's faster.

• Namespaces are not supported in PHP 5.2, fatal error :)

Right. I switched the plugin to namespaced to make an eventual core patch a little cleaner, but really could switch back to a Class for 5.2 compat at any time if that is preferable.

Having a patch that makes core dependent on a plugin feels off. I understand it is just for testing, but thinking we need a better way.

The better way would be to merge the plugin into core :)

That let us solve this and a handful of other related tickets.

I have some time to put into this now. Should I suggest the plugin as a feature plugin? I made it a plugin because the code had languished for too long on #20564 and also to open it up to more users. I have heard from some people using the plugin successfully.

[adamsilverstein]

20299.5.patch​

• Switch back to class vs namespacing for PHP 5.2 compatibility

Still working on the other suggestions.

[adamsilverstein]

Related: #11049.

[adamsilverstein]

20299.diff​ :

• Refresh against trunk
• Use factory for post creation in unit test

[adamsilverstein]

20299.2.diff​

• Clean up docs
• Removed unused 'DOING_PREVIEW' constant
• This patch is pretty simple, the bulk of the functionality is in the wp-post-meta-revisions plugin

Note, requires the the ​wp-post-meta-revisions plugin.

[westonruter]

@adamsilverstein in regards to #11049 and not being able to preview a change to a page template, will the scope here also include addressing the issue where changing the featured image actually makes it go live immediately (the opposite problem from page template)? I couldn't find a trac ticket about this, but as a user I would expect to be able to set a featured image and then click Preview, and then actually _preview_ that change without it going live for all. The solution seems as simple as changing the featured image behavior to populate a hidden _thumbnail_id input so that it gets sent along with all of the other postmeta upon hitting Save or Preview. (In other words, the wp_ajax_set_post_thumbnail() should be eliminated.)

[adamsilverstein]

Replying to westonruter:

@adamsilverstein in regards to #11049 and not being able to preview a change to a page template, will the scope here also include addressing the issue where changing the featured image actually makes it go live immediately (the opposite problem from page template)?

Yes, this plugin plus some whitelisting would address this issue.

Previews currently rely on an autosave revision to load their data, and since post meta like featured image is not revisioned it gets saved, then the stored value 'previewed'.

All that should be required to fix this (after installing the plugin) is whitelisting _thumbnail_id with the wp_post_revision_meta_keys filter. The plugin already includes code to load the revisioned meta for previews, see ​https://github.com/adamsilverstein/wp-post-meta-revisions/blob/master/wp-post-meta-revisions.php#L38

If you have a chance, please give it a try: I will do more testing and refreshing of patches on my end soon.

[ocean90]

Replying to westonruter:

.... will the scope here also include addressing the issue where changing the featured image actually makes it go live immediately (the opposite problem from page template)? I couldn't find a trac ticket about this, but as a user I would expect to be able to set a featured image and then click Preview, and then actually _preview_ that change without it going live for all.

See #12922.

[adamsilverstein]

In 56714:

Revisions: framework for storing post meta revisions.

Enable the storing of post meta in revisions including autosaves and previews:

Add a new argument revisions_enabled to the register_meta function which enables storing meta in revisions.

Add a new wp_post_revision_meta_keys filter which developers can use to control which meta is revisioned - it passes an array of the meta keys with revisions enabled as well as the post type.

Meta keys with revisions enabled are also stored for autosaves, and are restored when a revision or autosave is restored. In addition, meta values are now stored with the autosave revision used for previews. Changes to meta can now be previewed correctly without overwriting the published meta (see #20299) or passing data as a query variable, as the editor currently does to preview changes to the featured image.

Changes to meta with revisions enabled are considered when determining if a new revision should be created. A new revision is created if the meta value has changed since the last revision.

Revisions are now saved on the wp_after_insert_post hook instead of post_updated. The wp_after_insert_post action is fired after post meta has been saved by the REST API which enables attaching meta to the revision. To ensure backwards compatibility with existing action uses, wp_save_post_revision_on_insert function exits early if plugins have removed the previous do_action( 'post_updated', 'wp_save_post_revision' ) call.

Props: alexkingorg, johnbillion, markjaquith, WraithKenny, kovshenin, azaozz, tv-productions, p51labs, mattheu, mikeschroder, Mamaduka, ellatrix, timothyblynjacobs, jakemgold, bookwyrm, ryanduff, mintindeed, wonderboymusic, sanchothefat, westonruter, spacedmonkey, hellofromTonya, drewapicture, adamsilverstein, swisspiddy.
Fixes #20564, #20299.