Tagged: Related Field, Stale Data
- This topic has 3 replies, 2 voices, and was last updated 5 years, 4 months ago by
Jason.
-
AuthorPosts
-
-
September 18, 2016 at 9:34 pm #7348
rickParticipantHi Steve,
We’re using Piklist for a WooCommerce site and created a new ‘locations’ post-type to represent where a product ships from. We then created a meta-box for the WooCommerce ‘product’ type which allows a user to select from a drop down and assign which physical store the item is located in. From my understanding, this should simply add a new meta key in the postmeta table for this particular post_id. We then created a shortcode which conducts a custom query for items on a per-location level, and outputs products grouped by this meta key (the store location – store_location).
All appears to be working with this when new products are added in, and the queries successfully work. However, my client reported to me that they had at first listed a few products in the wrong location, and went into the wp-admin to update the location. They were able to do this, but the front-end of the site did not update; the product was still listed in the old location. I investigated page caching issues, but even with all page caching disabled the problem persisted across several products. I even looked into our server mem_cache with no avail.
I dug deeper into the database, and manually into the postmeta table to see what the store_location value was for the corresponding post_id. Surprisingly, the store_location value was the stale value that had originally been posted. Subsequent product updates did not modify this value. What is strange, however, is that in the WP admin product page appears to be saving the value as when the page is reloaded, the correct drop-down setting is selected so something is being saved, just not in the right place from what I can tell.
Please advise and thanks in advance.
Here’s my PHP code for the related fields meta-box.
<?php /* Title: Ships from Location Post Type: product Order: 2 */ piklist('field', array( 'type' => 'select' ,'field' => 'store_location' ,'label' => __('Select which location this item ships from.', 'piklist') ,'choices' => piklist( get_posts(array( 'post_type' => 'store_location' ,'numberposts' => -1 ,'orderby' => 'title' ,'order' => 'ASC' )) ,array('ID', 'post_title') ) ,'relate' => array( 'scope' => 'post' ) )); -
September 22, 2016 at 2:31 pm #7378
JasonKeymasterHi @rick!
Interesting. So just to clear things up, every relationship in Piklist has an owner and an owned object. In this case the owner is the product and the owned object is the store. Therefore, by default, the id of the product would be stored under the store’s meta (in the wp_postmeta table) as key
__post_relate.It sounds like the
__post_relatevalue is still the old product id in the database? If you manually change it to the new id does that fix it? What happens if you remove the row altogether and reassign the store from scratch?Let’s see if we can figure this out. 🙂
-
September 26, 2016 at 11:23 am #7395
rickParticipantHi @jason,
Thanks for responding. I was not aware that this is how the related field relationship worked in the database. If I understand correctly, with this relationship, you are saying that the store (owned object) would point to its owner using the __post_relate key. Upon doing the query in the wp_postmeta table for the store, I see many __relate_post keys representing the various products. However, when I a sample individual product, I still have the store_location field, which is where the stale data is. This essentially would be a pointer in the opposite direction, where a product points to the store that its at by storing the store ID. When I update this value the issue is resolved. That value in the defined store_location field gets initialized correctly but then never updates.
Am I misusing the related field in Piklist? The only relationship I really need to store is the product pointing to the store location by storing the store location post id in the “store_location” field of the product in the wp_postmeta table. Should the related field update the pointers from both directions?
Thanks.
-
September 26, 2016 at 1:40 pm #7396
JasonKeymasterInteresting, so it sounds like the old relationship meta wasn’t clearing for some reason. It’s possible that a relationship was formed somewhere during development and the query was later changed so the field wasn’t aware of a previous relationship to remove. I’d try removing all the relationship meta for the store and seeing if the problem persists when I relate the the two again and then change it.
The primary reason you’d want to use a relationship, as opposed to just a standard meta field, is if you want the relationship to be bi-directional. In this case if you want to be able to pull up a product’s location as well as pull up a location’s products, then a relationship is the way to go. If you only want to pull up a product’s location and that’s it, then a normal field should work just fine.
Hope this helps! 🙂
-
-
AuthorPosts
- You must be logged in to reply to this topic.