Rufus McDufus

I would love this option too! I have one or two users who keep hitting the subscribe button by accident, despite being told multiple times what it does. You just can’t teach some people…

Many thanks!

My problem is solved in this case as I can specify comments just on post type “post” and ignore post type “page”.

• This reply was modified 3 years, 8 months ago by Rufus McDufus.
• This reply was modified 3 years, 8 months ago by Rufus McDufus.
• This reply was modified 3 years, 8 months ago by Rufus McDufus.

Ah cool – I had a feeling the errors weren’t just from the plugin! I do normally keep the logger disabled – this was literally the first time I’d tried it.

Thanks!

• This reply was modified 3 years, 9 months ago by Rufus McDufus.

I’m seeing the same issue with 5.1 and 5.1.1, but limited to sites of mine using the Flatsome theme. These worked perfectly up to CF7 5.05 (though these would have used reCaptcha v2/Invisible and not v3 as mandated in the >5.1 CF7 versions).

I have some other sites with different themes and they’re OK with CF7 5.1 & 5.1.1, reCaptcha v3.

• This reply was modified 5 years, 11 months ago by Rufus McDufus.
• This reply was modified 5 years, 11 months ago by Rufus McDufus.

I found a workaround! I see you’ve added the ability to specify CSS for tooltips in the settings – very wise. I added ‘icon-box-left’, the CSS class for the featured box, and all works in IE11! I’ve no idea why, but it’s good!

Hi – sorry the slow reply. I haven’t tried other themes because I’m using a particular theme (Flatsome) element in the tooltip, in this case Flatsome’s [featured_box] shortcode which usually comprises an image and some text. It seems to garble the output on IE11 when the image is left or right of the text. If on top all is fine. I think this is a CSS precedence/override issue with Internet Explorer – the width of the tooltip (displayed with IE) corresponds to the width of the image – not image + text – so IE displays a very narrow and deep tooltip. However if I display the content itself outside of Tooltipy it displays correctly.

Thank you so much – that works absolutely perfectly and all is good now!

Am I right in thinking the logic in:

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;
}

might be wrong? Changing if( $add_ons == ‘no’ ) to if( $add_ons == ‘yes’ ) appears to work!

I’ve been doing a bit of rudimentary debugging.
The products which work (addons are added to variation price) appear to be ones which don’t have an entry in wp_postmeta (meta_key = ‘_variable_add_ons’). It’s likely these product variations/addons were added before I installed the WooCommerce Variable Product Add-ons plugin, (hence why they’re working?!).

The broken ones (where addon price is not being added to variation price in the cart) *do* have an entry in wp_postmeta but meta_value is set to ‘no’.
Here’s an example of one which is ‘broken’:
+———+———+——————-+————+
| meta_id | post_id | meta_key | meta_value |
+———+———+——————-+————+
| 5370 | 573 | _variable_add_ons | no |
+———+———+——————-+————+

The ‘no’ value means the $cart_item_data array gets set to ” in woocommerce_add_cart_item_data().
Presumably with the ‘working’ ones where there’s no _variable_add_ons entry in wp_postmeta mean $cart_item_data is being left untouched – just check, yes this appears to be the case.

That looks absolutely perfect – many thanks David!

Terrific – thank you so much!

I found the underlying reason. The problem was a metadata template in Adobe Bridge was being applied, but that template had the DateTimeOriginal field ticked (but no value given). The field was getting stomped over when the metadata template was applied. Strange it didn’t happen for all images, and strange only the PHP exif_read_data() function had trouble with it and not other tools, but hey.

OK, it turns out the exif data for my images (captured from a Canon EOS400D or 5D mk III) all seem to be slightly corrupt. Even images with good DateTimeOriginal values have bad values elsewhere. I did a little digging and it looks like PHP’s exif_read_data() function is returning bad data. No idea why because other tools including Adobe Bridge, exiftool, and exif seem to return good data. Weird. The PHP version is update to date in terms of packages available (Debian) but it does look like exif_read_data() doesn’t change too often.

Anyhow David suggested using xmp:CreateDate instead and this works perfectly! That’ll teach me to RTFM too – there are so many values available.

Many thanks David! Message sent.