After upgrading PHP to Version 5.4 or higher, it's not uncommon for some WordPress plugins to produce the “PHP Warning: Illegal string offset" error message. The reason for this is because in Versions 5.4 and above, the default error reporting level has changed.

PHP 5 introduced a new error level: E_STRICT. In PHP versions prior to 5.4.0, you would have to explicitly enable the E_STRICT reporting level, which was disabled by default. With the release of PHP 5.4.0, E_STRICT is included in E_ALL. According to the PHP documentation:

STRICT messages provide suggestions that can help ensure the best interoperability and forward compatibility of your code. These messages may include things such as calling non-static methods statically, defining properties in a compatible class definition while defined in a used trait, and prior to PHP 5.3 some deprecated features would issue E_STRICT errors such as assigning objects by reference upon instantiation.

After I upgraded my WordPress installation to PHP 5.4, my error_log started filling up with the Illegal string offset warning for a couple of lines in the Genesis Simple Sidebars plugin. I am a devout advocate of the Genesis Framework. The plugin is written by Nathan Rice a key contributor to the Genesis framework, so I was a little surprised by the errors.

The code that produces the warning is found in the plugin's source at lines 104 through 109. Specifically, the errors are produced by lines 2 and 4 in the code below.

genesis_register_sidebar( array(
	'name'        => esc_html( $info['name'] ),
	'id'          => $id,
	'description' => esc_html( $info['description'] ),
	'editable'    => 1,
) );

Syntactically, there's absolutely nothing wrong with the code The warning message displays because one of the array values is empty. There are several ways to fix this.

1. You could turn off error messages altogether, but then you wouldn't know if you had a real problem.
2. You could edit the plugin's code to test for empty arrays, but this is not recommended at all. If a plugin update comes through, your changes will be overwritten and you'll be back to square one.
3. You can do as I did and fix the data.

Genesis Simple Sidebars Fix

The following fix applies only to the Genesis Simple Sidebars plugin. For any other plugin, I suggest you look for an empty array value as your code processes the loop.

First, access your database through PHPMyAdmin or MySQLWorkbench. then execute the following SQL statement. (make sure you change "my database" to the name of your database.

SELECT * FROM mydatabase.wp_options where option_name = 'ss-settings';

Next, delete:

i:0;s:20:"__return_empty_array";

from the beginning of serialized string and subtract 1 from the first integer after a:.

In my case the before looked like:

a:7:{i:0;s:20:"__return_empty_array";s:16:"about-me-sidebar";

and the after looks like:

a:6:{s:16:"about-me-sidebar";

This fix works like a charm for Genesis Simple Sidebars. I only hope it helps provide insight into a direction you can pursue to track down your own Illegal string offset warnings.

Formidable Honeypot Fix

Another plugin that exhibits the Illegal string offset warning is Formidable HoneyPot. Formidable HoneyPot is an anti-spam add-on for the popular Formidable Forms plugin. The "honeypot" technique for SPAM protection is invisible to humans and tricks spambots into filling out an invisible form field. When the form is validated, if that invisible field has been populated, the form is not submitted.

As with the Genesis Simple Sidebars plugin, the warning error in Formidable HoneyPot is being produced because the developer is trying to evaluate an empty array. Actually, he's evaluating a non-existent array. Line 86 of the code, which produces the error, evaluates whether or not the form is a multi-page form. The array in question only exists in a multi-page form. So if you only have single page forms, as most people do, the code produces and error.

The developer's original code is:

//don't require if not on the last page
global $frm_next_page, $frm_vars;
if((is_array($frm_vars) and isset($frm_vars['next_page']) and isset($frm_vars['next_page'][$values['form_id']])) or (is_array($frm_next_page) and isset($frm_next_page[$values['form_id']])))
	return $errors;

To fix the error, I simply wrapped the developer's code in a new if statement.

//don't require if not on the last page
global $frm_next_page, $frm_vars;
if(!is_array($frm_vars) or !is_array($frm_next_page)) {
	// do nothing
} else {
	if((is_array($frm_vars) and isset($frm_vars['next_page']) and isset($frm_vars['next_page'][$values['form_id']])) or (is_array($frm_next_page) and isset($frm_next_page[$values['form_id']])))
		return $errors;
}

Just to be clear, this is not the way I like to fix things. I hate changing another developer's source code, especially when the chance is good that it will be overwritten in the future. The only reason I did it this time is because it appears that the developer has been unresponsive to the posts in the plugins forums. One user posted about this error 4 months ago and there has been no response. I guess I'm going to have to write a tutorial on how to add honeypot fields to Formidable Pro without using a plugin.