Fatal error: Uncaught Error: Cannot unset string offsets

It seems to be a bug in the uninstall() method in the better-wp-security/core/lib/class-itsec-scheduler-cron.php file at #466 …

To prevent any confusion, I’m not iThemes.

Hi,

Further investigation has revealed that the issue is not strictly due to the iTSec Plugin bug. It seems there is probably also some unexpected data in the WP Cron option. The WP Cron option stores all scheduled events in the database.

The iTSec plugin code is not robust enough to deal with that (unexpected) data.

This means the issue can be resolved from 2 sides:

1. The iTSec plugin code should be fixed for added robustness.
2. Or any invalid (ghost) entries in the WP Cron option are deleted.

Additionally there is a chance that the WP Cron API will clear the invalid entries once they are executed. I’m trying to get this verified. If true the issue might automatically get resolved over time…

I’ve opened a new topic for this here.

Based on the info gathered so far I think the best way to proceed is to figure out a (simple) way to get rid of the ghost entries in the WP Cron option as currently saved in the database. The WP Crontrol plugin may assist us in doing so.
Let’s keep an eye on the topic I opened in the WP Crontrol support forum 😉

Never mind. Testing showed me the WP Crontrol plugin won’t list any invalid scheduled event entries from the WP Cron option (array).
So WP Crontrol plugin turns out to be useless for our purpose.

We could have a look at the exact content of the WP Cron option as saved in the database. But this will require some skills with the phpMyAdmin tool (or anything similar) and MySQL.
We would also need to manually remove any invalid entries in json encoded data which is pretty risky. Certainly when you haven’t done this before.

Alternatively we can simply fix the bug by improving the robustness of the uninstall code in the iTSec plugin. It will allow the (plugin) activation code to complete. The part where it fails is part of an upgrade routine which only needs to run once. So it looks like you are activating a newly installed version of the plugin but at activation it automatically notices that the plugin buildnr (as stored in the database) is older. Hence it starts upgrading.
Once that upgrade is able to complete the buildnr in the database will be updated to the latest release. Next time you deactivate/activate the plugin the buildnr is the same and no upgrade routines are triggered.
I’m pretty confident this will work and move this forward relatively easy (certainly compared to option 1). All we need to do is add 3 new lines of code to the uninstall() method in the better-wp-security/core/lib/class-itsec-scheduler-cron.php file like this:

public function uninstall() {
	remove_action( self::HOOK, array( $this, 'process' ) );
	remove_filter( 'cron_schedules', array( $this, 'register_cron_schedules' ) );
	
	$crons = _get_cron_array();
	
	foreach ( $crons as $timestamp => $args ) {
		if ( ! is_array( $args ) ) { // New line 1
			continue;            // New line 2
		}                            // New line 3

		unset( $crons[ $timestamp ][ self::HOOK ] );
	
		if ( empty( $crons[ $timestamp ] ) ) {
		 	unset( $crons[ $timestamp ] );
		}
	}
	
	_set_cron_array( $crons );
	
        delete_site_option( self::OPTION );
}

Do make sure to make a copy of the better-wp-security/core/lib/class-itsec-scheduler-cron.php file before editing.

@timothyblynjacobs
FYI

@katluk20
FYI Fixed in the iTSec 7.9.0 release. According to the changelog:

Bug Fix: PHP warnings when invalid entries are stored in the WordPress Cron storage.

@timothyblynjacobs
This week I ran into an identical issue when attempting to activate the iTSec (7.9.0) plugin (after deactivating it while ITSEC_DEVELOPMENT was set to true). However it seems to be happening in a different part of the code. Full stack trace below:

Fatal error: Uncaught Error: Cannot unset string offsets in /var/www/vhosts/example.com/subdomains.com/isfree/wp-content/plugins/better-wp-security/core/setup.php:195
Stack trace:
#0 /var/www/vhosts/example.com/subdomains.com/isfree/wp-content/plugins/better-wp-security/core/setup.php(21): ITSEC_Setup::setup_plugin_data()
#1 /var/www/vhosts/example.com/subdomains.com/isfree/wp-content/plugins/better-wp-security/core/core.php(594): ITSEC_Setup::handle_activation()
#2 /var/www/vhosts/example.com/subdomains.com/isfree/wp-includes/class-wp-hook.php(287): ITSEC_Core::handle_activation()
#3 /var/www/vhosts/example.com/subdomains.com/isfree/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters()
#4 /var/www/vhosts/example.com/subdomains.com/isfree/wp-includes/plugin.php(478): WP_Hook->do_action()
#5 /var/www/vhosts/example.com/subdomains.com/isfree/wp-admin/plugins.php(193): do_action()
#6 {main} thrown in /var/www/vhosts/example.com/subdomains.com/isfree/wp-content/plugins/better-wp-security/core/setup.php on line 195

For now I resolved the issue by cleaning up the cron option (I probably added the bogus cron entry myself to debug the initial problem in this topic. Looks like I forgot all about it… Let’s just say I was ahead of myself. Honestly, I remember doing a global search through the code and thinking to myself … hmmm that’s another potential point of failure. And just a couple of months later, bingo. ;-)).