Interaction between WooCommerce create new copy of Product, and Publicize/Social

[arjenlentz]

Steps to reproduce the issue

• Install/Enable WooCommerce.
• Create a product, publish.
• Edit Product, select "Create new copy".
• See the Publicize/Social settings, and publish to see what actually happens (e.g. on Twitter).

What I expected

The Publicize/Social settings should be editable, and default to ticked.

What happened instead

The Publicize/Social settings are greyed out, and default to off.

However, when the copied product is published the publicize DOES happen (e.g. posts to Twitter etc). This the settings are greyed out, this cannot be adjusted at will. So it becomes a problem.

[jeherve]

Thanks for the report.

When you duplicate a post (or a product), you also duplicate post meta data that was created by Publicize on the original post to indicate that the post was pushed to your social networks. To solve that issue, we would need to customize the duplicate post feature to remove all post meta data star the string _wpas_ when duplicating a post.

There used to be a woocommerce_duplicate_product_exclude_meta filter in WooCommerce that would allow to exclude specific post meta when duplicating a product, but it looks like that filter was removed in 10d3e2d580cc7ad815eddf32ca486f5c5fb2d26c. I've opened a GitHub issue with WooCommerce to see if we could bring that filter back, and thus make sure it's possible to duplicate WooCommerce products without affecting Publicize: https://github.com/woocommerce/woocommerce/issues/13180

[arjenlentz]

Thanks @jeherve - the problem wouldn't exist though if the publicize settings weren't greyed out. Is this because the original post was already published and thus has a flag for that set, which is then copied?

[kraftbj]

@arjenlentz Exactly! Since the meta is set already to indicate an existing, published post, the Publicize settings are inactive since that post wouldn't be Publicized again via wp-admin.

[arjenlentz]

@kraftbj that's not actually what happens though, as in fact the copy DOES get publicized when Published (as the original bugreport notes).

@jeherve And even more "interesting", if you try this with a Product that is not publicized (the social targets unticked, then published), a copy will STILL get publicized!

So aside from the items being greyed out, a) the copied item gets publicized and b) this publicized logic appears to go ahead irrespective of the (greyed out) settings that are present.

[jeherve]

@arjenlentz That's indeed the expected behaviour right now: the status of the chexkboxes is managed via post meta data. You consequently can't trust the checkboxes at all when you work with a duplicated product right now.

Once https://github.com/woocommerce/woocommerce/issues/13180 is fixed, we should be able to add a compatibilty function to Jetpack, to avoid duplicating Publicize post meta when duplicating a WooCommerce product. Then you'll be able to trust and use the checkboxes again.

[jeherve]

woocommerce_duplicate_product_exclude_meta was added back to WooCommerce in https://github.com/woocommerce/woocommerce/pull/13202, so we could now go ahead and create a new compatibility function in this file to exclude all post meta including the _wpas_ string.

[JapeNZ]

Has there been any movement on this? I'm still seeing the grayed out area and am unable to change anything in the product Publicize area.

[jeherve]

@JapeNZ We haven't made any progress on this, but will update this issue when we do so.

[bindlegirl]

@jeherve Any news about this one? We had a question about it in 2694924-zen

[jeherve]

@bindlegirl No news yet, but as I mentioned above we'll update this issue once we make progress on this.

[aheckler]

Took a look at this just for fun, and I'm not sure of the best approach.

woocommerce_duplicate_product_exclude_meta requires that we define the meta keys to exclude ahead of time, and then it loops through what's given to it and removes those from the duplicate post metadata:

https://github.com/woocommerce/woocommerce/blob/master/includes/admin/class-wc-admin-duplicate-product.php#L153-L155

It doesn't pass the existing metadata through the filter, so it seems like we can't dynamically removing metadata starting with _wpas_?

It might be possible to piggyback on the woocommerce_product_duplicate_before_save action just below though.

[jeherve]

It doesn't pass the existing metadata through the filter

That's a good point. It may make sense to open an issue/PR at Woo to add this as a second parameter for the existing filter?

