Aaron Axelsen

Hmm, I just tried this and set it to replace “Cat 1” with “Cat 2” at expire time. When I published the post, it was set to “Cat 1” correctly. When expiration came around, things were updates correctly to be only “Cat 2”.

Can you provide any more detail?

Do you have the debug log enabled? That may help provide some additional details.

I would start by checking for conflicts with other plugins. I can confirm that this does work on a vanilla WordPress 5.0.2 installation with no other plugins installed.

The other most common issue is that your web-host may not support WP-Cron – which is required for the plugin to work.

        
function woocommerce_add_cart_item_data( $cart_item_data, $product_id, $variation_id )
        {
            $add_ons = get_post_meta( $variation_id, '_variable_add_ons', true );
            if( $add_ons == 'no' ) $cart_item_data = '';
            return $cart_item_data;
        }

Based on my review of the plugin, when “add_ons” is true / yes, that essentially means that products add_ons should be disabled for that variation – correct? With that logic, I believe there is a bug and the above function should actually be:

        function woocommerce_add_cart_item_data( $cart_item_data, $product_id, $variation_id )
        {
            $add_ons = get_post_meta( $variation_id, '_variable_add_ons', true );
            if( $add_ons == 'yes' ) $cart_item_data = '';
            return $cart_item_data;
        }

This did correct the issue that I was seeing with my site. Hopefully this helps someone else as well!

I have the “Product Add-Ons” from Woo setup, and am using your plugin to hide those options on all but a single variation on this product. When that variation is selected, it does show the add-ons correctly on the front end, however the text value entered is no longer saved and passed along to the cart / order process.

I can try to get a fix implemented for this. Can you confirm with exactly how you are using this on your site?

If there is any hooks or anything that would make this easier, let me know – happy to make some tweaks to the post expirator backend

@soumilroy do scheduled posts work on the site? Typically, if there is a cron issue going on, scheduled posts also won’t work.

You can also disable the built in cron, and setup a cron job or schedule task to run at your specified interval. Inmotion has a guide here that gives you the general idea of how you might do this: https://www.inmotionhosting.com/support/website/wordpress/disabling-the-wp-cronphp-in-wordpress

@soumilroy what is different between the two wordpress installs?

Good luck with the other plugin! Please keep in mind that most plugin authors have full time jobs, and just offer up plugins for free to better the community. Sorry we cannot always offer immediate feedback!

If you are still interested in making this plugin work – can you confirm that the timezone is set correctly on your wordpress instance? What happens if you revert to version 2.2.2, do you have the same behavior?

Can you turn on the debug log, and then make an new post that is set to expire right away to see what happens?

What version of the plugin are you using? Also, what does the debug log show? Is WP-Cron enabled and available on your server?

That explains it .. the syntax I was using was not supported until php 5.5 (which I wasn’t aware of at the time).

What version of PHP are y’all running? I bumped the rev to 2.3.1.1 in case you got it before that other line was patched.

Sorry guys! Fixed up in 2.3.1. Cheers!