jtowell

@markseton I am not sure what made you think that the issue is meant to be fixed in WooCommerce 7.6.1, but it is actually WooCommerce 7.7.0 which is yet to be released that the issue is currently scheduled to be released in. You can follow its progress on GitHub https://github.com/woocommerce/woocommerce/pull/37907

This is the fix that resulted from me raising the issue on GitHub ie https://github.com/woocommerce/woocommerce/issues/35752

My experience is the fix does still work, it is just that the line number effected has changed to line 750 as reported in your error. I continue to use this fix on systems every time a WooCommerce update is released and will do so until WooCommerce 7.7 is eventually released. It appears that WooCommerce 7.7 is currently at Beta 2 and definitely includes the fix. It also appears that this is scheduled for release on 9th May according to the following WooCommerce post https://developer.woocommerce.com/2023/04/26/woocommerce-7-7-beta-2-released/

Hopefully this will finally be an end to this issue.

Janette

PS. I am in no way affiliated with WooCommerce, I just happened to be the person that raised the issue on GitHub hoping to get it fixed. I never expected the process of getting it fixed to take over 5 months.

@tabaraksiyal this issue is finally due to be fixed in the next minor release of WooCommerce ie version 7.7, so you can either wait until this is released or go to wp-content\plugins\woocommerce\src\Admin\API\Reports\Customers\DataStore.php line 750 (assuming you have version 7.6.1 of WooCommerce ) and replace the line with

'date_registered' => $customer->get_date_created( 'edit' ) ? $customer->get_date_created( 'edit' )->date( TimeInterval::$sql_datetime_format ) : null,

You can access this file also via the Plugin Editor in WordPress. If you do not know how to do this, you may be best to wait until the fix is released.

All the best

Janette

• This reply was modified 1 year, 6 months ago by jtowell.

I couldn’t agree more. When I raised the GitHub request over 2 months ago (https://github.com/woocommerce/woocommerce/issues/35752) I had thought that being a fatal reproducible error that it might get fixed quickly. They keep adding odd comments like “5962802-zen” on GitHub but I have no idea what this means or if it is getting any closer to being dealt with. I am unsure if working out how to do a pull request on GitHub would get this dealt with any quicker. You are correct it was not fixed in yesterday’s WooCommerce update. That’s at least 8 updates since I raised it and it is still not dealt with. I completely understand it is a big product but when they release new features but don’t fix fatal errors, I just can’t understand it.

Could someone from Woo Support please explain the process.

Thanks

Janette

In an attempt to get this fixed as quickly as possible I have now created a GitHub issue for this Github Issue #35752
This is my first time creating an issue on github so hopefully I have done it all correctly.

I have just been looking into this further and it would appear to be an oversight in WooCommerce coding based on the fact that earlier in the same DataStore.php file on line 573, they cater to the possibility of the registered date being null ie

$data['date_registered'] = $customer_user->get_date_created( 'edit' ) ? $customer_user->get_date_created( 'edit' )->date( TimeInterval::$sql_datetime_format ) : null;

And given that the default value for date_registered (in the wp_users table) is null, it makes sense that they need to cater for this. How do we make this something that gets fixed in the next WooCommerce update?

Thanks
Janette

• This reply was modified 1 year, 12 months ago by jtowell.

We are also experiencing exactly the same error. Thanks @trepidationcouk for your temporary solution. It works nicely for now.

Thank you Syam this was resolved by the link provided in https://www.ads-software.com/support/topic/problem-with-php-8-4/
Regards
Janette

Hi Syam,
Thank you this has resolved the issue. It is interesting though that the version you linked to has the same version number as I already had installed ie v3.2.1.11184 but different code.
Regards
Janette

Hi,
You mentioned that this would be fixed in the next version and that was 2 months ago and there has been no new version, so unfortunately this is not resolved. In php 8.1 this now becomes a warning and a PHP fatal error ie

[03-Aug-2022 22:29:06 UTC] PHP Warning:  Attempt to read property "type" on array in ...wp-content\plugins\wpfront-user-role-editor\includes\widget\class-widget-permissions.php on line 112
[03-Aug-2022 22:29:06 UTC] PHP Fatal error:  Uncaught Error: Attempt to assign property "type" on array in ...\wp-content\plugins\wpfront-user-role-editor\includes\widget\class-widget-permissions.php:112
Stack trace:
#0 ...\wp-content\plugins\wpfront-user-role-editor\includes\widget\class-widget-permissions.php(230): WPFront\URE\Widget\WPFront_User_Role_Editor_Widget_Permissions->get_meta_data(Array)

When can we expect an update of this plugin please?
Thanks
Janette

Thank you for your response. It there an ETA on the new release that will include this?
Thanks
Janette

Due to receving no assistance, I further looked into this issue, and for the benefit of someone in the future that may encounter the same issue here is what I have found out and done to fix the problem.

1. In the plugin settings you can turn on logging, ie Product Feed –> Settings –> Control then toggle the “Enable log” to on.

2. This then produces a log file in my case every 5 minutes when the health check background task runs. You can view the log file either through WooCommerce
ie WooCommerce –> Status –> Logs and look for a log file name starting with “WPFM- ”
or you can find the log file on the server in wp-content\uploads\wc-logs

3. Looking at the last incomplete log entry this then gave me the product ID of when the error was occuring. It was for a product ID that didn’t exist in WooCommerce. How is this possible??? By looking for this ID in the wp_posts table where WooCommerce products are stored eg where 24803 is your product ID
SELECT * FROM wp_posts where ID = 24803
I was able to discover that a variable product (ie post_type product_variation) which had once existed and had been deleted from WooCommerce actually still existed in the wp_posts table. Now for the important part, the post_parent for this product didn’t exist in the wp_posts table. So this is an example of an orphaned variation. It was this ophaned variation that was causing the error.

4. Orphaned variations occur when you delete a variations parent without first deleting the variation product. WooCommerce has a way to clean up orphaned variations ie go to WooCommerce –> Status –> Tools and “Delete orphaned variations”. The other way is to exclude variations from product feeds.

5. In the process of all this I did also Clear the bathc and Purge the Cache in Product Feed –> Settings –> Control. I am unsure if this was absolutely necessary now but doing this at least got rid of the 5 minute health check cron job that had been causing the error to constantly be reported.

In summary if you have any orphaned variation products in your system it will break all feeds. Maybe this is something that could be coded for in a future version of this plugin.

I hope this is of some help to someone else.
Janette

I have discovered that there is a rex cron running every 5 minutes. ie hook wp_rex_product_feed_background_process_cron running action Rex_Product_Feed_Background_Process->handle_cron_healthcheck() I am assuming this is what is causing the bug to be reported every 5 minutes. Would it be safe to delete this cron and see if it fixes the issue?

We really need this fixed.

Thanks
Janette

Further information to my previous post, I have realised that the specific line of code that is causing the issue, is specific to WC_Product_Variation type products ie it is in an if that has just tested for this, and we have only Simple products no variable products. So I can’t understand how it is even reaching this line of code.

Regards
Janette