[aheckler]

This is possible now that https://github.com/woocommerce/woocommerce/pull/27038 has been merged. We should probably wait until WC 4.4.0 is released first.

[kriskorn]

@jeherve Do you think this could be now implemented after the above Woo change has been merged? Thank you! Have another user report here: #25508234-hc

[jeherve]

Do you think this could be now implemented after the above Woo change has been merged?

It may be worth a try, yes!

[jeherve]

This was also brought up in #25978 and #29779.

[github-actions[bot]]

Support References

This comment is automatically generated. Please do not edit it.

• [ ] 2694924-zen
• [ ] 7576752-zen

[sdarte]

So this issue has been going on since 2017? This is unbelievable. I've installed this and am close to having to dish out money for a product that is not functioning properly. This is quite annoying. I would think someone would have figured this out by now.

[formosattic]

Internal discussion: p1694325958239749-slack-C02JJ910CNL

Requested in https://wordpress.org/support/topic/unable-to-use-with-woocommerce-copy-to-a-new-draft/

[pablinos]

I think we might need to decide on the correct behaviour first and then unravel what's happening with the metadata.

There's an issue with how the metadata/publicize process is handled where on the local site, when a post is published, it's assumed to have been shared, and metadata is added to prevent it from happening again. But any new post that is synced has this metadata ignored and the publicize process will run on it. I'm not entirely sure of the history around this, but I have been meaning to dig into it for a while, and that is what's causing the behaviour of the post looking like it's not going to be shared, but in fact is shared on publish.

There is other metadata we could set to ensure that what happens reflects the UI on the duplicated post. That could be a fairly quick solution, which as this issue is 6 years old, is probably needed! But again we probably want to work out what's best. Maybe we would not want sharing to be enabled until the product is edited for example, or have the option to enable or disable it by default on duplicated products.

[JapeNZ]

A while back there was a snippet that added a 'clear publicize' button below the publicize box in the product edit page. You'd click the button and then be able to decide if you'd like to publicize or not, and add a custom message if necessary. This was a handy workaround for products created using the create new copy of product, as you could clear the publicize then publish the new product and have it posted on the socials. I think this is it HOW TO RE-PUBLICIZE POSTS WITH JETPACK but it's from 2014 and doesn;t do anything now. Not sure if it might suggest an option for the current version of Jetpack Social.

[jp-imagines]

Had another report of this in 7576752-zd-a8c. This user always creates copies of their existing products as a time-saving measure considering the complexity of their variable products, and not being able to control Jetpack Social settings is troubling.

Using the browser inspector to remove disabled="disabled" attributes on the input and textarea elements allowed them to be editable again and, after saving those changes and publishing, the updated settings seemed to work. (User had a copied product that didn't share to their connected accounts. They created a new copy, and I was able to use this HTML manipulation there to select their connected accounts and slightly modify the social sharing message, and the product then did get shared with that updated message.)

[sdarte]

jp-imagines

Using the browser inspector to remove disabled="disabled" attributes on the input and textarea elements allowed them to be editable again and, after saving those changes and publishing, the updated settings seemed to work. (User had a copied product that didn't share to their connected accounts.

How or where would I find this when I press F12 I am totally lost! Not a developer.

[jp-imagines]

@sdarte I can't guarantee that this method will work, and it's not something I would personally recommend if you're not familiar with using the browser console. It seemed to work for the person I was assisting last week, but I can't really be sure and haven't been able to test further since then.

This gif is a quick example of what I'd described above though.

[pablinos]

Do we have an idea of what the default should be for these duplicated products? If people have to resort to editing the HTML on the page, we should find a better solution!

Looking at https://github.com/woocommerce/woocommerce/issues/26192 it seems the solution is to use the woocommerce_duplicate_product_exclude_meta and exclude anything that starts with _wpas_. If we're happy with that then we can add it to our backlog. My concern is that as the duplicate gets published we'll run the Publicize jobs by default. That's a change in behaviour which could lead to products being shared unintentionally.