可以使用自定义的帖子类型，并且只能使用WordPress添加到该API中的一些功能。事实上，这是默认设置：当您调用register_post_type(), 的默认值public 是FALSE. 没有UI、没有查询变量、没有重写规则、列表或公共可见性。你可以走了public => FALSE, 仅启用所需的功能，其余部分使用自定义处理程序。

看看插件Log Deprecated Notices 例如（忽略PHP 4代码样式）。

    $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 );

但是……如果您的帖子类型是公开的，并且您阻止其他插件访问其内容，您的用户可能会遇到一些奇怪的问题：

用于内部搜索的插件（如Relevansi或search Everything）可能无法按预期工作，因为相关性权重可能表现得很奇怪站点地图。xml生成器可能找不到内容

内置的角色和功能可能并不总是有效

您需要进行大量附加测试以确保兼容性。因此，最重要的一点不是这是否可能，而是结果是否符合用户对插件的心理模型。单靠文档和良好的UI无法解决这一问题。

我的建议是：试着铺路。例如，使用过滤器和挂钩在最后可能的时刻更改内容pre_get_posts 搜索结果。