adamsilverstein / wp-post-meta-revisions Goto Github PK

What's the status of this plugin for Wordpress 5.8.2? Does it work?

Also the plug in page https://wordpress.org/plugins/wp-post-meta-revisions/#description seems to not be up to date.

Sometimes when previewing changes, neither wp_creating_autosave nor wp_before_creating_autosave fires, and thus the meta isn't saved to the revision. I believe it has something to do with timing; possibly that revisions aren't stored until WP has sent its first 'autosave' heartbeat. I haven't dug into the WP code yet to determine why that is. See demo below:

(Note, this is with #40 merged, so that meta previews work)

Using the beta tester plugin to indicate and download updates
https://wordpress.org/plugins/plugin-beta-tester/

Version 0.6 changes seem older than 0.1.8.

I noticed for some reason, all meta for a single key is stored as a single meta key (serialized array) in the revision meta, this makes calling get_post_meta on a revision return an array-encapsulated data rather than the data you would get from calling get_post_meta on the parent post. I just wondered why that was?

When creating a revision's meta entires, it will create meta values based on whitelist, so even if the copied post didn't have a meta value with that key, the new revision will have a blank key because theres no check to see if that key existed.

At this point I'm sure this plugin ever worked.
I already had Advanced Custom Fields installed when I installed this and so I thought was I was seeing was a working plugin. I've since wiped and re-installed WP with this being the only active plugin and I cannot see it work in the least. No matter what I change, I cannot see custom fields in the revision timeline nor to their values come back when I restore old versions.
Can you please help?

The posted data is checked only against the meta key, which means that a plugin could not name a field something different and revision its post meta, e.g. <input name="my_plugin[my_meta_key]" />. While I think that's a reasonable default, it should be possible to decouple field input names and meta keys.

The function add_metadata_preview_filter doesn't seem to ever be called. How does this get called or used?

/**
 * Add the revisioned meta to get_post_metadata for preview meta data.
 *
 * @since 1.0.0
 */
public function add_metadata_preview_filter() {
	add_filter( 'get_post_metadata', array( $this, 'wp_preview_meta_filter' ), 10, 4 );
}

Create new post, enter title and a custom field. Publish.
Change custom field value. Update

Expected: See Revisions link in Publish meta box.
Results: No Revisions link.

Revisions are not available until a change is made in the native fields.

Hi,
I noticed that the _add_metadata_preview_filter method never gets called. Is this intentional? Why is the add_filter function it uses not called in the constructor?

Hi,

I use ACF PRO and ACF Extended on my site. On posts with a Custom Post Type, I'd also like to save revisions with these Custom Fields that I created with the ACF plugin. Can i do that?

Another question I'm interested in is whether I can get these revisions and information about ACF fields on the Front-End as well?

The current functionality in the _wp_autosave_post_revisioned_meta_fields() method takes the meta value directly from the $_POST variable. In instances where a complex meta value is built from several post fields, cleanup/sanitation of the post field occurs, or the post field name differs from the meta key name, this approach will not work.

Generic example:

// Assuming 'custom_field' is part of the wp_post_revision_meta_keys filter
$yes_no_prompt = isset( $_POST['custom_field'] ) 
   && '1' === $_POST['custom_field'] ? 'Yes' : 'No';
update_post_meta( $post_id', 'yes_no_prompt', $yes_no_prompt );

The revision post meta for the code above would be the value of whatever $_POST['custom_field'] is and would not have the yes_no_prompt post meta.

A possible solution would be a filter in the _wp_autosave_post_revisioned_meta_fields() method that allowed a theme/plugin to override the posted value with whatever should be saved. I can work on a PR for this.

please can you add CMB2 support?

It dosent work with Cmb2 fields, can't figure out why, my guess i that have somthing to do with cmb2 hooks.

Using this plugin to get meta data storing in revisions on a client's website. Whereas the meta data stores fine after registering their meta keys, I cannot seem to get the preview functionality working.
I noticed that it was turned off by default so I assume this is a known issue. But since the client asked to be able to preview their changes I thought I'd enable it and try and get it working.
Sadly I ran out of time for this but what I found was that the autosave revision does have meta data stored against it, but that the data is empty. It seems that the _wp_autosave_post_revisioned_meta_fields method does not get called when the autosave gets created.

Hope someone will find the above helpful in solving this as previewing the meta changes would be a fairly nice feature to have. If I get more time later I'll give it another go.

_wp_post_revision_meta_keys() is used a few times, but because of the class, it's actually a method.

I'd recommend using a namespace instead, as this will make it work a little more nicely. :) (It will drop compat with 5.2, but only when testing using the plugin. This means less changes between the patch and the plugin too, since it should only require adding/removing the single line for the namespace.)

Originally from: #43 (comment)

I've had a quick look and would like to propose the following:

1. Do the whole fixing in a separate PR.
   Existing open PRs will need to be rebased after that PR has been merged, so those will be tested properly.
2. Do it with a holistic look at the whole devops setup.

Having said that, I'm looking at:

• Adding a .gitignore file.
• Adding a .gitattributes file.
• Adding a composer.json file.
• Actually running the unit tests in Travis.
• Linting against various PHP versions in Travis.
• Running PHPCS in Travis. I propose to run against the WordPress-Extra or WordPress ruleset, as well the PHPCompatibilityWP ruleset.

Questions:

• What do you think about the above proposal in the first place ?
• Any feedback on the proposed PHPCS rulesets ?
• What is the minimum PHP version you want to support at this moment ? 5.2 still ?
• What is the minimum WP version you want to support ?

I may have additional questions once I start setting things up.

Hey. Just wondering if anyone can tell me if this plugin still works?

This can be somewhat tricky because the meta values are expected to always be strings. See https://core.trac.wordpress.org/ticket/29920.

When carrying out a series of post / post meta updates, it doesn't appear to store the two in sync properly.

Replication
Create a new post.
Add post content 'Content 1'
Add meta in a whitelisted field 'Meta 1'
Save content

Make content change 'Content 2'
Make change to whitelisted meta field 'Meta 2'
Save content

etc.

Click on revisions created and restore.
Post content example 'Content 2'
Meta content example 'Meta 1'

Expected result
I would expect that restoring 'Content 2' would result in also restoring 'Meta 2'

I tested this and it is saving the revisions and when restoring a revision it definitely rolls back my assigned custom fields but in the revisions screen I do no see them.
I tried adding this code but it did not help though this code does work when I save meta fields using other code (that I want to drop because of drawbacks):

function dc_dcb_pmr_fields( $fields ) {
    global $post;
    $fields['meta_slugl'] = 'Meta name';
    return $fields;
}
add_filter( '_wp_post_revision_fields',    'dc_dcb_pmr_fields' );

Is this something anyone here got working or is it not supported?

We are using CMB for the custom meta boxes. (I know it is deprecated but waiting for a whole site refresh to migrate away).

There is a non-unique meta key ph_tabs with an array as value. The data is saved as follows in the database

The metadata for the autosave is fetched from $_POST.

Plugins like CMB send the data in a array and this caused for the data to be saved as one big array instead of seperate rows for each array.

This is how the $_POST looks like:

Array (
[ph_tabs] => Array (
    [cmb-group-0] => Array (
            [ph_tab_title] => Array (
                    [cmb-field-0] => New tab
            )
            [ph_tab_content] => Array  (
                    [cmb-field-0] => Content
            )
    )
    [cmb-group-2] => Array (
            [ph_tab_title] => Array  (
                    [cmb-field-0] => Tab Title
             )
            [ph_tab_content] => Array (
                    [cmb-field-0] => Content second tab
             )
     )
)
)

I will create a PR with a fix.

The file hosted here:
https://wordpress.org/plugins/wp-post-meta-revisions/
https://downloads.wordpress.org/plugin/wp-post-meta-revisions.0.1.8.zip

contains files not required for the plugin to be used, including an additional trunk folder.

It may be better to only add wp_before_creating_autosave once core-#20299 is closed and the filter is in core.

This case has no delete_metadata: https://github.com/adamsilverstein/wp-post-meta-revisions/blob/master/wp-post-meta-revisions.php#L133

While this case does: https://github.com/adamsilverstein/wp-post-meta-revisions/blob/master/wp-post-meta-revisions.php#L62

Was there a specific reason delete_metadata was excluded?

1. Add versioning to any meta field
2. Make a post with that field
3. Edit that post's field
4. Revert
5. Post has now reverted to empty field.