Stuck feed, WP Cron Confirmed OK

  • Resolved magicoders

    (@patopaiar)


    3 years, 10 months ago

    Hi!

    We have an issue with the feed getting stuck at 4% on a site with 50,000 products, 10,000 products actually and the rest variations.

    The site is on a robust hosting, running on a well setup and configured server.

    WP-cron is enabled and running normally, this has been checked.

    Set the products per batch to 2,500 as recommended and also tried with this setting in Off.

    We have deactivated and activated the plugin, cancelled the stuck job and manually triggered it again. Refreshed browser tried as well.

    No matter what we do, it still gets stuck at 4%.

    PHP error logs show nothing.

    This site does have a very long history of feeds. We also noticed this generates a large autoloaded option saved to wp_options that is detrimental to performance. This is a separate conversation, but wondering if something is exhausting with this long history.

Viewing 11 replies - 1 through 11 (of 11 total)
  • supportadtribes

    (@supportadtribes)

    3 years, 10 months ago

    Hi,

    Did you also check the WooCommerce fatal error logs of today and yesterday? I can imagine that with these product and batch amounts you can still run into server configuration limits such as timeouts or CPU usage limitations. Those should show in your WooCommerce fatal errors logs that can be found here:

    https://docs.woocommerce.com/document/finding-php-error-logs/

    Thread Starter magicoders

    (@patopaiar)

    3 years, 10 months ago

    There are no backend fatal errors.

    Could the server be interpreting any request from your plugin as a frontend request?

    I am also seeing that the cron jobs that get generated to process the next batch are not getting created.

    Does this help point to a problem?

    Are there any particular cookies, query strings, or URIs that we could exclude from cache?

    supportadtribes

    (@supportadtribes)

    3 years, 10 months ago

    I am also seeing that the cron jobs that get generated to process the next batch are not getting created.

    The initial batch is being triggered either by a manual update or an automated update. The 4% processing you are seeing indicates that only this initial batch has been processed and no follow-up batched were triggered. Every time a batch is finished the plugin will create a new cron event to fire off the next batch. This process continues until the feed contains all products.

    So it sounds like there is a problem in the above process. We understood from other users that firewall/security or even caching plugin’s sometimes have settings to prevent new cron events from being created by other users or plugins (a permission issue). Could this be happening in your case?

    Thread Starter magicoders

    (@patopaiar)

    3 years, 10 months ago

    This is an nginx server with caching enabled, which cannot be turned off.

    We can whitelist URIs, cookies, query strings so that they are not cached, we do this in fact for the cart, checkout, cart sessions, etc.

    This is why I was asking if you could provide those details of what to exclude from cache from your plugin, to discard this possibility being the issue.

    supportadtribes

    (@supportadtribes)

    3 years, 10 months ago

    Hi,

    Please whitelist at least these URL’s:
    /wp-admin/admin.php
    /wp-content/plugins/woo-product-feed-pro/*

    And of course the paths where the feeds are being written to:

    /wp-content/uploads/woo-product-feed-pro/xml/
    /wp-content/uploads/woo-product-feed-pro/csv/
    /wp-content/uploads/woo-product-feed-pro/txt/
    /wp-content/uploads/woo-product-feed-pro/tsv/
    /wp-content/uploads/woo-product-feed-pro/logs/

    Now that being said, I am not sure if you are (Redis) object caching too, if so, then unfortunately I am afraid our plugin won’t work.

    Thread Starter magicoders

    (@patopaiar)

    3 years, 10 months ago

    OK, these may be helpful although your questions now make me remember.

    This was working well for a long time, and then a large amount of products were added, and everything went haywire.

    So, given the server should be ok if it was running before, it’s not caching nor the cron…

    What could have broken and be getting broken by importing in bulk a large amount of products.

    As a reminder, the server this is running on is solid. It’s a robust private cloud environment on nginx that runs steadily at ~55% of its RAM/CPU capacity

    supportadtribes

    (@supportadtribes)

    3 years, 10 months ago

    We have no experience whatsoever with bulk uploading data into WooCommerce however in the past we did have some users who experienced issues after doing so, mainly because of wrong bulk imports that mixed up product types (simple and variables) which caused a lot of ghost products sitting around in their database with duplicates values that had to be unique and all that sort of disasters.

    Thread Starter magicoders

    (@patopaiar)

    3 years, 10 months ago

    Ah… this is good information.

    If you have any tips to help us debug the problem, they would be appreciated.

    Logs are giving us nothing so we’re still thinking what to test/where to look next.

    supportadtribes

    (@supportadtribes)

    3 years, 10 months ago

    Another shot: have you tried de-activating and re-activating the plugin? That will reset all cron events needed to update the plugin.

    supportadtribes

    (@supportadtribes)

    3 years, 10 months ago

    Hi,

    Assuming the issue at hand has been resolved or that our support is no longer needed, I am going to close this topic for housekeeping reasons now.

    Please don’t hesitate to reach out to us again whenever you need our help again.

    Thread Starter magicoders

    (@patopaiar)

    3 years, 10 months ago

    That’s OK thank you!

    After lots of trial and error we finally got everything to work.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Stuck feed, WP Cron Confirmed OK’ is closed to new replies.