[wp-hackers] support for custoim post types + custom feilds
curtis at curtismchale.ca
Mon Jun 21 19:01:12 UTC 2010
I'd help out verifying plugins.
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
> 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...
> 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
>> 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
>> 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
>> 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
>>> 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
>>> 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.
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>> Curtis McHale
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers