karlemilnikka

Thanks for the quick reply. I’m sorry to hear that such an important feature got removed from active development and put into the backlog.

It’s not only the cookies that are an issue. Just like we cannot make automatic connections to Google Fonts (until the US has changed their mass-surveillance laws), we cannot make automatic connections to Stripe. We’d have to rely on the article 49 exception, which required explicit consent. Keep in mind that I’m not a lawyer, so I’m not saying use of Stripe would be GDPR compliant under article 49. That’s just the only way I see we could use Stripe at all after the EDPS sanctioned the European Parliament for using Stripe as a payment provider.

I made a proof-of-concept-fix for Woocommerce’s own Stripe plugin by dequeuing the scripts ‘stripe’ and ‘woocommerce_stripe’ (from the wp_enqueue_scripts hook), and removing the payment option (using the woocommerce_available_payment_gateways filter) until consent to make an exception had been given. I haven’t been able to make a similar solution for this plugin (yet).

Thanks for the amazingly quick reply. Yes, it’s the connections to js.stripe.com from the visitor’s browser I’m referring to. I’ll look into blocking them with a third-party plugin.

I’ve set a reminder to add a review if can find a way to make the plugin work in a GDPR compliant mode.

Thank you very much for your quick reply and transparency. I’ll look into what we can do and take into consideration that it will require some custom development if we decide to use Stripe for our European customers.

Thanks for your quick reply. No, this is actually regarding the situation before any network connections are made or any Stripe cookies are set. Currently, both network connections and cookies are set before the user has given permission. This could be solved by adding a link in the checkout that has to be clicked before any content is loaded from Stripe’s servers.

Shahjahan Jewel has confirmed (in the official Facebook group) that they will open-source the email parser and let us host it ourselves. That way, we’ll be able to handle emails in a GDPR compliant way.

I just posted a reminder to check in on when it will be available.

This bug got fixed in Astra Theme 3.7.8, released on 2022-03-03.
https://wpastra.com/changelog/astra-theme/#version-3-7-8

Presto Player 1.8.6 was just released with a patch for the bug. You can safely switch back to Full text RSS after updating.

I’m glad to hear. Thanks!

Best regards
Karl Emil Nikka

Sure. This time, the issue was caused by a conflict between our website configurations and the latest version of our management tool WP Toolkit Deluxe. To reduce the amount of unnecessary styles and scripts, we restrict some plugins to only run on their own respective post types. For some reason, this caused WP Toolkit Deluxe to break all LearnDash CPT permalinks when the website was scanned (something that happens regularly and when the website is cloned to staging).

The reason I thought it was related to the previous issue (the one that actually involved Pods) was because Pods this time fixed the permalinks when I saved an extended post type.

The solution was to simply let LearnDash run unrestrictedly on the frontend, regardless of post type. I guess we’ll have to manually dequeue bloating scripts and styles, but that’s for another day.

(I’ve informed the cPanel team about the conflict.)

Final update. I’ve experienced the issue on a site where LearnDash’s post types aren’t extended by Pods. My current issue is hence not related to the previous one and not even to Pods. I apologize for my faulty conclusion.

I’ve so far not been able to pin down the cause of the issue. Since I cannot say for sure that it is related to a conflict between Pods and LearnDash, I mark this issue as solved again and keep investigating it as a bug within LearnDash.

Not yet. I’m trying to find a reliable way to replicate the issue (just like before) and I will get back to you as soon as I’ve found it. I just wanted to report the situation as soon as I discovered it in case other users are experiencing the same issue.

I’m sorry to say, but there is still a compatibility issue. Unfortunately, I haven’t you found a way to replicate it consistently. The URLs don’t change anymore, but they suddenly stop working and start returning 404s. The only way I’ve found, so far, to avoid the issue is to re-save the Pod for Swfd-courses (without making any changes) after every plugin update.