6768 pointsCommunity rank #8Supreme DeityWPMU DEV StaffLifetime member
Developer
(joined June 2008)
Likes (0)
I haven't seen one, but it all depends on the plugin in question (is it your own or are you trying to fix one).
Some plugins have easy fixes, but a few (mentioning no names) are a nightmare and just need to be scrapped and re-written, or aren't worth the bother.
A few things to look out for:
Hardcoding database prefix
Creating tables (and forms based on them) but not passing or storing the blog_id / user_id for filtering
Hardcoding locations.
Relying of activation hooks to set up tables (mu-plugins don't fire this).
6593 pointsCommunity rank #9Supreme DeityMember of the MonthLifetime member
Keeper of the Dark Chocolate
(joined July 2007)
Likes (0)
Hardcoding locations.
Hardcoding the wrong locations....
Our method of testing is to install it on a testbed, give it a shot and see what happens and what errors are produced. You have to remember that even though that there are guides on how to build a plugin, even a general one, few developers follow it word for word. And then you have all the name changes of the functions over the versions, different functions that do the same thing, etc. It really is a mess although to be honest, most open source platforms are.
A lot of the plugins have been discussed previously either here or on the regular mu forums. If you;re having a specific problem with a specific plugin, may want to check to see if it;s been discussed previously.
8460 pointsCommunity rank #4Supreme DeityWPMU DEV StaffLifetime member
Lead Developer
(joined May 2009)
Likes (0)
Also you need to be VERY aware about the security holes many normal WP plugins will open in your site. Almost none of them verify/filter user input. They can open your entire site to XSS and SQL injection vulnerabilities.
225 pointsCommunity rank #221ExpertJust Getting Started
Member
(joined February 2009)
Likes (0)
@Barry, Thanks! There are quite a few plugins that we tried...some were successful, other were NOT and still not. :) What you have mentioned are indeed 100% right.
@drmike, Thanks! Thought if there is some general check points, specific functions that we need to handle so on...I thought it would help all if we put them together here.
@Aaron, Thanks too. Thats a real point we should be aware of....some paid versions of plugins come encrypted too...cant even check if it does have any such security hole.
Yes, if more 'n more people put their thoughts here...we are likely to get more exposed to what all need to at-least kept in mind in such situations.
225 pointsCommunity rank #221ExpertJust Getting Started
Member
(joined February 2009)
Likes (0)
One more thought that just stuck....we must also need to consider multi-db functionalities(when its a db dependent one) when a plugin is made/modified or does the wp normal stuff handles it?
225 pointsCommunity rank #221ExpertJust Getting Started
Member
(joined February 2009)
Likes (0)
As Aaron said: "SQL should also not hardcode the wp_ prefix on table names."
I would like to add: Apart from using wp_prefix($wpdb->prefix), do NOT use wp_ in-between the tablename, eg: use $table_name = $wpdb->prefix . "eCart_tbl"; and NOT $table_name = $wpdb->prefix . "wp_eCart_tbl";
7430 pointsCommunity rank #7Supreme DeityMember of the MonthLifetime member
Erstwhile founder
(joined May 2007)
Likes (0)
I think what they did in that case was by accident. It looked like they had thr prefix hardcoded at one point and then decided to add the prefix variable. The problem is that they forgot to remove the hardcoded prefix.
Responses (9)
Developer (joined June 2008) Likes (0)
I haven't seen one, but it all depends on the plugin in question (is it your own or are you trying to fix one).
Some plugins have easy fixes, but a few (mentioning no names) are a nightmare and just need to be scrapped and re-written, or aren't worth the bother.
A few things to look out for:
Hardcoding database prefix
Creating tables (and forms based on them) but not passing or storing the blog_id / user_id for filtering
Hardcoding locations.
Relying of activation hooks to set up tables (mu-plugins don't fire this).
Keeper of the Dark Chocolate (joined July 2007) Likes (0)
Hardcoding the wrong locations....
Our method of testing is to install it on a testbed, give it a shot and see what happens and what errors are produced. You have to remember that even though that there are guides on how to build a plugin, even a general one, few developers follow it word for word. And then you have all the name changes of the functions over the versions, different functions that do the same thing, etc. It really is a mess although to be honest, most open source platforms are.
A lot of the plugins have been discussed previously either here or on the regular mu forums. If you;re having a specific problem with a specific plugin, may want to check to see if it;s been discussed previously.
Lead Developer (joined May 2009) Likes (0)
Also you need to be VERY aware about the security holes many normal WP plugins will open in your site. Almost none of them verify/filter user input. They can open your entire site to XSS and SQL injection vulnerabilities.
Filter input/filter output.
Member (joined February 2009) Likes (0)
@Barry, Thanks! There are quite a few plugins that we tried...some were successful, other were NOT and still not. :) What you have mentioned are indeed 100% right.
@drmike, Thanks! Thought if there is some general check points, specific functions that we need to handle so on...I thought it would help all if we put them together here.
@Aaron, Thanks too. Thats a real point we should be aware of....some paid versions of plugins come encrypted too...cant even check if it does have any such security hole.
Yes, if more 'n more people put their thoughts here...we are likely to get more exposed to what all need to at-least kept in mind in such situations.
Thanks & Regards
Member (joined February 2009) Likes (0)
One more thought that just stuck....we must also need to consider multi-db functionalities(when its a db dependent one) when a plugin is made/modified or does the wp normal stuff handles it?
Thanks & Regards
Lead Developer (joined May 2009) Likes (0)
Occasionally a plugin doesn't use the Wordpress $wpdb class for database actions. That's a no no and will break in Multidb and usually MU too.
SQL should also not hardcode the wp_ prefix on table names.
Member (joined February 2009) Likes (0)
As Aaron said: "SQL should also not hardcode the wp_ prefix on table names."
I would like to add: Apart from using wp_prefix($wpdb->prefix), do NOT use wp_ in-between the tablename, eg: use $table_name = $wpdb->prefix . "eCart_tbl"; and NOT $table_name = $wpdb->prefix . "wp_eCart_tbl";
Thanks & Regards
Erstwhile founder (joined May 2007) Likes (0)
I think what they did in that case was by accident. It looked like they had thr prefix hardcoded at one point and then decided to add the prefix variable. The problem is that they forgot to remove the hardcoded prefix.
Thanks,
Andrew
Keeper of the Dark Chocolate (joined July 2007) Likes (0)
Heck, I hardcode the prefix. I'm lazy. :)
Plus it's one less function call. And I know all of my installs use the prefix. (Except for one and they use wpmu_)
Become a member