Forum Replies Created

Viewing 11 replies - 1 through 11 (of 11 total)
  • Thread Starter cwthorpe

    (@cwthorpe)

    Hi @frankremmy,

    The issue is present in a bare storefront+woocommerce only environment. I added debugging in the loop within Storefront_WooCommerce_Adjacent_Products and it is clear that the while ( $adjacent = $this->get_adjacent() ) { ... } loop never exits.

    cwthorpe

    (@cwthorpe)

    To clarify, the problem seems to be that the WP function get_adjacent_post changed how it returns data, specifically, it previously returned a false value if no adjacent post found. Storefront and other themes apparently assumed that a simple boolean test would work to exit their loop to find adjacent products.

    while ( $adjacent = $this->get_adjacent_post() ) { ... }

    However, in WP 6.9, the get_adjacent_post function does not return false and so the loop becomes infinite and the page times out – with increasingly high CPU loads as unfulfilled page accesses gradually accumulate

    • This reply was modified 4 months ago by cwthorpe.
    Thread Starter cwthorpe

    (@cwthorpe)

    The issue is that after upgrading to WordPress 6.9, the site begins to run extremely slow. After restarting the server, the site runs normally for a while, then gradually gets slower and slower as the CPU load on the server increases.

    On investigation, it turns out that loading a woocommerce product page fails with a 504 or other timeout status. Other pages on the site load alright, but because each attempted access of a product page causes an increased CPU load until it times out, then gradually the server becomes more sluggish as the number of pending page loads on the product pages gradually rises. Eventually the server becomes overloaded and unresponsive.

    I isolated the issue to the product pagination function of the storefront theme. This function contains a loop that calls the wordpress get_adjacent_post function. However, due to changes in how the function return data, the status is not correctly interpreted by the storefront code, and the loop can become infinite. Hence, if the product pagination is enabled in storefront, accessing a product page will cause the server to enter an infinite loop with high CPU usage until timeout.

    Even worse, there is a file access within the get_adjacent_post function (due to time zone lookup) that is inside this infinite loop.

    I recommend disabling storefront pagination until this is fixed.

    Other themes and plugins may be impacted if they rely on get_adjacent_post returning a value of false for loop exit.

    • This reply was modified 4 months ago by cwthorpe.
    cwthorpe

    (@cwthorpe)

    There is an issue in Storefront with an infinite loop in the get_adjacent product function.

    You need to disable product pagination.

    This is also happening for my site. It began happening when I changed to the WC block checkout page.

    It appears that during checkout, the wallet balance is subtracted from the order, but then when the checkout is finalised, tax is added to this wallet transaction, which makes it become greater than the wallet balance, so evidently updating the wallet balance fails. However it stays on the order.

    With the old shortcake based checkout, there is no tax added to the wallet transaction “fee”.

    Hope you can fix this!

    Thanks

    For anyone else who has this problem:

    I installed WP-Crontrol and within that plugin Cron Events, you can create URL events that call an arbitrary URL.

    So instead of scheduling the BackWPup job directly, change the schedule to start with a link, then copy that link from BackWPup and use it within WP-Crontrol in a URL event at the desired times and intervals.

    It works fine.

    I have been getting this same issue for past 2 weeks also.

    Job runs when triggered manually. wp-cron event is scheduled and triggered on schedule, but it doesn’t actually start the job.

    I am having the same issue. The problem appears to only be on the admin dashboard – cannot access that, get a timeout in the TimeInterval.php file (not always line 321). If I navigate directly to any of the individual admin pages it loads fine.

    Can even load the analytics page itself, although the performance icons don’t display (Grey boxes only).

    As others have noted, get the same behaviour in recovery mode with default theme and no other plugins.

    @sacredpath – yes, I am trying out antispam Bee… Defensio seemed like a good idea but it’s obviously not a priority for the company anymore.

    Yeah, mine started working again too…

    There’s another forum post on this here so obviously has been happening on and off for a while. Looks like Defensio may be no longer actively supported (it doesn’t appear at all on the website of its parent WebSense Inc).

    I’m getting the same error – “Could not validate your API key.” – and yet when I go to my account page on Defensio.com everything seems to be fine, the API key matches, and there is no indication that the account is not working.

    Are these guys still active? Defensio? Websense Inc?

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