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.
When you installed (or upgraded) 2.2.4 of IP Geo Block, you encountered the following error:
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 code in problem was as follows:
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.
Whenever I release a new version, I follow the procedure as listed below:
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).
Check compatibilities with other plugins and themes which had some issues in the past depending on the changing points.
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.
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.
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 .