Planet
Weblog Tools Collection: Tackle Plugin Compatibility Issues While Using Popular Libraries — 16 hours ago
I recently got a email from a plugin developer, with regards to him having compatibility issues with one of the plugins I had developed. It turned out that both our plugins used a popular library called PclZip for adding archiving features. Due to the compatibility issue, accessing his plugin would cause a fatal PHP error saying that the PclZip class cannot be re-declared, when both our plugins were activated.
The compatibility issue arose because of two things;
- A mistake on his part while checking for existence of class objects in the code.
- A mistake on my part of using custom libraries, instead of using those provided by WordPress core.
Here is a code snippet used to check for class existence.
if(! function_exists(’class_name’)) {
require_once(’myclass.php’);
}
$object = new class_name();The above code is wrong, since:
- Class names cannot be accessed as functions.
- The internal methods of a class are not available for checks, unless one decides to instantiate the class and use the method_exists instead.
The correct way to check if a class exists or not can be seen in the following code.
if(! class_exists(’class_name’)) {
require_once(’myclass.php’);
}
$object = new class_name();This change in code actually solved the compatibility issue, but I would like to discuss a bit further on why one should rely on libraries provided by WordPress core instead of using their own custom libraries. The fatal error could have been avoided, if my plugin made use of the the library files from core WordPress, instead of using custom libraries included with my plugin.
If both our plugins had relied on the library files provided by WordPress, the require_once directive would not have re-evaluated the “same file” again, thus avoiding the duplicate class issue. Earlier versions of WordPress did not include many popular libraries, and many plugins include those libraries to provide backward compatibility. If you have to provide backward compatibility for your plugins, be sure to add in a WordPress version check so that you can rely on your own libraries, only when a version of WordPress does not provide it, doing this will certainly do away with having to tackle the compatibility issues caused by plugins using different files for the same libraries.
Update: Including files for backward compatibility can be accomplished by using the following code.
if(!class_exists(’PclZip’)) {
if(file_exists(ABSPATH.’wp-admin/includes/class-pclzip.php’)) {
require_once(ABSPATH.’wp-admin/includes/class-pclzip.php’);
}
else {
require_once(’/path/to/your/lib/class-pclzip.php’);
}
}It is also a good practice to include the classes only when you require them, and later destroy the object by using the unset() method. This is a non-exhaustive resource for tackling compatibility issues between plugins, and I will try and research more on other things that can help avoid these issues and keep informing you about them.
If you have your own advice about avoiding such issues, please do share them with us.
Further reading from PHP documentation:
Donncha: WP Super Cache 0.7 - the dupe content killer — 16 hours ago
WordPress.org user, “definitelynot” discovered a bug in the WordPress plugin, WP Super Cache that could expose blogs to duplicate content penalties. Unfortunately this affects every blog that uses the plugin in “ON” or full “Super Cache” mode, and has URLs that end with the “/” (forward slash) character. If the plugin is on “half on” mode, you’ll be fine.The problem is that an anonymous user might visit a legitimate URL, ending with a slash, the plugin then creates a static file out of that page, which is then used when people visit the same URL. Unfortunately if someone links to that URL without the ending slash, a visiting browser or search engine bot won’t be redirected to the proper URL, they’ll be served the static html file.
For example:
- John visits the URL /2007/05/23/why-the-nurses-cant-go-on-strike/ on my site. WP Super Cache creates a html file of that page.
- In his enthusiasm for that post, John publishes a post about those zany doctors, but he forgets the ending “/”.
- Googlebot, seeing fresh content on John’s site, crawls it and sees the link, visits my site eventually and wonders why it’s seeing the exact same page at two different URLs.
To be fair, Google is pretty good at figuring out where duplicate content is supposed to go but it’s better to avoid the issue completely. It also only matters if there are links to your site without the ending slash. The most common will probably be to your homepage as it’s likely internal URLs will be copy/pasted.
How to Fix
You should update to version 0.7 of the plugin which checks if your blog is affected by this problem. It also has instructions for updating the mod_rewrite rules in your .htaccess. It’s fairly easy to fix. Thank you “andylav” for the mod rewrite magic!- Edit the .htaccess in the root of your WordPress install.
- You’ll see two groups of rules that look like this:
RewriteCond %{REQUEST_METHOD} !=POST RewriteCond %{QUERY_STRING} !.*s=.* RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.* RewriteCond %{QUERY_STRING} !.*attachment_id=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$ RewriteCond %{HTTP:Accept-Encoding} .*gzip.* RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L] RewriteCond %{REQUEST_METHOD} !=POST RewriteCond %{QUERY_STRING} !.*s=.* RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.* RewriteCond %{QUERY_STRING} !.*attachment_id=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$ RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L] - You need to add the following 2 rules above each block of “RewriteCond” lines:
RewriteCond %{REQUEST_URI} !^.*[^/]$ RewriteCond %{REQUEST_URI} !^.*//.*$ - The rules should eventually look like this:
RewriteCond %{REQUEST_URI} !^.*[^/]$ RewriteCond %{REQUEST_URI} !^.*//.*$ RewriteCond %{REQUEST_METHOD} !=POST RewriteCond %{QUERY_STRING} !.*s=.* RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.* RewriteCond %{QUERY_STRING} !.*attachment_id=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$ RewriteCond %{HTTP:Accept-Encoding} .*gzip.* RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L] RewriteCond %{REQUEST_URI} !^.*[^/]$ RewriteCond %{REQUEST_URI} !^.*//.*$ RewriteCond %{REQUEST_METHOD} !=POST RewriteCond %{QUERY_STRING} !.*s=.* RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.* RewriteCond %{QUERY_STRING} !.*attachment_id=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$ RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L] - Or you could just delete those rules and let the plugin regenerate them for you again.
PS. Thanks also to Lloyd for noticing the “enable the plugin” link was pointing at the wrong URL, and to Ryan who spotted a minor problem with the admin page and was kind enough to send me a Tweet about it.
PPS. I’ve just tagged 0.7.1 to fix some problems with the updating of the .htaccess, mainly for new users. If 0.7 of the plugin works for you, there’s no need to upgrade!Related Posts
Alex King: Twitter Tools 1.5b2 — 17 hours ago
I’ve got a new beta version of Twitter Tools ready for testing. Twitter Tools is a WordPress plugin that creates an integration between your blog and your Twitter account.
This release has a couple of bug fixes (from version 1.5b1) and a couple of new features:
- fixed a logical bug that made the “exclude replies” option work backwards (oops!)
- removed a try/catch for PHP 4 compatibility (oops!)
- added support for hashtags (linked to search.twitter.com)
- abstracted all API endpoints and URLs so that it can theoretically support any service that implements the Twitter API
Hopefully this will be ready for a full release shortly, with only minor changes (if any). I guess we’ll find out soon.
The download and more information are available on my WordPress Plugins page.
If you have any trouble with this, please open a thread in the WP Support Forums and send me the link.
