Austin Ginder

It’s not a separate issue. I have the same PHP fatal in my error logs and we’re using the same web host, Kinsta.

I had the same issue for one of my customer websites. This is both a bug with WooCommerce Square and also requires a configuration change to PHP in order to resolve. In regards to the plugin bug, WooCommerce Square is not properly detecting PHP’s opcache.save_comments configuration which is required by the plugin: https://woocommerce.com/document/woocommerce-square/setup-and-configuration-of-the-woocommerce-square/. With Kinsta, simply reach out to their live chat support and request that they enable it per each site you plan to use WooCommerce Square. By default Kinsta doesn’t have PHP’s opcache.save_comments enabled. Once that’s been addressed, you should be safe to activate WooCommerce Square.

WooCommerce Square Support, can you fix this bug? You should be able to reproduce the PHP fatal by turning off PHP’s opcache.save_comments and then try activating WooCommerce Square.

If you have SSH, here is a handy bash script to rollback.

version=$(wp plugin get woocommerce-services --field=version --skip-themes --skip-plugins)
if [[ "$version" == "3.0.6" ]]; then
    wp plugin install woocommerce-services --version=3.0.5 --force --skip-themes --skip-plugins
fi

The problem is that lc_twicedaily_refresh_req was repeatably added to WordPress cron. On one of my customer websites, the database row for cron in the options table was over 20MBs large. Even with SSH and WP-CLI, removing all cron events lc_twicedaily_refresh_req would take all day to purge. Cleaning up these types of issues are messy, especially when WordPress is overloaded. Here is how I restored a few of my customer websites with Kinsta over SSH.

Enable maintenance mode manually

cd ~/public
echo '<?php $upgrading = time(); ?>' > .maintenance

Restart Kinsta PHP workers then export current cron events to JSON file.

wp option get cron --format=json --skip-themes --skip-plugins > cron.json

Create the following cron-purge.php

<?php
/**
 * This script cleans the 'cron' option in the WordPress database by removing
 * events related to 'lc_twicedaily_refresh_req'.
 *
 * Usage: wp eval-file cron-purge.php
 */

// Path to the cron.json file.  Make sure this is correct!
$cron_file = 'cron.json';

if ( ! file_exists( $cron_file ) ) {
	WP_CLI::error( "Cron file not found: $cron_file" );
	return;
}

$cron_data_json = file_get_contents( $cron_file );

if ( false === $cron_data_json ) {
	WP_CLI::error( 'Failed to read cron data from file.' );
	return;
}

$cron_data = json_decode( $cron_data_json, true );

if ( null === $cron_data && json_last_error() !== JSON_ERROR_NONE ) {
	WP_CLI::error( 'Failed to decode cron data: ' . json_last_error_msg() );
	return;
}

if ( ! is_array( $cron_data ) ) {
	WP_CLI::error( 'Cron data is not an array.' );
	return;
}

$removed_count = 0;

foreach ( $cron_data as $timestamp => $events ) {
	if ( is_array( $events ) ) {
		foreach ( $events as $hook => $details ) {
			if ( strpos( $hook, 'lc_twicedaily_refresh_req' ) !== false ) {
				unset( $cron_data[ $timestamp ][ $hook ] );
				$removed_count++;
			}
		}
		// Clean up empty timestamp entries
		if ( empty( $cron_data[ $timestamp ] ) ) {
			unset( $cron_data[ $timestamp ] );
		}
	}
}

// Update the option in the database.
$result = update_option( 'cron', $cron_data, false );

if ( $result ) {
	WP_CLI::success(
		sprintf(
			'Successfully cleaned cron data. Removed %d events. Option updated.',
			$removed_count
		)
	);
} else {
	WP_CLI::error( 'Failed to update the cron option.' );
}

Run wp eval-file cron-purge.php --skip-themes --skip-plugins. One my site the response looked like this:

Success: Successfully cleaned cron data. Removed 130982 events. Option updated.

Lastly remove the maintenance file to restore the website.

rm .maintenance

Since the WordPress cron might not have been running properly for the last few days, I recommend running all outstanding items.

wp cron event run --due-now

Same. After updating to v1.1.5 I’ve been seeing the following PHP fatals in my error log. It may just be background errors. I’m not sure as my host provider emails recurring PHP fatals no matter how they are triggered. I’m on PHP 8.0.

2024/03/21 13:01:14 [error] 61371#61371: *566487 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught TypeError: array_key_exists(): Argument #2 ($array) must be of type array, bool given in /www/public/wp-content/plugins/smart-app-banner/wsl-smart-app-banner.php:49