Dave Loodts

Hi @lapzor, the fix update of 1.0.31 has brought in a new critical error that seems to have more impact.
I’m trying to contact the plugin builder via the NL community. A quick rollback to version 1.0.30 will the best solution right now.

Hi, it is a general issue probably.
I contacted the owner of the plugin via the WordPress Slack Channel of The Netherlands, also asked the NL community if someone can send him an sms.

Meanwhile, don’t update. Or roll back to the previous version.

Hi Rich,

Thanks for the answer.

But what about users (like me) that don’t really want to use FSE. I’m more talking about custom sites. I’m now on a big project where i (can) use the theme.json file in a non-FSE theme.

But it’s bizar that WP allows the theme.json file to be accepted in a non-FSE theme, but not the global UI.That is strange, it’s either acceptance or blocking, right.

This all seems like global UI is made just to push FSE. But from my experience, this is not gonna work. Bigger/custom project won’t use FSE – certainly not the upcoming years- since their are too many risk of messing up sites. Let alone presenting/style customizing blocks to clients is already hard enough.

WP needs to open up the idea that pro-users will only need the “blocks” as a “content” editor, not “structure” editing. That’s not (always) gonna work for custom themes. And therefore WP needs to open up the Global UI for non-FSE themes too; otherwise it’s kind of ignoring a part of the WP users.

And working straight into the theme.json is not a happy thing to work on.

• This reply was modified 2 years, 9 months ago by Dave Loodts.
• This reply was modified 2 years, 9 months ago by Dave Loodts.

By the way: on the front-end; there’s no problem.

Thanks for the fast and clear respons. We’ll look into that. Thanks!

Hi, thanks. We deleted that row without any problem.

And thank you for the amazing plugin!

• This reply was modified 3 years, 2 months ago by Dave Loodts.

Hi Michael, your site is back again. But maybe a good idea to take a closer look at why the error is being shown in the dashboard. I’m quit technical, but i can imagine it will freak non-tech users like crazy. And probably they don’t even know who’s wpmarketingrobot as this is not mention in your plugin.

Thanks!

Thanks Ben!

It’s this site: https://www.7bees.com/product/b-complex/

We don’t use any Lazyload plugin at the moment.

We used one (Swift Performance) but we deactivated it, mainly because it made things worser in terms of Layzyload, even if the Lazyload was turned on in Swift Performance. Yes, i know, bizar. So, it has to be js caching issue with the code that Kadence adds into the productpage.

Hi, we had the same issue. Some products were not displaying in the category-overiews; on front and admin.

The work-around: Products > Rearrange Woocommerce Products > Sort by Categories > Select a category works… but isn’t there another “bulky” way.

We have a lot of categories… and the site has 4 languages… so it would take a lot of time to “re-save” it.

Waw, Thank you for the quick reply.
So to be clear: we can only use 1 fixed way of order in that meta query?

Mmm, i will look if i can extend that snippet to get the choosen Woocommerce order option

Hi Olaf, thank you for helping. It’s really the plugin code itself. I hired a senior developer to investigate it, he was highly surprised about the low quality of the code. He found a leak that we have passed to Moosend on 23 july. No reaction.
Just look at the ticket here, no response. They don’t really care, or they are overworked.

Regarding privacy, this is also an issue as it sends a request on every page visit. Well, that’s normal for a tracking plugin.

And last week, our site went down because Moosend’s tracking server went down. Because of the bad code of the plugin, an issue with their servers will cause outages of the connected site.
And it just slows down the site.

We have advised the client to search for alternatives.

Thank you for the quick reply and fix in the new version (we’ve contacted the support service via a contactperson)

I can confirm that it works. The error notification is shown.

The only “minor” point is still that a phone field is first not required. But when chosing the Afterpay, it is required. But still; WooCommerce indicates that the phone field isn’t required.
I don’t think you can do anything about this.

We’ve added this text to our AfterPay payment method:
Please add your phonenumer when choosing this payment method.

In this way, people can “expect” this error. Otherwise, it just looks odd.

The WordPress team decided that this plugin is not going to deactivate the new Gutenberg widget area. Instead, a new Classic Editor plugin is launched: https://www.ads-software.com/plugins/classic-widgets/