braunsch

Is this now another one of those plugins that all of a sudden does not get any support anymore?

Hello Ben –

Thank you for your continued support!

I just ran a “Verify Database”, and I also ran an “Update Database – even though the database version matches the WooCommerce version.
System and ll plug-ins are on the latest available patch level:

WordPress: 6.0.2
WooCommerce 6.9.4
WC Memberships 1.23.1
WC Subscriptions 4.5.1
Kadence 1.5.7

Here is an interesting twist to this problem:

I just exported my Kadence configuration, creating the “kadence-woomail-designer-export.json file.
Then I reset the Email designer to all default settings.
I ran my manual renewal – and it succeeded.

Then, I re-imported the file with the configuration settings. Together with my settings, the error came back, too.

This shows, to my mind, that the error is somewhere within the Kadence plugin – Apparently I have some configuration in my setup that broke, maybe with an update of the plugin. It also explains why you can’t recreate the error: I assume you just used the standard settings in the email designer plugin, and there, it works.

Is there a way to send you my Kadence email configuration settings file?

I have tested this with every plugin deactivated except for
– WooCommerce
– WooCommerce Memberships
– WooCommerce Subscriptions
– Disable Emails

This works. My order shows the message, “Payment to be made upon delivery. Order status changed from Pending payment to Processing”. My subscription is correctly updated. (note: I chose “Cash on Delivery” so that I could deactivate Stripe as well).

Now I activate, as a 5th plugin,
– Kadence WooCommerce Email Designer

When repeating the renewal process, I get two order notes: The same as above, and a second one saying “Error during status transition. Invalid order”. The subscription is not updated and remains on hold.

So, There isn’t much more I can deactivate…

When you ask, “what’s a path I can use to recreate this?” – I can give you a test login to a staging system so that you can recreate this – but not sure how to send the credentials to you in a confidential manner.

I appreciate your help!

Georg

Hello Ben –

