Tackle Plugin Compatibility Issues While Using Popular Libraries 14comments
If you like this post, please subscribe to our RSS feed to read our new posts every day.
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:
Obviously Powered by 
