Peter Fabian

I agree it makes more sense to backup code+db together, but sometimes folks operate more liberally with updting/downgrading WC code (probably because it’s easier to upload new zip package than to restore db to a specific point in time).

Let’s have a simple example: Let’s say we decide to migrate coupons from wp_posts to wp_wc_coupons in WC 8.3. We can build 8.3 in a way that it can work with coupons in both locations. But once you migrate the coupons to the new location in the db, you cannot really go back to WC 8.2 code, as your coupons will not work (8.2 knows nothing about the new coupon location). Thus, updating the code to WC 8.3 and then updating the db once you see things are working fine could be reasonable way of updating the site.

Not saying this is bulletproof, but that’s my guess about why this was implemented years ago.

As for actual usage, @doffine got it right. Ideally by using a code snippet plugin (so that you don’t need to reapply this every time you update WP/WC), you should add the following code:

add_filter( 'woocommerce_enable_auto_update_db', '__return_true' );

• This reply was modified 1 year, 10 months ago by Peter Fabian.

With all due respect to bluehost support, the error message indicates that a library that’s in use in their plugin is conflicting with (most likely) another plugin that uses a dependency injection container (perhaps an older version?).

Additionally, I’m not quite sure what type of server settings they are asking for. Server settings are mostly handled by the hosting, not by us (a WordPress plugin), so in this case, I’d recommend trying to find out which plugin is conflicting with the Bluehost plugin (please check out the troubleshooting guide: https://woocommerce.com/document/how-to-test-for-conflicts/) and contacting support for those two plugins.

Hope that helps!

Happy to hear the site is funcitonal now.

The error you mentioned is a warning about functionality that will be removed in future PHP versions and should be harmless for now.

As for the coupon menu issue, this problem reported in GitHub seems related: https://github.com/woocommerce/woocommerce/issues/32187, so you might want to add your experience as a comment over there.

Thanks!

Thanks for sharing. This seems like an error is coming from a Bluehost plugin called “bluehost-wordpress-plugin”. Have you tried checking with your hosting provider (I assume it’s Bluehost) if they have seen this error before?

Hi @jpnl

This is to make sure people have an opportunity to backup their database should they choose to do so before a migration/db update is carried out. Especially in case someone wanted to roll back to previous WC version, it might be difficult to run an older WC code with a newer version of the database, as the code cannot anticipate the changes we will do in the future.

If you want this to happen automatically (e.g. in case you use some smart backup solution which can roll back your site including both the code and the database), you can use filter woocommerce_enable_auto_update_db and set it to true. This should remove the notices and run the db update automatically.

Hi @uwccpan

Would you be able to check if there’s any error in your PHP log? The JavaScript error are probably not the cause of the issue you’re facing with saving or publishing your pages.

Thanks,

Peter.

Hi Tom,

Thanks for reporting the problem. I believe this error might be caused by a failed install/unzip on your site. The error you shared suggests that some of the plugin files are still at version 7.6.1 instead of 7.7.0. I would recommend trying to reinstall WooCommerce, either via WP Admin or FTP, whatever works best for you.

Hope that helps.

Cheers,

Peter.

• This reply was modified 1 year, 10 months ago by Peter Fabian.

Hi,

Thanks for the further info. I’m fairly certain it must be one of the plugins interfering with the tax setup. I also tried this with WooCommerce only, tried also with the “EU/UK VAT Manager for WooCommerce” plugin, but wasn’t able to replicate the same problem on my testing site.

At the same time, I can see on your site that the resulting VAT is always 0 and that WC sends back the 0 tax as a response to any change in the billing country. There are many places where a plugin (or custom code) can filter the tax calculation, so the only way to find out is to disable all the plugins, switch to the default checkout experience and start from there. Ideally, you would test this out on a staging site (see below). If this vanilla experience is still not working correctly on your site, then this needs a deeper look.

You can clone your site to a staging environment and perform tests without modifying your live site or impacting customers. Many hosts provide staging facilities, so it’s worth checking in with them. It’s also possible to do it using the free [WP Staging](https://www.ads-software.com/plugins/wp-staging/) plugin.

Hi, we no longer support PHP 7.0.

Please see the rationale in this post: https://developer.woocommerce.com/2022/01/05/new-requirement-for-woocommerce-6-5-php-7-2/

If this is a new hosting account, then I would encourage you to check with your hosting company. You can tell them that you are seeing syntax error messages in the logs for return type declarations in PHP and they should be able to check if everything is in order. We test our code on PHP 7.0 – 8.0 on different environments from Windows to Linux to MacOS and haven’t seen this error yet, so it seems unlikely that it would be a problem with WooCommerce.

Another option would be that the code was corrupted somehow (e.g. incomplete installation), but since your site works now, I think the syntax error can’t be happening anymore, otherwise, you would just see an error message/blank screen.

If you find out more, please let us know. Thanks!

• This reply was modified 4 years, 4 months ago by Peter Fabian.

Hi @dideto

I’m just guessing here, but maybe this error comes from earlier when you ran a different version of PHP (PHP 5, most likely).

Since PHP 7.0 (which was released 5 years ago), the language supports declaring return types for functions, which is what we’re doing on that line in the PHP script.

My assumption, since you could send us your System Status Report is that currently, WooCommerce runs and works for you, is that correct? Because if you faced a syntax error in the main WooCommerce file and WC was active, you wouldn’t be able to visit any WordPress page on your website.

Therefore, I think you can ignore this error, unless it appears again.

Hope it helps!

• This reply was modified 4 years, 4 months ago by Peter Fabian.

Hi @nader2020 , sorry to hear you’re having problems. Were you able to identify any errors in the logs/on the screen that might help us fix the issue? Thanks!

Hi @aksutah, what features are you missing from WC? I don’t remember us removing any recently, so would be happy to help if possible. Thanks!

Hi @bizm8tech , thanks for your review. Have you had a chance to try and [troubleshoot to see which plugin WC might be conflicting with](https://docs.woocommerce.com/document/how-to-test-for-conflicts/)? It would help us to know which ones we should test with. Thanks!

Apologies for the problems! The error mentioned by @abuguda should be fixed in WC 4.4.1 we released on August 19th.