Is it possible to create Custom Post plug-in?

3 Views

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.

Read More

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?

Post Views: 3

Related posts

1 comment

  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.

Comments are closed.