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

Mon Jun 21 18:16:00 UTC 2010

Hey Curtis,

Your list was great.  I've had exactly the same issues, especially #2.  I figure "core" plugins will likely be more APIs than end-user features and that would work nicely.

Sounds like #3 would not be an issue with "core" plugins, since they would be tested to work prior to release.

As for non-core plugins and #3 I'm wondering if it would be viable for WordPress.org to form a volunteer team of plugin testers that could "certify" plugins to be compatible (yes, it would only happen for ~10% of plugins, but those would likely be the most used 10%.)  Add to that the ability to "chain" optional plugins that augment a given plugin and then the community to identify and fix incompatible plugins.

Automattic could even potentially offer a service to companies where the companies register the plugins their websites use and pay an annual fee to have those plugins maintained.  The fee could be a sliding scale depending on which plugins they needed maintained. With the revenue Automattic could then hire people to work on the plugins that nobody works on on a volunteer basis.

Just some thoughts...

-Mike

On Jun 21, 2010, at 12:29 PM, Curtis McHale wrote:

> 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 information.
> 
> 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 again.
> 
> 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
> 
> 604.751.3482
> http://curtismchale.ca
> http://twitter.com/curtismchale
> http://ca.linkedin.com/in/curtismchale
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers