August 27th, 2008

Hello there! If you are new here, you might want to subscribe to the RSS feed for updates on this topic.

Responses

Comments

James Dimick (23 comments.) says:

8/27/2008 at 5:06 pm

Great article!

You actually hit on a great point with using unset to destroy it when you’re finished with it. I actually don’t do that in my plugin, but I should. I’m going to add that for the next release I think.

I think it’s important that all plugin developers code their plugins in such a way that they will not clash with each other. Otherwise you end up with a big mess. My plugin could probably do more to help prevent clashing. I just need to learn more. It is my first plugin so I’m still learning as I go.

Anyway, great article!
Aaron (3 comments.) says:

8/27/2008 at 7:53 pm

Good post. I’ve run into many issues with my plugin and Wordbook conflicting. I’ve made sure that Fotobook only includes the Facebook API library whenever it uses it. However, Wordbook makes use of the same library more frequently and often tries to redeclare the Facebook API classes. You mention unsetting the object, but in my case the problem is that both plugins are declaring the same class. So undeclaring the class would be more appropriate. But to my knowledge that isn’t possible.
ovidiu says:

8/28/2008 at 7:47 am

great article, although I am not a programmer by any means, I udnerstand what you are talking about and have personally had issues with different plugins, which were loading the same libraries, causing conflicts, which is pretty hard to solve for a user, you need to get in touch with both plugin developers and hope they can help.

Hopefully more plugin developers will read this article
Rajesh (35 comments.) says:

8/28/2008 at 9:27 am

Keith, I have not seen the code in the custom library but I think there is more confusion here than you had discussed here.

In object oriented programming, every class will normally have a constructor and the constructor will have the same name as the class. That was the case until php 5.0 introduced __construct() as the constructor name.

That might have been the reason.Has the author of the custom library not updated it for PHP 5.0? I am guessing that the plugin author, who contacted you, must have got this error on php 5.0.

But this is a problem with php as a language.They seem to be making such drastic changes in the language, putting the developers to hardships We do not see these in other real object oriented programming languages like Java…PHP has a long way to go…
- Rajesh (35 comments.) says:
  
  8/28/2008 at 9:43 am
  
  But the custom library author would have done well to check it as a class rather than as a function…But when he developed it for a versions earlier to php 5.0, he would not have anticipated such a drastic change in version 5.0…if the original author is no longer supporting it then it is no fault of his.I will blame it on PHP.
  
  I would also like to add that this is sometimes the case even with wordpress..it is more important to advertize the deprecated functions and the replaced functions, whenever a new wordpress version is released.This will help the plugin authors to update their plugins easily.
Rajesh (35 comments.) says:

8/28/2008 at 10:18 am

Ok…

if he had instatiated the class and checked the function inside the class with a methos-exists() call, I guess he would still have been safe…

Keith, it would be nice if you could mention the function name and the line of code in the library that caused this error? Is it a function inside a class?

This is more interesting really…i don’t think it is the if loop that is causing the issue.Wouldn’t require_once() ensure that the code from the file is included only once.

I am guessing that it is the object creation line(done twice) that is causing the incompatibility issue…
- Keith Dsouza (82 comments.) says:
  
  8/28/2008 at 12:18 pm
  
  Like I described require_once will evaluate different files and not re-evaluate the same files. So if two plugins are using their own libraries require_once will throw a fatal error. This issue can be tackled by using the if condition.
  
  On the other hand multiple Object creation will never give you a error, they are unique of each other.
  - Rajesh (35 comments.) says:
    
    8/28/2008 at 1:02 pm
    
    Oh yes, i somehow missed the note on plugins using their own libraries in this case..you are right…
Keith Dsouza (82 comments.) says:

8/28/2008 at 12:23 pm

Just to add that creating a new using the new keyword would throw an error if the class is not found, so it becomes essential to use the if condition, to safely check if no other plugins have already used the library. Method exists can be used when you are trying to check for functions that were deprecated or when you are trying to check for backward compatibility of a library.
- Rajesh (35 comments.) says:
  
  8/28/2008 at 1:13 pm
  
  Just to add that creating a new using the new keyword would throw an error if the class is not found, so it becomes essential to use the if condition, to safely check if no other plugins have already used the library.
  
  If both the plugins are using the same library, why should it be ensured that no other plugins have already used the library? What is wrong if they use it, as they are anyway using require_once()….
Steve (3 comments.) says:

8/28/2008 at 2:07 pm

There is a genuine need for a tutorial (or whatever) going into painful details about plugin interactivity and compatability, to include the use of common libraries (like jQuery) across plugins and the user’s own homebrew coding (adding actions into wp_header).
Aaron (3 comments.) says:

8/28/2008 at 4:13 pm

Steve,
Very true. That would be very helpful and eliminate a lot of messy code. I think most plugin coders just start off doing whatever they can to make it work without realizing some of the systems that are in place to streamline things and avoid some of these conflicts.
- James Dimick (23 comments.) says:
  
  8/28/2008 at 5:08 pm
  
  I know that’s true for me. When I started on my plugin I was just out to make it work. Then I discovered that there was much more I had to do to make it play nicely.
  
  By the by, I’m the person who E-mailed Keith. It was about my plugin Easy Admin Color Schemes which also uses the PclZip function a little bit. Just thought I’d name the anonymous “plugin developer”. So, any of you who are interested in looking deeper can have a look at my code. A warning though: It may not be pretty. It’s my first plugin.
- Steve (3 comments.) says:
  
  8/29/2008 at 4:05 pm
  
  I don’t really blame plugin developers, though… because most plugins start out as an individual site-owner’s need to “do something” that he or she can’t find an existing plugin for. So initially you go off and “just make it work”. Later on you may offer your plugin up for the masses… who then manage to find 100 ways to break it!
  
  I know for myself that I’ve been calling the jQuery code from Google code… and then running it in my wp_footer() for whatever I use it for (sIFR, etc.). I know that some people, instead, load jQuery through wp_enqueue_script — but I know little to nothing about this, other than it’s probably a more correct method. I DO know that another method is to load jQuery DIRECTLY from the WordPress core (which even allows for a query value specifying which version of jQuery).
  
  All I know is, that my own code fights with plugins just as well as the plugins fight each other. Recently Lightbox2 (a tremendous idea) blew away my homebrew jQuery code. The Google code hosted IE-7.js (which fixes IE6 neatly and cleanly) blew away my Kimili Flash Embed plugin. It’s like I can’t win.
  
  There’s got to be a better way of exposing core code and common libraries… and viewing plugin dependencies. Should this maybe be part of the WordPress admin plugin page? Like a prereq/library field or something?