Almost anything is possible! 🙃

You’ll probably be interested in the guidance listed over at actionscheduler.org/perf, and you may also wish to use (and adapt as needed) the plugin it links to at the bottom.

Additionally, if you are able to take advantage of WP CLI, then you can instruct Action Scheduler to create new and custom queues that target specific groups of actions. You can then use your system scheduler (in lots of cases, this will be cron) to trigger your command at whatever interval you require.

I’m not sure what sort of workloads you are processing, but do be mindful of the dangers of consuming too many system resources, as this may have an adverse affect on the rest of your site.

Function WP_Block_Patterns_Registry::register was called incorrectly. Pattern content must be a string.

In relation to this error specifically, and if you have a means of doing so, you may wish to try deleting the _site_transient_woocommerce_blocks_patterns transient. For instance, via WP CLI, you might do:

wp transient delete woocommerce_blocks_patterns --network

If you don’t have access to WP CLI, you can perhaps instead use a tool such as Transients Manager to do this.

For very large files, and where a redirect is not your preferred option, it may be better to use X-Accel-Redirect/X-Sendfile option if you can (we realize that enabling this is not always possible, however), as this essentially short-circuits things and PHP’s involvement will be minimized. Some resources:

• https://woocommerce.com/document/digital-downloadable-product-handling/
• https://developer.woocommerce.com/docs/using-nginx-server-to-protect-your-upload-directory/

Do you think the max_execution_time is the reason why it’s failing?

Yes, what you’ve already noted seems quite likely. The force download method can work with very large files, but to do this reliably your host would need to lift these constraints and that is, unfortunately, out of WooCommerce’s control.

See the difference? One is https the other http … somehow I think that Woocommerce should catch this and fix the URL automatically if necessary.

I’m not sure that we could always reliably detect that this would be problematic. Additionally, site configurations can change and so a large number of HTTP URLs may already be in place, and then become unviable.

However, I agree we could warn if it seems likely to cause a problem, and possibly could add a tool to correct existing entries. Would you like to propose this as a new enhancement? Some final notes:

• There are some great options like serving large files from S3 that you might be interested in.
• You could consider entering URLs without specifying the protocol. For example, //example.com/path/to/asset.pdf

Hi @hebhansen 🙂

• It’s possible another plugin or even your theme is interfering with things. Have you tried troubleshooting/testing for plugin conflicts? See this guide for more information on how to do this.
• Normally, if WooCommerce detects a problem with a login attempt, it will display an appropriate error message. It sounds like that isn’t happening here, so the problem probably isn’t at WooCommerce-level (even if it happens to manifest through the WooCommerce-generated My Account area).
• You noted this happens to ‘other users’. What sort of accounts do these other users have—are they regular customers, or subscribers, or something else? If you create a fresh customer-level account for testing purposes, and test it yourself, do you find it works?
• Take a peek at WooCommerce ‣ Status ‣ Logs (and you may also wish to review your server error logs, if you have access to them). Do you notice any entries of interest, perhaps ones that correlate with the dates/times these failed login attempts were made?

Thanks!

@nicmare … correction, the pieces just clicked together. This is not an issue on WP Umbrella’s side, it’s actually something that can be replicated any time Action Scheduler 3.9.1 is present but loaded after an earlier version. We’ll look into a fix on our side.