update_post_meta doesn't change post modified date

[DennisSmolek]

In building an application I wanted to query for posts that were modified since a specific date/time.

The only issue is the majority of our changes are to post meta and not to post content, this means these changes don't show up in the query.

To solve this I'm tying into the action, but I feel like this is something that should be done by default.

[nacin]

Changing this would change behavior in a potentially un-expected way.

If wp_insert_post() added the ability to change metadata (something we've talked about), this could be solved. Interesting. I'm not even sure the easiest way to "bump" a post's modified date.

[nofearinc]

propose update_post_modified_date

[nofearinc]

A possible solution is a helper function update_post_modified_date that would update the modified date on add, update and delete. Sample use:

add_action( 'updated_postmeta', 'test_update_post_date', 10, 4 );
add_action( 'deleted_post_meta', 'test_update_post_date', 10, 4 );
add_action( 'added_post_meta', 'test_update_post_date', 10, 4 );

function test_update_post_date( $meta_id, $post_id, $meta_key, $meta_value ) {
	update_post_modified_date( $post_id );
}

I'm not a great fan of the the lack of a common action for updating (also, deleted_post_meta includes $meta_ids instead of $meta_id), but it could work.

[nofearinc]

updated logic

[nofearinc]

Moved to a core function that uses a global collection picking all changed post IDs where postmeta was changed, and updating the DB with cache clearing during the shutdown hook.

[nofearinc]

So, the first patch implements the idea of a helper function that could be applied by a plugin as discussed with nacin. The second one uses the global array for performance reasons but runs in core and collects all post IDs with updated metadata which is what we discussed with wonderboymusic. The third update updates only post metadata which was found thanks to an issue with Query Monitor by johnbillion that we debugged here.

[johnbillion]

#30085 was marked as a duplicate.

[jeremyfelt]

#30492 was marked as a duplicate.

[swissspidy]

I feel like method 3 using the shutdown hook is not ideal, because it runs after all output is sent. For example, when updating post meta using the REST API, you want to return the new modified date, which this wouldn't allow for. Also, using global variables isn't ideal and shutdown is hard to test.

On the other hand, there can be lots of meta data changes in a single request, so using the shutdown hook is definitely more performant.

Long story short, 24266.4.diff​ is an updated patch that adds unit tests and also uses only 1 single DB query in update_post_modified_dates().

Pinging @rmccue for feedback.

[swissspidy]

Related: #34775.

Now that I think of this again, it might just as well be plugin territory as it seems like this might cause some unwanted behaviour. Thus, it be great if someone else could jump in.

[chriscct7]

This could cause a lot of unexpected things to occur. Many sites use the post modified field to show when the last public changes to post have occured, but a lot of plugins use meta for non-public internal things. Maybe limit the post modified change to only meta registered explicitly as public? Even still, I think this is better off as close as wontfix

[hellofromTonya]

This ticket was marked as a close candidate 4 years ago because it "could cause a lot of unexpected things to occur" and as @swissspidy notes "it might just as well be plugin territory".

What do we think today? Is this a wonfix and plugin territory? cc @swissspidy @johnbillion @nofearinc

Also marking as `needs-refresh as the patch fails against trunk.

[johnbillion]

Agreed, this is plugin territory. Post meta is used for a lot of internal things, eg. the _edit_lock field which gets set whenever a post is opened for editing without any changes being made.