Ronaldt

@florismk you can install the beta mentioned earlier in this issue, works great.

Please read the last couple of posts.

Thank you for that update @femiyb, much appreciated.

Personally I find it odd and maybe even a bit concerning that a commercially supported plugin like Mollie’s takes three to four weeks to fix a bug like this. Mollie is in the banking industry and we have to be able to convince our clients to trust in Mollie too.

WordPress updates are important and even through translations are not that exciting (or even in the security category), having an update available for weeks on end makes me fear for the story about the boy that cried wolf.

I understand there are schedules in place and that translations are maybe not top priority but I would love it if a patch release could fix this problem that is bugging a lot of users (way more than actually post on this support forum, of course) that are using this plugin.

Just my two cents.

Thanks @crazypsycho! Just tested and it seems to indeed be fixed for me.

Same here, running a WP CLI command to clear Elementor cache. This runs in PHP 7.4, throwing the following fatal error:

PHP Fatal error:  Uncaught Error: Class 'WeakMap' not found in /home/USER/domains/DOMAINNAME/public_html/wp-content/plugins/dynamicconditions/Public/DynamicConditionsPublic.php:90
Stack trace:
#0 /home/USER/domains/DOMAINNAME/public_html/wp-content/plugins/dynamicconditions/Lib/DynamicConditions.php(165): DynamicConditions\Pub\DynamicConditionsPublic->__construct()
#1 /home/USER/domains/DOMAINNAME/public_html/wp-content/plugins/dynamicconditions/Lib/DynamicConditions.php(89): DynamicConditions\Lib\DynamicConditions->definePublicHooks()
#2 /home/USER/domains/DOMAINNAME/public_html/wp-content/plugins/dynamicconditions/Lib/DynamicConditions.php(273): DynamicConditions\Lib\DynamicConditions->__construct()
#3 /home/USER/domains/DOMAINNAME/public_html/wp-content/plugins/dynamicconditions/dynamic-conditions.php(70): DynamicConditions\Lib\DynamicConditions::run()
#4 /home/USER/domains/gemaaktindenoor in /home/USER/domains/DOMAINNAME/public_html/wp-content/plugins/dynamicconditions/Public/DynamicConditionsPublic.php on line 90

By the looks of it there is no problem on PHP 8.x but we cannot update the PHP version on CLI just yet.

Same here…

Warning: Undefined array key "cols_count" in /Users/ronald/Sites/[..]/wp-content/plugins/filter-everything/src/Admin/Widgets/FiltersWidget.php on line 577

For future self, or anyone else that stumbles upon this… I found a workaround here: https://stackoverflow.com/a/76455377/2082479

Can you make a backup of the file /wp-content/uploads/forminator/.htaccess and then try removing the line Options -ExecCGI from it to to see if that helps? That is what recently became a big problem for many of the websites we manage for clients (see ticket).

If it does not help, don’t forget to add it back in.

Can you make a backup of the file /wp-content/uploads/forminator/.htaccess and then try removing the line Options -ExecCGI from it to to see if that helps? That is what recently became a big problem for many of the websites we manage for clients (see ticket).

If it does not help, don’t forget to add it back in.

Can you make a backup of the file /wp-content/uploads/forminator/.htaccess and then try removing the line Options -ExecCGI from it to to see if that helps? That is what recently became a big problem for many of the websites we manage for clients (see ticket).

If it does not help, don’t forget to add it back in.

I’ve had some discussions with our server managers and we’ve come to the conclusion that you can’t expect a host to have ExecCGI enabled. We’re running DirectAdmin and because we’re hosting quite a lot of websites on there (300+) we take security very serious. And due to security reasons we don’t have CGI enabled by default.

@wpmudev-support8 can you explain why the option is used? Can it maybe first check if it is available on the server before it is added to the .htaccess

We have clients run their own website but do often recommend Forminator as a plugin to them. If we have to manually change the generated .htaccess for every website that is not manageable.

The problem is that ExecCGI is disabled on our live environment (running CloudLinux), the error is: /wp-content/uploads/forminator/.htaccess: Option ExecCGI not allowed here

In that .htaccess it states:

<Files *>
  SetHandler none
  SetHandler default-handler
  Options -ExecCGI
  Options -Indexes
  RemoveHandler .cgi .php .php3 .php4 .php5 .phtml .pl .py .pyc .pyo
</Files>

Is the option Options -ExecCGI added recently by any chance?
I can confirm that when I comment (# Options -ExecCGI) that line, the error 500 is no longer there and the styling is loaded correctly.

It is a website build with The7 theme (ThemeForest) with Elementor as page builder. I’ve tested switching themes and even falling back to a non-page builder page with a plain shortcode, but the problem stays.

I’ve downloaded the website to my local development environment, there isn’t a problem there. So it must be the fact that the stylesheet can’t be reached because of the error 500 on the live-server.

I’ll do some more digging on the server to see if I can find some more info there!
Will keep you updated.

@niklasinpsyde We had the same problem and the version you just linked fixed the problem for us too. Can we expect a quick patch so that I don’t have to manually update 12 websites? ??

Thanks!

I had the same here, it happened when updating WooCommerce to v7.2.3

Fatal error: Cannot redeclare as_unschedule_action() (previously declared in /home/USER/domains/DOMAIN.com/public_html/wp-content/plugins/mollie-payments-for-woocommerce/inc/woocommerce.php:50) in /home/USER/domains/DOMAIN.com/public_html/wp-content/plugins/woocommerce/packages/action-scheduler/functions.php on line 103

When I deactivate and remove Mollie, re-enable WooCommerce and install Mollie (same latest version as before) again it actually works.

I guess the plugins are loading in a different order by WordPress then? But with this workaround I’ve got it working.., for now.

Basic Auth for O365 is being deprecated by Microsoft. I think the Azure API is the only way to not end up with problems soon.

https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online