robertstaddon

Thank you!

Thank you!

I have notified LearnDash and they said that they are also looking into it. I will reply to your email right away!

I’m using the latest v3.2.8. Out of the box it works fine. But with certain other plugins installed that utilize WordPress hooks (such as in the backend or REST API), your plugin can trigger a PHP fatal error when the replace_cart_url() function runs. This is because WC()->cart can be null.

As you can see in this WooCommerce GitHub ticket, WooCommerce says that “we don’t load the cart in backend or REST API. So you need to check if is not?null?first, or even if?get_cart?is callable.” https://github.com/woocommerce/woocommerce/issues/23758

And this Stack Overflow article (and others that I could reference) reiterate that you need to check that the cart object even exists as well as that it is not empty: https://stackoverflow.com/questions/64425146/avoid-error-call-to-a-member-function-get-cart-in-woocommerce-function

That would be helpful. How can we get rid of this unexpected “grabbing an image from a post” functionality and can you add this to your documentation? Thanks.

So perhaps this bug has been in your plugin for longer than I initially thought. When can you get it fixed?

This is not correct. The documentation page that you linked to has always said: “Rank Math lets you set up a default OpenGraph Thumbnail, which will be considered as a fallback thumbnail for all your posts. So, if your post does not have a featured image / OpenGraph image set, then this fallback thumbnail will be used when the post is shared on Facebook.”

It says nothing about grabbing the first image in the post. The functionality spelled out in your documentation is the expected functionality.

And the functionality for the Default Open Graph Thumbnail itself inside of Rank Math says: “When a featured image or an OpenGraph Image is not set for individual posts/pages/CPTs, this image will be used as a fallback thumbnail when your post is shared on Facebook. The recommended image size is 1200 x 630 pixels.”

This is the behavior we have all come to expect. Whoever thought up the silly idea of defaulting to use the first image of the post instead of the clearly specified Default Open Graph Thumbnail failed to read your clear documentation or consult your customer base.

I am having the exact same issue with the latest version 4.4.0 of the Astra theme! Rolling back to the previous version works for now.

Your latest update solved the blank homepage issue. Thank you!

I just created a support ticket!

I also successfully tested the filter that you sent and it enabled me to update to the latest version of your plugin while still allowing products with decimal quantities to go through! Thank you!

Wow, you are right. So Stripe shows in the log a 400 error to POST /v1/payment_intents

The error message is:

parameter_invalid_integer – level3[line_items][0][quantity]
Invalid integer: 1.5

Can you add an option or hook to optionally disable level3 data in your plugin?

I can confirm that upgrading to Site Kit 1.107.0 resolved the issue for me. Thank you!

Well done! I can confirm that version 6.1.4 has fixed this conflict with Divi tag templates on my site. Thank you!

The?release of?The?Events?Calendar?6.0.12 in April broke?the?functionality of any?Divi?Theme Builder Archive page for WordPress Tags. The archive template no longer applies and instead shows a default WordPress page. Disabling?The?Events?Calendar?solves?this?problem.

I have had an open ticket with The Events Calendar paid support since May 11th and they were able to replicate the issue on their side on May 23rd. The latest word that I have received on the issue was June 15th when their support rep wrote, “I can assure you that the team is actively working on resolving this issue.”

It’s now August 10th and the current version 6.1.3 of The Events Calendar still has this bug with Divi. You currently have to keep your plugin on version 6.0.11 for full compatibility with the Divi theme.

I’m going to chime in here as another WPML user who just upgraded to Site Kit 1.106.0 and started experiencing this same fatal error as everyone else. I rolled back to 1.105.0 for now.