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?

  • 1
    Yes, it is possible. Without more details, a better answer is impossible. May I ask you to improve your question?
    – fuxia
    Commented May 9, 2013 at 15:49
  • @toscho Sure. Do you want more examples of what I'm asking? Commented May 9, 2013 at 15:51
  • Explain your goal: Why do you think the built-in features are not enough for your specific needs? I am pretty sure, there are alternatives.
    – fuxia
    Commented May 9, 2013 at 15:55
  • @toscho I've taken another crack at it. Please let me know if it's better for you. Thanks. Commented May 9, 2013 at 16:00
  • 1
    Yes, that’s better. :)
    – fuxia
    Commented May 9, 2013 at 16:04

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.