WPwebbouw

Since the update to 4.41.3 this has totally changed. Welcome emails are now moved to the new Marketing Automations. Nice feature, but unfortunately some things were moved from free to payed plans. There’s some documentation at https://kb.mailpoet.com/article/397-how-to-set-up-an-automation

With WooCommerce 7.90 the error still pops up when opening a product for editing. This is not resolved here.

Installing 7.0.2. fixed the issue.

Hi @niklasinpsyde, could you confirm that the issue in https://www.ads-software.com/support/topic/geen-api-sleutel-verschaft/#post-15368799 is also due to the 7.0.1. update and solved in 7.0.2.?

I noticed that in version 7.0.2. you rolled back the code to version 6.7.0. Could it be that the above described error was caused by the version 7.0.1. that was launched on 14-2-2022, since we started to see the error as of that version. And if this is what happened, will 7.0.2. fix this error?

Just wanted to let you know that all of a sudden on a working live site of one of my clients this error occurred. This resulted in the admin emails ‘New order’ not being sent. The error notice says the error occurred during a status change. Since status changes trigger emails this makes sense. The question is why does this error happen out of the blue? Should I re-enter the Mollie API key as the notice suggests? How can an API key that has functioned properly suddenly be missing?

I paste the error notice from the Order Notices below:

Fout tijdens statuswijziging. [2022-02-14T10:18:46+0000] Geen API-sleutel geleverd. Plaats je Mollie API-sleutels hieronder.

Same problem here.

This seems to be a javascript error, most probably related to the updated jQuery library that came with WordPress 5.6

Any ETA for a fix, @modalweb?

This is very annoying. I see Plugin Support personel here with only one type of response: “could you provide more details, I can’t replicate”. This bug has been very persistent since you moved the coupon management. It is a bug. I see it on all Woo sites I manage. Please fix it. Meanwhile I use some css to hide the thing.

One more detail: in de settings of the Toolset Form I had to delay the redirection of the form after submission with 1 sec in order to get the notification triggering working.

Hi @mplusb,

Sure. Where would you like to receive my screenshots? (e-mailaddress)

Good to know that this was not intentionally. I adjusted my star rating. I will adjust it even more after the issue has been solved.

Well but then your plugin contains a bug, as it apparently doesn’t recognise the fact that a post type had already been checked on the settings page. I had installed the plugin a while ago and had checked one of the (custom) post types.

After the update to the latest version the ‘nag’ panel was shown, even though the post type was still checked on the settings page.

Even after I saved the settings page again, the ‘nag’ panel persisted.

• This reply was modified 6 years, 3 months ago by WPwebbouw.
• This reply was modified 6 years, 3 months ago by WPwebbouw.

I did ??

Thanks, this works!

I tried disabling some of the browser cache options but no avail. Had to disable browser cache altogether to fix the broken front end.

@jeherve The files are identical. I’ll notify the antivirus provider. Thanks.