Confession of the problem in 2.2.4

I must make a confession that the release 2.2.4 caused a big problem which stopped the sites of my plugin’s users. In this article, I will report why this problem was caused and also how I should improve my developing process in order to prevent this kind of undesired accident again.

The problem

When you installed (or upgraded) 2.2.4 of IP Geo Block, you encountered the following error:

Warning: strpos(): Empty needle in /public_html/wp-content/plugins/ip-geo-block/classes/class-ip-geo-block.php on line 71.

The message said just “Warning” but actually this was “Fatal Error” which broke the site. And to recover the site, users should delete IGB manually through the FTP or cPanel file manager.

The how

The code in problem was as follows:

// normalize requested uri (RFC 2616 has been obsoleted by RFC 7230-7237)
// `parse_url()` is not suitable becase of
// REQUEST_URI starts with path or scheme (
$uri = preg_replace( '!(?://+|/\.+/)!', '/', $_SERVER['REQUEST_URI'] );
$uri = $this->request_uri = substr( $uri, strpos( $uri, self::$wp_dirs['home'] ) + strlen( self::$wp_dirs['home'] ) );

When the second argument self::$wp_dirs['home'] passed to strpos() was an empty string, serious error occured and stopped showing the contents. This always happened if the WordPress is installed into the document root. I could not predict this error because there’s no mention in the PHP manual which just says:

mixed strpos ( string $haystack , mixed $needle [, int $offset = 0 ] )

If needle is not a string, it is converted to an integer and applied as the ordinal value of a character.

The why

Whenever I release a new version, I follow the procedure as listed below:

  1. Check all the functionality on my local environment by a handmade tool (for blocking functionality) and manual procedure (for “Activate”, “Deactive”, “Delete”, “Download now”, “Clear now”, clean uninstall, emergency recovery and so on).

  2. Check compatibilities with other plugins and themes which had some issues in the past depending on the changing points.

  3. Run continuously at least for 1 week or more on my real site and check if no error happens.

You can easily point out that those are not enough. One thing is that a variety of servers will never be tested. For example, the type of HTTP server (apache and nginx are not enough?), the type of multisite (sub-domains/sub-directories), verious versions of PHP and the libraries, adopting SSL certificate, etc…

And to make matters worse, both my local and real site are “sub-directories” type of WordPress. So as for the problem in 2.2.4, I had never tested “top-directory” type that caused this trouble.

What should I do?

In order to see that it never happens again, I’ve built up the application development environment on my local PC as follows:

In order to make those setup easy, I purchased MAMP Pro license.

Different type of multisite

And my future plans are:

In order to announce “call for testing”, I will equip an widget on the admin dashboard to distribute it. It might be provided with some useful information for users such as a summary of statistics and etc.


@jckuffner posted at the forum that:

Perhaps WP needs higher standards and more stringent procedures for plugin updates to keep this from happening.

I completely agree with him. Unit tests is necessary but not enough for testing a various type of servers. I think we definitely need something like WordPress Beta Tester that can test developing version online and easy to return to the stable version if something happens emoji .