esoderquist

I have finally been able to devote some time to track this down. Ultimately, the cause of the issue is the use of WooCommerce Webhooks. Ocean Extra fails to save metabox data properly when WooCommerce webhooks are used.

If one or more webhooks for product.updated is configured, the behavior I describe above is observed because of a new “scheduled-action” post being created during the product postback (triggering multiple save_post calls). The first save_post call will contain the $postId of the scheduled-action, not the base post, so metabox data is saved to the scheduled-action instead.

Rough steps to reproduce on WP 5.0.3, OceanWP 1.6.4, Ocean Extra 1.5.3, WooCommerce 3.5.4:

– Observe that metabox values save properly
– WooCommerce > Settings > Advanced > Webhooks. Create a new webhook for “Product updated” topic. Delivery URL must exist but can be anything for test purposes (google.com)
– Edit existing product
– Change metabox value and update product. Observe metabox values do not save.

Note: since the webhook doesn’t actually complete, you’ll notice future saves do complete as expected because a new webhook isn’t created since the previous one is still pending, however, if you cancel the in-flight webhook (Tools > Scheduled Actions), the failure to save reoccurs. In a production setting where webhooks complete as expected, a new scheduled-action is created during each product update leading to failure to save metabox data on each update.

Quick and dirty fix in my case was to check the post_type during the save_post call in class-butterbean.php:

Line 255:

// Save settings.
add_action( ‘save_post’, array( $this, ‘update’ ), 10, 2 );

Line 824 (also adjust the update function signature to include $post) :

$is_scheduled_action = $post->post_type === ‘scheduled-action’;

if ( $do_autosave || $is_autosave || $is_revision || $is_scheduled_action )
return;

Thanks!