[wp-hackers] Is there any compelling reason to use a custom post type plugin?

[Angelia Baladon]

I've been following along with the development of custom post types as
the code was being written in WP 3.0, and because use of the new post
type features were crucial for the functionality of a site that I was
building for a non-profit group that helps get art into the schools,
went ahead and built the site alongside the development of 3.0 over
the last six months.

Initially I was hand coding everything myself in my functions file in
regards to my custom post types, and taxonomies. Then there was an
issue with permalinks and whether it would be done in core or not,
yadda yadda, and I saw some good development happening in the way of
plugins for managing the custom post types. I was extremely nervous at
first to relinquish control, but, after many days of research and
looking at all of the code to be sure that I understood exactly what
was happening in it and could make my own adjustments if need be, I
decided to go with a plugin. Once this was firmly decided and I
installed the plugin and updated the supports array and other code to
be in line with the development. I then had my client go ahead and
enter terms ( not hundreds, but, thousands of hierarchical ones ) to
begin testing the filtering and relations functions.

Fast forward through months of building the site and entering content,
and we have found that we also need to register our taxonomies to the
default "link" object type. This shouldn't be a problem, as I can just
add register_taxonomy_for_object_type('art', 'link'); and I'm good to
go. But, as it turns out, this isn't the case. The code in the
management plugin is using a foreach loop through (get_post_types) to
create the checkboxes in the plugins interface for registering a
taxonomy to an object type. Of course, get_post_types does not
encompass the link object type.

At this point, I figured I was still okay, I had options:

Here are those options and the results of them over the past desperate week.

Option 1 - Put in a support request to the plugin developer to make
this inclusion so that everything stays clean in the backend.
Response - one quick "I'm not sure what you're getting at" and then
silence for the last week, despite my immediate and very clear
explanation.

Option 2 - hack the plugin again, and write it in myself.
Response - despite endless hours of effort, and inquiries here, I have
not been able to figure out a way to rewrite this foreach loop to
include the link object type.

Option 3 - Append a checkbox to the end of the foreach for the
post_types and have it register that way.
Response - Same as above. I haven't been able to figure out how to
create this checkbox properly, and I haven't received any response to
my requests for help.

Option 4 - Forget about the code being clean and just add the
register_taxonomy_for_object_type('art', 'link'); in my functions
file.
Response - The plugin is coded with some complex class specific
functions now that I don't entirely understand, but, I believe that
the code is saying, "if it isn't registered within this class ...
ignore it."

Option 5 - Beg, plead and publicly humiliate myself for any help whatsoever.
Response - none. ;-) I don't think I would respond to me either.

Option 6 - Push the deadline forward again, completely remove the
plugin, which will also remove or orphan all of my terms and the other
code in the site that is tied in with some of the functions within the
plugin, rewrite all of the registration functions for the post types
and taxonomies again, and have my client re-enter the thousands of
terms.
Response - Gigantic pain the #$@!, but, this will work and will avoid
this ever happening again.

Through this experience, I have come to the conclusion that it is VERY
important that these folks who are writing these particular plugins
realize that this is a monumental breakthrough in WP, and that it
affects more than what most plugins have ever affected. These post
types are the very core of the sites that are utilizing them, they are
the new "post". People are relying on them to be coded thoroughly and
accurately. Yes, they are plugins, and they are free, and someone was
kind enough to code them for everyone else's use, and that is the
beautiful thing that draws so many to WP to begin with. Believe me,
I'm not trying to look a gift horse in the mouth. I'm not that person.

I just feel that as a community we need to speak about these things,
and that in regards to this specific area, plugin developers need to
be acutely aware of the big mess a poorly coded or supported post
management plugin can cause. I believe this custom post type
advancement has created a lot of interest in WP, and I hate to think
of someone deciding to make the switch to WP, perhaps because of the
custom post type advancements, only to have what I've just gone
through happen to them. Can you imagine telling a client that they
need to reenter 3 years worth of terms or content or worse?

Having said that, I'll get to my point.

I feel that if the above plugin developers are going to put code out
there that they know is incomplete or that they have no intention of
maintaining or supporting, that they at least need to code it with two
very important things in mind:

#1 - Allow the plugin to be disabled without losing the terms
associated with the taxonomies. This should be an option. Should the
plugin not stay up to date or just not be supported any more, the site
administrator should be able to disable it, and enable another. In
that new plugin ( or in their functions file ), they should be able to
register their post types and taxonomies again, or perhaps even have a
way to de-register without erasing, and re-register a post type, and
taxonomies, so that when they are re-registerd all of the terms and
relations are in tact. I know that I had a problem with this when I
was first testing the plugin I went with, where a revision existed in
the database with a custom post type attached from my hand coded
version, and therefore I could not register the post type with the
plugin.

#2 - Do not wrap the registration functions in classes in such a way
that the site administrator cannot interact with their custom post
types and taxonomies via core code hooks and filters, outside of your
plugin ... i.e. if your plugin code is registering my custom
taxonomies, and I need to add in
register_taxonomy_for_object_type('art', 'link'); because it is not in
your code, don't make that an impossibility for me. Otherwise, an
awful lot of people are going to be hitting dead ends in the future,
as this great new functionality evolves, and they are locked into code
like this that controls such an important aspect of their site.

If you've gotten this far in reading this novel, then I will continue
on with what is an actual request for advice:

So many of you out there are so much more advanced than myself in
understanding all of this, and I respect your knowledge and
experience. Having read the above, and knowing that my only option at
this point is to go back to hand coding everything with no GUI, do you
feel that there are any crucially important aspects of custom post
types that are being handled by a plugin, that aren't being handled in
core?
I don't see any, but, this time I'm asking questions. I don't want to
just go on my own theories and possibly make the same mistake again.

Labels are handled
Capabilities are handled
Permalinks are handled
Supports array is thorough

Does anyone have any compelling argument for why it would be better to
use a plugin for managing post types and taxonomies, if you are
capable of doing all of the registrations yourself in your functions
file?

Feedback encouraged ...