nicw.a11n

You are welcome to submit code on the repository, and this would probably be the best route to take, as adding a filter reduces the amount of work needed in maintaining the fork. I am aware of one other user who have the same use case, and who maintains code in this way.

There is a lot of complexity in switching accounts, as you have discovered, it is a unique use-case, and I don’t believe we are quite at the point where we are ready to attempt to fully support this in core.

Hi there,

I’d just like to confirm that if you set the logging level to info in WooCommerce > Status > Logging > Settings you will not exclude default logging, but will switch off the order debug logging.

This also does not affect your server level logging, which is different from WooCommerce internal logging mechanism, and does not affect WP_DEBUG settings.

Each logger using the WC Logger gets to set it’s own logging level. If a plugin is not declaring a logging level, or uses the default level, then info is used. This is one level higher than debug which means that all logs, such as transaction logs, should continue to function normally, unless the developer has explicitly set them to below the default logging level.

No WooCommerce logging that I am aware of captures deprecation notices.

Hi @mkdsgns

We’ve taken a closer look at where your error is occurring, and we’re worried that your solution is not quite going to do the trick. The problem is this:

The line of code referenced is this one where Square is adding the $subtotal amount to the $total_tax. As you can see, this is not a string concatenation but actually math.

At that point in the code, both variables are a float which means the sum should succeed. There should not a string in this calculation.

The presence of a string indicates an error occurring when either the subtotal or the tax total is fetched.

We would recommend trying checkout on a default Storefront theme, with the default block or shortcode checkout, with Elementor disabled and only WooCommerce and Square enabled.

If you’re then still experiencing the issue, you should open a ticket with us at WooCommerce so we can investigate further.

Hi @meatface888

Thank you for your patience. Are you able to access your database and run queries, and how comfortable would you be with running snippets of code on your site to help rectify the situation?

Because as we’re not able to see the same behaviour on staging, I’d say we need to look at the database and clean up some of the settings there which are causing the import job to initialize.

The following snippet should help with the reset: https://gist.github.com/nicdwilson/f93d0a71de7b2c7646561663b8832da8

It will create a log file, and is designed to only run once. Please test it on staging first, and backup your site before trying to use it. Once it has generated the log, switch it off, and share the log file here.

Note that we don’t usually share code like this in support, and we don’t guarantee it is safe or works, but I feel you have been very patient, and I’m hoping this will solve the problem!

Hi @itsmefti

Please reach out to us by opening a ticket with WooCommerce Support, and we’ll help you with the refund. The refund request option may not be available for a number of reasons, to do with our standard refund Ts&Cs but we’d be happy to look at this for you.

Hi there,

Looking over your System Status Report, I see that while you have HPOS enabled, and Custom Tables are authoritative, you are still syncing legacy order data. I would recommend turning this off, and then using the tool in WooCommerce > Status > Tools to remove legacy data from the wp_posts and wp_postmeta table.

You can re-enable sync at any time.

I’m not sure where you currently stand on SQL indexing, but a tool such as a SQL indexing plugin can be handy.

Could we try removing that additional data, and then if you could let us have another System Status Report, it would show us any changes to your database.

Hi @reberiii

Thanks for the update on that. I think it would be best if you could remove the file from file.io.

Editing products on admin is a database intensive process, and bulk editing does not reduce the size of the query, but actually increases the amount of processing which takes place.

You did ask if HPOS (High Performance Order Storage) would help and the answer to this is yes, if you have a high number of orders, it allows you to move meta data from wp_postmeta to the new custom order tables and remove the legacy order data from the wp_postmeta and wp_posts table. This reduces the number of rows in the table, where many heavy JOIN queries are run.

The impact will be higher as the number of orders increases. If you currently have no orders, the impact will not be significant at this point.

Performance of the admin dashboard can be improved by using an external object caching mechanism, such as Redis. In fact, I would say an external object cache is essential.

the server is a AWS Lightsail instance with 4 vCPU, 16GB of RAM and 320GB of storage.

Scaling vertically, so that your database server is separated from your web server, is recommended as your needs scale. This allows the DB server to be built optimally for the task, while the webserver can have a different configuration. Our experience at this point is that autoscaling solutions, rather than static individual server instances, might be better suited for larger stores.

Alternative methods of managing stock, which implement either through the REST API or through a plugin which is designed for bulk stock management (search WooCommerce bulk stock management) may be more efficient.

A pro tip here: running a CSV export, removing all columns but SKU and stock numbers from the CSV, editing the stock and then reimporting can be a quick and dirty way to manage bulk stock updates.

Could you please give us a copy of your System Status? You can find it via WooCommerce > Status. Select “Get system report” and then “Copy for support”. That will give us some idea of what we’re dealing with.

Awesome @miyagibonsai – I will mark this thread as resolved. Should you need any more help, you know where to find us 🙂