[wp-trac] [WordPress Trac] #43122: customize.php fails to load with default changeset_uuid

WordPress Trac noreply at wordpress.org
Mon Jan 22 05:05:49 UTC 2018


#43122: customize.php fails to load with default changeset_uuid
--------------------------+------------------------------
 Reporter:  bpayton       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Customize     |     Version:  4.7
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by westonruter):

 * version:  4.9 => 4.7


Comment:

 @bpayton sorry for the delay. Interesting. So you see two separate
 `customize_changeset` posts in the DB with the same UUID `post_name`? It
 has an actual status of `publish` or is it `trash` in this case because it
 was published and thus advanced for garbage collection? Are you seeing
 this happen on WordPress.com? It could be due to latency in DB
 replication.

 In particular, note that `\WP_Customize_Manager::find_changeset_post_id()`
 saves the located changeset post ID in the object cache, using the UUID as
 the key. If you then look at
 `\WP_Customize_Manager::save_changeset_post()` when it goes to insert a
 new changeset, you can see that it does `wp_insert_post()` but then
 immediately after it does not do `wp_cache_set( $uuid, $changeset_post_id,
 $cache_group )` like `\WP_Customize_Manager::find_changeset_post_id()`
 does. This means that potentially the DB write happens but there is a
 latency for the replication to happen, and then immediately after another
 call to `\WP_Customize_Manager::find_changeset_post_id()` is made and
 since the object cache has not been populated with the changeset's ID, it
 tries to do a query to find the post but it comes up empty because it
 hasn't propagated yet.

 If merely the object cache were updated with the UUID/post_id mapping it
 wouldn't be enough since the DB would not have the post in it yet, so
 perhaps in addition to preemptively setting the object cache with the
 UUID/post_id mapping the actual `WP_Post` for the newly-inserted
 `customize_changeset` should be preemptively cached via
 `update_post_cache( array( $post ) )` as well?

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


More information about the wp-trac mailing list