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 public is 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:
- Plugins for internal search (like Relevanssi or Search Everything) might not work as expected, because relevance weighting could act strange.
- Sitemap.xml generators might not find the content.
- The built-in roles and capabilities might not always work.
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.