More testing from my side.
I have another plugin (“WooCommerce Auto-complete orders” – which prevents all my orders for virtual products, like memberships, from hanging in “Processing” status.

Once I deactivate that plugin I am not getting any message in my PHP error log.

To further my testing, I activated every plugin related to WooCommerce – including Stripe (using “Cash on Delivery” instead). Unfortunately, my error did not go away: Manual renewal orders for subscriptions show the message “Error during status transition. Invalid order.” when Kadence Email Designer is active – and “Order status changed from Pending payment to Completed.” if I deactivate Kadence WooCommerce Email Designer.

Another addition: Created the PHP log – it has three lines:
[01-Oct-2022 01:23:36 UTC] status was called incorrectly. Order properties should not be accessed directly. Backtrace: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), do_action(‘template_redirect’), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::do_wc_ajax, do_action(‘wc_ajax_checkout’), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::checkout, WC_Checkout->process_checkout, WC_Checkout->process_order_payment, WC_Gateway_Stripe->process_payment, WC_Stripe_Payment_Gateway->process_response, WC_Order->payment_complete, apply_filters(‘woocommerce_payment_complete_order_status’), WP_Hook->apply_filters, sp_autocomplete_paid_virtual_orders, WC_Abstract_Legacy_Order->__get, wc_doing_it_wrong. This message was added in version 3.0.
[01-Oct-2022 01:23:36 UTC] status was called incorrectly. Order properties should not be accessed directly. Backtrace: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), do_action(‘template_redirect’), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::do_wc_ajax, do_action(‘wc_ajax_checkout’), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::checkout, WC_Checkout->process_checkout, WC_Checkout->process_order_payment, WC_Gateway_Stripe->process_payment, WC_Stripe_Payment_Gateway->process_response, WC_Order->payment_complete, apply_filters(‘woocommerce_payment_complete_order_status’), WP_Hook->apply_filters, sp_autocomplete_paid_virtual_orders, WC_Abstract_Legacy_Order->__get, wc_doing_it_wrong. This message was added in version 3.0.
[01-Oct-2022 01:23:36 UTC] The WC_Abstract_Legacy_Order::get_product_from_item function is deprecated since version 4.4.0. Replace with $item->get_product().`

Did not get the PHP error logs (yet) – but I found this here when preparing a WordPress log. Not sure if this helps.

I will see that I get PHP logs as well

[01-Oct-2022 00:07:07 UTC] status was called incorrectly. Order properties should not be accessed directly. Backtrace: require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), do_action('template_redirect'), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::do_wc_ajax, do_action('wc_ajax_checkout'), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::checkout, WC_Checkout->process_checkout, WC_Checkout->process_order_payment, WC_Gateway_Stripe->process_payment, WC_Stripe_Payment_Gateway->process_response, WC_Order->payment_complete, apply_filters('woocommerce_payment_complete_order_status'), WP_Hook->apply_filters, sp_autocomplete_paid_virtual_orders, WC_Abstract_Legacy_Order->__get, wc_doing_it_wrong. This message was added in version 3.0.
[01-Oct-2022 00:07:07 UTC] status was called incorrectly. Order properties should not be accessed directly. Backtrace: require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), do_action('template_redirect'), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::do_wc_ajax, do_action('wc_ajax_checkout'), WP_Hook->do_action, WP_Hook->apply_filters, WC_AJAX::checkout, WC_Checkout->process_checkout, WC_Checkout->process_order_payment, WC_Gateway_Stripe->process_payment, WC_Stripe_Payment_Gateway->process_response, WC_Order->payment_complete, apply_filters('woocommerce_payment_complete_order_status'), WP_Hook->apply_filters, sp_autocomplete_paid_virtual_orders, WC_Abstract_Legacy_Order->__get, wc_doing_it_wrong. This message was added in version 3.0.

It does not matter if I can create a Gutenberg gallery – because it’s not what I am using, and even though I want to replace my folder plugin I do not want to re-work half of my website.

If categories are attached the “wordpress way” to attachments (just like you can add categories to posts, pages, events (of my event plugin), you can read these from the database from anywhere in WordPress using php. See the example of the shortcode I was providing.
What is needed here is: If you are using wordpress built-in categories for your folders I’d need to know your prefix (= post type, I think). Categories for a regular post typically are “post-categoryname”, categories for my event calendar are “a1ec-categoryname”, categories for Joom Media Folder are “wpmf-foldername”, and regular “attachment” categories for the media/attachment post type are “attachment-categoryname”.

Is there a custom post type for FileBird? – and does FileBird add categories to the uploaded media based on this custom post type in order to assign a (virtual) folder?

Thank you Karina –

I have the plugin to create the document gallery, that’s not the problem, no need to re-invent it.

What I do need is the concept of assigning categories to the media files reflecting the folders the files are in. That way, I can pick files from a specific folder from everywhere in WordPress, not only from within the folder plugin (e.g. my gallery plugin can read the folders and make a gallery based on all files that I put into a specific folder, no additional action needed).

Thank you for yourquick reply!

Same here.

Apparently, this forum is not monitored by the developer…

ok – with latest version (2.19), this now is fixed. Thank you!

Unfortunately not… Still getting the same error

So – I think the problem is now reasonably resolved: After discussions with Dreamhost, I ended up reducing the amount of memory for the installation – from 512MB to 384MB, with a 180 second time-out. That in fact did enhance stability.
Now backups run end-to-end in a good 20 minutes.

Thanks for your help!

Just got a reply from Dreamhost. Their reply: “Unfortunately, your user’s processes are being killed for reaching the memory limit”.

My memory settings are: 512 MB in phprc, in wp-config and in wp-vivid.

I told the plugin to break files after 128 MB. Yet, the problem did not go away: this time it stalled three times:
– after 1.2 MB of backing up the themes (4.5 MB total)
– after 18 MB of the 2nd chunk of plugins (plugins are ~220 MB in total)
– after 43 MB of backing up the core (which should be ~45 MB).

In between, there were five “full-size” files (128MB) that ran through without any problems.

Never during the entire process did the WP memory usage plugin report more than 98.5MB of memory used.

Any idea how I can go about figuring this out?

Thanks a lot!

Thanks for your thorough replies. I took a moment for more experiments.

First, it is recommended to uncheck the ‘Merge’ option, because the merge will take more time to compress files.

I intentionally keep this because I want only one file. I have tried it – and the resulting many files are just a mess since they aren’t in the folder. The merge is not what is causing the backup time to be so long.

Next, since it’s with shared hosting that has a timeout limit, it is recommended to ‘compress files every’ 100-200Mb. Because when you set it to 1024GB, there will be only one zip, then in a timeout situation, the plugin will delete the failed backup files(together with temporary files and junk files) then try to backup the entire zip again, which will take more time, and may even cause the backup fail to complete eventually.

But when you set it to 100-200Mb, there will be multiple parts of files. When backing up part1 times out, the plugin will delete and retry part1 only, rather than the entire zip, which will save you great time.

Same problem: If I use this I will get dozens of files, which I don’t want.

The largest part of the excessive time is not the actual work being done (it probably would get an entire backup done in less than 20 minutes, if there weren’t all these timeout problems.
20 minutes is fine, and it does not matter if it’s 18 or 22 minutes. 90 minutes with five timeouts is not.

Therefore, we would recommend you increase the php max execution time on your server side to at least 900s, and set ‘PHP script execution timeout for backup’ to the same in WPvivid settings, so that you will not wait for the time difference.

Since wait time after stalled processes is the biggest problem I have, I upped my max execution time more carefully. 300 seconds on both sides, PHP and WPvivid Backup. Yet: After 155 seconds into the job, at the 48% complete mark (in the middle of processing uploads), the job apparently stalled (no more file growth). So, timeout at 300 seconds can not be the problem here. There must be something else that makes this not processing correctly.

Thanks for your great help so far!

Hello Tony –

Thank you for the detailed reply.

Indeed, it may be that my site has grown to the point of outgrowing the standard parameters of your plugin, So I changed some of the parameters – and then waited for an unattended backup to happen – to see if it really works again or not.

– I kept the “merge backup files into one” option – because the other one is a mess (as the program does appear not place all the files belonging to a singe backup into a separate folder for each backup.
– I enabled optimization mode for shared hosting
– Changed access mode to PDO – which sped up things big time.
– Compress files every 1024 GB as I want only one file
– backup timeout 300 sec
– memory limit 1024 MB.

The backup made it all the way to the end – but it took over 90 minutes due to several timeouts on the way. The following activities timed out:

[2020-08-24 00:04:51][notice]Prepare to zip files. file: https://www.baylands.org_wpvivid-5f4303d23e4c5_2020-08-23-17-03_backup_plugin.zip
[2020-08-24 00:13:11][notice]Prepare to zip files. file: https://www.baylands.org_wpvivid-5f4303d23e4c5_2020-08-23-17-03_backup_plugin.zip
[2020-08-24 00:27:04][notice]Prepare to zip files. file: https://www.baylands.org_wpvivid-5f4303d23e4c5_2020-08-23-17-03_backup_uploads.zip
[2020-08-24 00:43:39][notice]Prepare to zip files. file: https://www.baylands.org_wpvivid-5f4303d23e4c5_2020-08-23-17-03_backup_core.zip
[2020-08-24 01:05:44][notice]Uploading https://www.baylands.org_wpvivid-5f4303d23e4c5_2020-08-23-17-03_backup_all.zip Total size: 662.55 MB Uploaded: 334.00 MB speed:10223.62kb/s

This time, I did not see if the size was calculated or not – as this was a scheduled backup.

Item #2 (time-outs):

This looks like a timeout issue. We would recommend you to increase PHP max execution time to 1800s on your server side. Then go to WPvivid settings > Advanced Settings > Change the ‘PHP script execution timeout for backup’ to the same value.

I don’t think that the timeout setting is the problem: I have been looking at file sizes “live” on the file system while these processes were running (on other occasions, not this particular run because it was unattended). What happens is that it starts writing files (to the local directory). They start growing – and then the growth suddenly stops. Only then I can start looking at the time and see that the timeout limit starts counting. It just stops, and it does not matter if I tell it to wait for 5, 10 or 15 minutes – before it re-starts that piece of the job.
When it re-starts, it deletes the previous file and starts at zero again. If it runs without problems it’s usually done quickly: Backup_plugin, in the last (and successful) attempt, took 2 minutes, 5 seconds for 201 MB – far from the time limit of 5 minutes I gave it.
In the end:

Backup_plugins took 23 minutes (including two timeouts) for the 201 MB.

Backup_uploads took 16 minutes (including one timeout) for 617 MB

Backup_core took 21 minutes (including one timeout) for 42 MB

Later came the upload – which has one thing that baffles me a bit:

[2020-08-24 01:09:36][notice]Not responding for a long time.
[2020-08-24 01:13:56][notice]Add resume event succeeded.. arg1:1598231696 arg2:wpvivid_resume_schedule_event arg3:wpvivid-5f4303d23e4c5
[2020-08-24 01:13:56][error]Task timed out.
[2020-08-24 01:32:34][notice]Start upload.
[2020-08-24 01:32:35][notice]Check upload folder wpvivid_backup

Apparently the network connection was lost once (detected at 01:13:56). But, why does it take almost 20 minutes before it starts uploading again?

While the disconnected network (not between me and Google, but between Dreamhost and Google) is not in your or my control, I am surprised by the many problems that are occurring locally while compressing files.

Thanks a lot for your help!