[wp-trac] [WordPress Trac] #55467: WP_REST_Meta_Fields::update_meta_value handles update_metadata return value incorrectly

WordPress Trac noreply at wordpress.org
Fri May 31 16:48:04 UTC 2024


#55467: WP_REST_Meta_Fields::update_meta_value handles update_metadata return value
incorrectly
--------------------------------+-----------------------
 Reporter:  wordpressscyt       |       Owner:  (none)
     Type:  defect (bug)        |      Status:  reopened
 Priority:  normal              |   Milestone:
Component:  Options, Meta APIs  |     Version:  5.9
 Severity:  normal              |  Resolution:
 Keywords:  needs-patch         |     Focuses:  rest-api
--------------------------------+-----------------------
Changes (by shanemac10):

 * status:  closed => reopened
 * resolution:  invalid =>


Comment:

 Replying to [comment:2 TimothyBlynJacobs]:
 > Hi @wordpressscyt,
 >
 > Welcome to trac! Yes, you are correct that `update_metadata` can return
 `false` in those instances which is why we first check whether the stored
 value is equal to the proposed new value before calling the function in
 the previous lines of the `WP_REST_Meta_Fields::update_meta_value` method.

 So I've been chasing a bug that has lead me to also find this issue as
 reported above, and upon closer look, I believe there is a possible issue
 here, and at minimum an opportunity to DRY up the code a little more.

 Even though `update_meta_value` says `// Do the exact same check for a
 duplicate value as in update_metadata() to avoid update_metadata()
 returning false.` in it, it does not appear to be truly "exact". Where
 `update_meta_value` uses `get_metadata`, `update_metadata` uses
 `get_metadata_raw`. `update_metadata` as calls `wp_unslash` on
 `$meta_value` beforehand. Admittedly, I am having trouble holding it all
 in my head and walking through the these processes side by side, and it
 may be fine, but I cannot tell. Whether or not there is an issue here, it
 would be prudent for these functions to call upon the same DRY function,
 that would call and check the meta values. This would truly be "the exact
 same check".

 Note: the meta value that is being checked and/or updated in my bug
 hunting instance appears to only be an integer 0 or 1. It's a value stored
 by a plugin, and when a post is updated it is not saved because of error
 returning from `update_post_meta` being called. I'm curious if the
 `get_metadata_raw` and `get_metadata` have a discrepancy in this case. If
 this helps in any way.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55467#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list