scmsteve

Thanks again! I have looked through the logs and it seems it is consistent and only that one product, so I can take a look at it and see if it was a converted product type and remove any old metadata.

I found this post about locating products without categories:

https://www.damiencarbery.com/2017/12/list-woocommerce-products-with-no-category/

I ran it on our site, and nothing was returned. I changed it from looking for 0 categories to 1 and it did return products, so the basic code seems to be working, so maybe we don’t have any products without categories. So what was causing the problem? Obviously that script and your code are looking at different things. ?? But having said that, the warnings to seem to be gone now.

Awesome! Thanks for clearing those warnings up. I installed the update and haven’t seen any since then. I realize it wasn’t probably affecting anything, just making more noise in the log. I also appreciate your insight on the cause, I’ll be looking into that as well to see how we ended up with that weird situation.

Unfortunately that did not resolve the issue here. I have been away all day, sorry for the delay in getting back to you.

Even more disturbing is that, as seen here, get_option at times fails to find the value at all. I don’t know if it was deleted and the add call failed because it thought it was still there or what exactly is going on. In fact, after doing the sequence of tests below I looked in the database and this option key is missing entirely, so it seems the delete worked but the add failed.

But the value being stored is time() so it should change on every call, the “current value” is from the first get_option(), then we do a delete_option() and add_option() with a new time() value. So below when it reports the Updated, new value is, and it is the same as the “current value”, that means it is a cached value and not the new computed value that should be in there. With the object cache portion of LSCache disabled this works as expected and I have never seen the option missing from the database at the end of the get/delete/add/get sequence.

[01-Feb-2020 03:09:38 UTC] SCM_DEBUG: Firing test, current value is 
[01-Feb-2020 03:09:39 UTC] SCM_DEBUG: Updated, new value is 1580526578
[01-Feb-2020 03:10:17 UTC] SCM_DEBUG: Firing test, current value is 1580526578
[01-Feb-2020 03:10:17 UTC] SCM_DEBUG: Updated, new value is 1580526578
[01-Feb-2020 03:10:53 UTC] SCM_DEBUG: Firing test, current value is 
[01-Feb-2020 03:10:53 UTC] SCM_DEBUG: Updated, new value is 1580526653
[01-Feb-2020 03:11:20 UTC] SCM_DEBUG: Firing test, current value is 1580526653
[01-Feb-2020 03:11:20 UTC] SCM_DEBUG: Updated, new value is 1580526653
[01-Feb-2020 03:12:57 UTC] SCM_DEBUG: Firing test, current value is 
[01-Feb-2020 03:12:57 UTC] SCM_DEBUG: Updated, new value is 1580526777
[01-Feb-2020 03:15:52 UTC] SCM_DEBUG: Firing test, current value is 1580526777
[01-Feb-2020 03:15:52 UTC] SCM_DEBUG: Updated, new value is 1580526777
[01-Feb-2020 03:15:58 UTC] SCM_DEBUG: Firing test, current value is 1580526777
[01-Feb-2020 03:15:58 UTC] SCM_DEBUG: Updated, new value is 1580526777

• This reply was modified 5 years, 2 months ago by scmsteve.

I wrote a small plugin that simply writes to the debug log the value retrieved from get_option, then does a delete_option, add_option, and prints a new get_option return value.

If LSCache *object cache* feature is enabled, I get the strange behavior the other plugin author ran into. The second get_option returns the same value as the first even though there have been an intervening delete_option and add_option to reset it.

If LSCache is running, but *object cache* is disabled, things work as expected.

Even stranger, I hadn’t specifically meant to have object caching enabled on the test site, it came as the configuration when I copied from our live site. I do have a redis instance there, but I hadn’t set one up on the test site, so I don’t even know what it is object caching to if configured for redis but none exists…

But this problem is happening on the live site and test site, so it seems something odd is happening in the base LSCache Object Cache feature.

Is there a workaround?

Would it be burdensome or troublesome to add those hooks under the advanced options in LSCACHE?

add_option
delete_option

That would ensure it is flushed when options are changed and they can’t get old data, right?

This may or not be related, but I was testing WooCommerce 3.9.1 update on our testsite with LiteSpeed Cache enabled, and after it did the update, a number of other plugins thought that the database had not been updated. Running WP-CLI ‘wp wc update’ triggered 75 updates going back from what looks like v2.00.

This behavior is similar to what the other plugin was seeing where options were not set properly, although the cause is not guaranteed to be the same as I have no way to know exactly what happened here.

If it matters, the LiteSpeed Cache plugin was disabled by the other developer during testing. When WooCommerce was updated, it was still disabled. I did not see those messages at that time. Then when I realized it was still disabled, I enabled it, and that is when these other messages appeared.

• This reply was modified 5 years, 2 months ago by scmsteve.

This is a little discouraging, it was the very reason I am looking at this plugin. ?? I am wanting to develop a mobile app, interacting with WordPress through the REST API and authenticating with JWT to get a token that I hoped, when the API was called, would be handled as though it were “that user” that authenticated.

Otherwise, as in your case, none of the content-restricted items are going to show up in the results the API returns and therefore will be useless.

I don’t know if that is at all the fault of this plugin, a WordPress issue, or just a failure to understand the required steps, but if anyone had an idea I’d love to hear it.

Having siad that, I haven’t tried this yet, and probably will just to be sure, but I fear it may be lost time if it didn’t work for you.

I reported the problem and can confirm that at least the WooCommerce Help Scout plugin is fixed:

2019-11-20 – version 2.2
Fixed issue ‘WP_Privacy_Data_Export_Requests_List_Table’ with wordpress 5.3.

Doing another grep, I found that a plugin “woocommerce-help-scout” had an include like this:

include_once ‘includes/deprecated.php’;

It isn’t prefixed wtih a path, and seems to somehow being triggering the wp-admin/includes/deprecated.php incorrectly.

Disabling that plugin allows me to re-install 5.3 without retriggering the error.

THe problem is when it is loaded in wp-admin/includes/deprecated.php. I realize this is strange, as it should (only?) be called from wp-admin/includes/admin.php which does previously include ‘class-wp-privacy-data-export-requests-list-table.php’ and ‘class-wp-privacy-data-removal-requests-list-table.php’, so these classes should be defined.

Yet the error given by deprecated.php shows they are clearly not however it is getting loaded/called.

BTW: Did a grep of all files in themes/plugins and those class names are not referenced.

• This reply was modified 5 years, 4 months ago by scmsteve.

On a live production site? ?? On every upgrade? ?? ??

I will see, but there is not a better way to find the actual cause of the error without this hunting in the dark blind disabling everything in site?

• This reply was modified 5 years, 4 months ago by scmsteve.

The backup restored from our live site, database and content, and had the same error.

I realize the patch would have to be applied each time, I guess my issue is wondering why it needs to be applied at all? The other comments on that ticket pointed to the idea that it was not a core problem, so how to narrow it down so that updates don’t break the site?

Please take the time to update the versions in the plugins, it is not helpful at all to see them lagging behind. I cannot just assume they are fine when there is no indication they have been tested.

• This reply was modified 5 years, 4 months ago by scmsteve.

The plot thickens, but I don’t know what it portends… I switched the web host from LiteSpeed to Apache, and this issue went away. No other changes. However, Apache is not as performant, and I don’t have time to fully test for any unintended side effects, so I put it back, and the problem came back. However, the other site we are running on the host should be running on the same server config/stack and it isn’t having this issue, so…. I don’t know what to think yet. ??