I understand that WordPress allows you to create Custom Post Types with Custom Fields, but is it possible to create a custom Plug-In that creates and maintains its own Custom Post type (outside of WordPress’s Custom Posts)?
So for example, if you had a WordPress site that had a the Custom Post Type “Event”, along with Custom Fields like “Event Host”, “Location”, “Start Date”, “End Date”, “Entry Fee”, etc.
The idea is that a custom Plug-In would allow finer control to view and sort selected records from the database. So for example, a user could ask to only see events by a certain Event Host, or that has an Entry Fee between certain thresholds.
Also, if the End Date had passed (i.e. the event had finished), then all search results would not display that Event any more.
I understand that most of this may be possible using Custom Post Types and Custom Fields using WordPress, but I believe a lot of it is fiddly, limiting and slow. Being able to write the database schema and SQL statements would presumably give us a lot more power.
Does WordPress allows such levels of customisation through plug-ins?
It is possible to use custom post types and only some features WordPress adds to that API. In fact, this is the default: When you call
register_post_type(), the default value for
FALSE. No UI, no query var, no rewrite rules, list tables or public visibility. You can leave
public => FALSE, turn on only the features you need and use your custom handlers for the rest.
Take a look at the plugin Log Deprecated Notices for an example (ignore the PHP 4 code style).
$args = array( 'labels' => $labels, 'show_in_menu' => 'tools.php', 'show_ui' => true, 'public' => false, 'capabilities' => array( 'edit_post' => 'activate_plugins', 'edit_posts' => 'activate_plugins', 'edit_others_posts' => 'activate_plugins', 'publish_posts' => 'do_not_allow', 'read_post' => 'activate_plugins', 'read_private_posts' => 'do_not_allow', 'delete_post' => 'activate_plugins', ), 'rewrite' => false, 'query_var' => false, ); register_post_type( self::pt, $args );
But … if your post type is publicly visible and you prevent the access to its contents from other plugins, your users might run into some strange problems:
You will need a lot of additional tests to ensure compatibility. So the most important point is not if it is possible, but if the result will match the users mental model of your plugin. Documentation and a nice UI alone cannot fix that.
My recommendation: Try to pave the cow path. Use filters and hooks to change things at last possible moment, for example
pre_get_posts for search results.