New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determining Grouped product/s from Child Product #14217
Comments
The whole idea is to make this a many to 1 relationship. There is not way to determine the parent, because there can be multiple parents. |
@claudiosanches We need to move this relationship information out of meta into a custom table (product_relationships?) and give it more thought in a future release. Having a separate table would mean we could have a get_parents method in the data store without horrible serialised data queries and would make Brents life easier. Since this is likely breaking (if using meta directly) this should be a 4.0 item. |
@mikejolley I like the idea of |
Product Bundles moved from serialized meta to dedicated tables since v5.0 for the same reason @thenbrent is mentioning. Developers needed an easy way to find which "bundles" a product belonged to for a variety of reasons, and we needed a performant way to query/sync availability data between bundles & bundled products.
See https://docs.woocommerce.com/document/bundles/bundles-data-structures-storage/ It's probably too late for PB to move its data to a WC core table like this, but there are quite a few extensions that could benefit for this structure. Mix and Match is one that comes to mind. |
On a related note, does the change to grouped products cause this to be obsolete: https://github.com/woocommerce/woocommerce/blob/3.0.3/includes/admin/class-wc-admin-post-types.php#L346-L348 |
Yes and no; there may be cases where parents are used.. but this change will stop it appearing after future updates #14521 |
I guess what I'm saying is that the parent is always |
@WillBrubaker Thats correct, it's obsolete for grouped products. I'm just saying there may be other use cases (not grouped products) where that could be used. We can remove it in 3.1. |
Note, once this table is in place we'll be able to tackle #14903 too. |
So just catching up, is there a way to get any/all of the parent product IDs from just a child product? As an example of necessity I am using setting children products to |
If anybody needs a workaround in the meantime: /**
* Get the first parent of simple product, WIP until better solution: https://github.com/woocommerce/woocommerce/issues/14217
* @param int $prod_id id of simple product
* @param bool $plain_id return id or post object
* @return post or id of grouped product
*/
function wc_get_first_parent($prod_id, $plain_id = true) {
$group_args = array(
'post_type' => 'product',
'meta_query' => array(
array(
'key' => '_children',
'value' => 'i:' . $prod_id . ';',
'compare' => 'LIKE',
)
)
);
$parents = get_posts( $group_args );
$ret_prod = count($parents) > 0 ? array_shift($parents) : false;
if ($ret_prod && $plain_id) {
$ret_prod = $ret_prod->ID;
}
return $ret_prod;
} It looks up the first parent it can find from the database, obviously not great from a performance point of view. Use at your own risk and let's hope we don't have to wait for a proper solution for too long. |
Any performance tips on @sftsk's implementation are welcome. I rely on reverse lookups like this. One tip: If you only need ID the get_posts should have
In my page all child products redirect to parent product, and all child products are listed in the parent product page. So I need to do this everytime I redirect the user, not a big deal perhaps but still. I also need to filter child products away from the main listings, so there needs to be some really performant way to do it. Having own mysql table would be the best way to do this in future, it should support fast queries forward from parent to child, and in reverse lookups. |
Tried the temp fix posted by Ciantic with a result of no change and still no grouped product titles in my order emails and or order listing in the dashboard. Not sure what I am doing wrong. Ciantic, can you assist? Really need this fix. |
Just to close the loop here, the workarounds posted above are the only way to do this right now. We are pushing ahead with a new 'relationships' table as we move meta data to custom tables. We're working on this as a feature plugin here https://github.com/woocommerce/woocommerce-product-tables-feature-plugin (currently private at time of writing, we'll open it up soon with an announcement on the dev blog). Essentially the table will link products to other products and will be use for upsells, crossells, and parent/child relationships for both grouped and variable products. The feature plugin will be released publicly before deciding on a core version (major) to include it in. Stay tuned to the dev blog :) |
Btw, I also created a plugin for this while back:
|
We've just come across the changes to the Grouped product relationship in 3.0. Especially this part mentioned in the release blog post:
While this change to the relationship is a good idea, the implementation makes it cumbersome to determine the grouped product ID/s from the child product.
In WC 2.6, it was possible to simply look at a child product's
post_parent
to determine the Grouped product's ID.Because the relationship is now recorded as a serialized array against the parent in post meta, it appears necessary to do a query searching for serialized data containing the child product's ID. e.g. for a product with ID
83
, you'd need to run a query like:(You can't just search for the ID, because you might get results where the ID is a subset of another ID, e.g. results for a Grouped product with child ID
183
when searching for child product ID18
).Is there a better way to find the parents from a child in 3.0?
FWIW, there's also no mention of this change in the 2.6.x to 3.0.0 Developer Migration Notes
UPDATED: clarified many-to-many relationships between parent/child weren't an issue, but still needed a way to find the parent or parents of the child.
The text was updated successfully, but these errors were encountered: