[wp-hackers] support for custoim post types + custom feilds

Curtis McHale curtis at curtismchale.ca
Mon Jun 21 16:29:08 UTC 2010

My biggest concerns about using plugins are:

1. Not cleaning out the DB if they're uninstalled. Most plugins don't do 
this in my experience. The should be some sort of API call to allow the 
user to download a .zip of the data then clean out the DB of the dead 

2. Doing way more than I need. Many plugins try to catch all of the edge 
cases so introduce way more functionality than I need.

3. Future support. If we look at the last WP upgrade to 3 last week the 
Podcast TSG plugin broke a number of sites (including mine). WordPress 
3.0 was out to test for quite a while yet the plugin didn't get updated 
in time for the launch. Yes it was quickly fixed, and yes I should have 
tested it first before upgrading, but I'd rather have WP at the newest 
and find a new solution for podcasting.

4. Many things/features are easy to add as a theme option so don't 
require a plugin. Take switching out a Feedburner RSS feed for the 
normal RSS feed. It's trivial to add a text box as a theme option and 
have it overwrite the normal WP RSS feed.

For the company I used to work for the biggest issue was #3. If it's 
code written in house then in theory we can fix/test it easily if there 
is an issue instead of being reliant on a 3rd party to fix the issue. 
Yeah I can dig into the plugin and see about fixing it myself but it's 
not my code so it will take me longer to do it. There also is really not 
a good way for users to submit patches to plugins. I have contributed to 
a few Open Source projects through Github which has a pretty slick/easy 
model for forking and offering patches.

Akismet is a fine plugin to use because it comes bundled with the 
software. This puts it at a different level than other plugins. I do 
think that core plugins would be also put on a different level than 3rd 
party plugins (and this is what people are afraid of).

I've never worked where there has been a 100% ban on plugins. As someone 
else said it's a sliding scale. I use Google XML sitemaps, wp-db-backup, 
and one or two others without any thoughts of writing the functionality 

To improve plugins I'd love to see a 'checklist' that rates a plugin. 
I'd expect to see easily if a plugin totally cleans up after itself, 
will backup the data it introduced...It would also be great for WP to 
check to see if plugins are noted as version compatible before you 
upgrade and warn you which plugins are not compatible.

Mike Schinkel wrote:
> On Jun 19, 2010, at 12:29 PM, Christopher Ross wrote:
>> I have a government client which runs 50+ WordPress websites (both inside and outside firewalls) and no plugins are allowed on the site, with no exceptions. This includes stripping internal update calls, pings etc. from the core before a site can be upgraded and I know from experience, big companies are the same.
> On Jun 19, 2010, at 1:17 PM, Curtis McHale wrote:
>> I've also worked with a company that doesn't like plugins at all. Caching can be done easily without a plugin so we didn't use it. I personally also dislike plugins on my sites so avoid them at all costs. If anything can be done easily without them that's how it's done.
> I find that fascinating.  I would love to hear, for my benefit and the benefit of all on the list, what the specific concerns they have about using plugins and the rationale for not using them?  Maybe there are things we could improve/change that would resolve their concerns?
> Are their reasons tangible or intangible?  For example, do they dislike plugins:
> 1.) Because admins can enable/disable them and thus potentially break the site?
> 2.) Because they believe plugins slow down a site?
> 3.) Because they feel that plugins are not as well tested nor as well "supported" as core WordPress?
> 4.) Are they concerned about plugins that don't clean up after themselves?
> 5.) Do they require Askimet *not* be used because it is bundled as a plugin and not as core?
> 6.) Would they have a different view of core plugins vs. other plugins?
> 7.) Will they have the same opinion 100% prohibition of plugins as plugins that support vertical market functionality emerge that are specific to their business cases?
> 8.) I wonder if they understand that almost all the same code for a plugin can be put in a theme and if they have any issues with the same code in the theme?
> 9.) Is there something else?
> 10.) Or is it all simply a knee-jerk reaction because they assume anything labeled "plugin" is bad?
> I'm not at all debating their perspective but instead simply wanting to understand it.  By understanding it we as a community might be able to make the situation better for them and still achieve many of the goals of the WordPress community.
> -Mike
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

Curtis McHale


More information about the wp-hackers mailing list