Allow for whitelisting/blacklisting keys

[ivankruchkoff]

Allow for whitelisting / blacklisting of meta keys e.g. blacklisting:

add_filter( 'wp_post_revision_meta_keys', function( $keys ) {
return array_diff( $keys, array(
'foo',
'bar',
'_edit_last',
'_edit_lock',
'_encloseme',
'_pingme',
)});

This is a breaking change as previously the filter had array() passed to it.

To continue with the whitelisting approach is as simple as:
add_filter( 'wp_post_revision_meta_keys', function( $keys ) {
return array( 'foo', 'bar' );
)});

Also, now we prevent creating revisions for meta that doesn't exist. Previously, we'd save the result of get_post_meta( $post_id, $meta_key ) which would be the empty string.

[adamsilverstein]

@ivankruchkoff Thanks for this PR!

The checks for empty meta seem useful, I want to test with empty meta and make sure the unit tests account for that as well.

Regarding the blacklist/whitelist approach - in my original version i had complicated code that tracked which meta fields where revisioned for each revision - I like how your code does something similar to that by checking which meta keys were actually stored against the revision.

I also like how you turned the existing filter into a white/blacklist by passing the existing meta, however one of the big concerns for core is potential db bloat.

The idea of a pure whitelist approach is we only revision meta by request so there is no additional db use unless you explicitly revision some meta. This change appears to revision all meta by default. Still: I can see the use case for revisioning all meta and using a blacklist to exclude certain fields so it would be good to make that easier/possible.

I'm open to suggestions for the best approach here, ideally something with the flexibility of a single filter as you propose, with the default being no meta is revisioned. Perhaps a theme setting or separate filter that is used to turn on revisioning of ALL meta (without this the existing empty array would be the default)?

[ivankruchkoff]

My concern with the approach for whitelist/blacklist as two separate actions is that you will run into usecases of priority for each, that is:
whitelist everything in whitelist except for those items in the blacklist
blacklist everything in blacklist except for those items in the whitelist

That implies either mandating one approach over the other, or three filters whitelist1, blacklist, whitelist2 which allows for both examples above.

The alternative with one filter is that it's up to the plugin user to decide what is whitelist and blacklisted and which list takes precedence.