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

Curtis Work curtis at curtismchale.ca
Mon Jun 21 19:01:12 UTC 2010 

I'd help out verifying plugins.

Curtis McHale
Http://www.curtismchale.com
604.751.3482

On 2010-06-21, at 11:16 AM, Mike Schinkel  
<mikeschinkel at newclarity.net> wrote:

> 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
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list