[wp-hackers] support for custoim post types + custom feilds
curtis at curtismchale.ca
Mon Jun 21 17:06:38 UTC 2010
There should also be an easy mechanism of transferring plugin
ownership/responsibility to a new person. I know this has been discussed
in previous threads so...
There should be a way for you to remove a plugin from the repo as well.
As you've stated people bug you about a plugin that you haven't
supported in years. If it's still in the repo I'd ask why? It really
should be removed and it should be easy for a plugin author to remove it.
On top of clean uninstall it should offer to give you a downloadable
.zip of the data before deletion. If you're removing it I'm guessing you
don't need it but having it as a standard option is a good idea IMO.
With version compatibility I think WP should recognize if a plugin is
not listed as 3.0 (or whatever) compatible and warn you of that.
eric at eamann.com wrote:
> So let's put together a checklist. Quite a few plug-in developers follow this
> mailing list, so if we build a checklist and mark it as complete (perhaps even
> add a page to the plug-in development section of the codex?) then it gives us
> the foundation for a standard.
> So far you've covered a few points:
> 1) Clean install/uninstall (document what options and db tables are created -
> remove both on uninstall).
> 2) Version compatibility (the WP site already has a framework in place for this,
> but it's not as explicit as many of us would like - maybe set a few standard
> tests and checks to verify it works with each version? Like a documented list
> of which WP functions the plug-in depends on which can easily be compared to the
> list of out-dated/deprecated/unsupported functions in core).
> Some things I'd like to see are explicit guarantees of support. When is the
> plug-in released? Who is the individual responsible for coordinating support if
> something breaks? How long does the author intend to support the plug-in?
> There are people still using a plug-in I wrote years ago that I've stated many
> times I no longer support (the functionality it provides is now a part of core
> and redundant), but I still get the occasional "X broke when I did Y" email.
> If we put together a standard, then it's a quick matter for plug-in authors to
> say "My plug-in meets the ---- standard as of 6/21/2010" and offer that
> additional level of comfort for end-users. It also makes it easy to audit that
> statement if, for example, an author failed to actually test against a new
> On June 21, 2010 at 4:46 PM Curtis McHale<curtis at curtismchale.ca> wrote:
>> Yeah that's probably pretty close. Like I said if there was a more
>> robust system for plugins to get into the repository or a checklist that
>> plugins had to match up against I believe that some of the issues would
>> not be present.
>> scribu wrote:
>>> Summarizing what I've read so far:
>>> Plugins are for hobbyists. Serious sites don't trust them.
>>> Themes are ok, because [unlike plugins?!] their code can be reviewed.
>> 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