Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • We had this same issue on a client’s site where the number of products would drop dramatically when the daily feed refresh was run.

    If the update was run manually all products would be restored!?

    The problem was traced to a duplicate job in the WordPress Action Scheduler. The second, duplicate job was running shortly after the first. The first would complete, move the _tmp file to be the real file, the second would write out the last batch to the now empty _tmp file and then move the much smaller file to become the feed file – hence the drop.

    If you have this situation where a manual refresh results in the correct number of products, but a daily refresh does not, check the Action Scheduler!

    Thread Starter Not Just Code

    (@notjustcode)

    We absolutely do want to use the Action Scheduler for feed generation – our apologies, the original bug report contained an error. This:

    Please consider adding a setting which provides us with the facility to switch off processing of the Action Schedule within the webserver.

    Should have asked:

    Please consider adding a setting which provides us with a facility to prevent includes/Classes/Heartbeat.php from running the maybe_run_feed_batch_action_schedules() function which is running the action scheduler as part of serving an HTTP request. 

    In other words, please add an extra check box to the settings page with the option Disable HTTP feed generation requests which would implement our work around above.

    Setting the Refresh option to “no refresh” makes no difference here, as the bug is caused by Hearbeat.php repeatedly calling the maybe_run_feed_batch_action_schedules() function which is overloading the server – this is why so many people are reporting the strange behaviour of: stay on the page and feed generation gets stuck, move away from the page and feed generation completes.

    The bug here is repeatedly calling maybe_run_feed_batch_action_schedules() function in includes/Classes/Heartbeat.php.

    • This reply was modified 6 months, 3 weeks ago by Not Just Code. Reason: Formatted the bug report change with italics for clarity and fixed a typo in file path in last sentence

    When upgrading to php7.4 on WordPress 6.1.1 we had the same error message:

    Uncaught Error: Call to undefined function trailingslashit()

    Rolling back to a previous version of WordPress and leaving PHP 7.4 in place revealed this error message:

    Your PHP installation appears to be missing the MySQL extension which is required by WordPress

    We fixed this by installing the MySQL extension for PHP 7.4.

    On Debian-based systems, you can do this by running:

    sudo apt install php7.4-mysql

    at the command line.

    We restarted php7.4-fpm and the site now runs again on WordPress 6.1.1 and PHP 7.4.

    Thread Starter Not Just Code

    (@notjustcode)

    Clean install of WP5.5.3 and branch release from the link above resulted in a clean install and activation.

    Issue fixed.

    Thanks!

    Thread Starter Not Just Code

    (@notjustcode)

    No problem – I thought it would be a regression as previously the plugin has notified us about directories it needed access to.

    We run our WP installs on tightly locked down nginx setups, so appreciate it when plugins a) acknowledge that nginx exists and b) lets us know what directories to make accessible.

    In answer to your question: clean, new install of the plugin.

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