I'm questioning how i can get rid of the post-editor (visual + html). I tried to not register post type support, and it still appears (de-registering works fine with every other default meta box on post edit screen). I also tried to deregister it with remove_meta_box, which didn't work too (works for everything else except the title meta box). Maybe i'm missing something. Already searched the web and couldn't find anything. I hope someone can tell me. Thanks!

Ps. I would be happy about a sollution for disabling the title field too, but that's 2nd (not registering it with the post type works).

(Wordpress version is 3.0.4.)

5 Answers 5


Giving a blank array to 'supports' in the declaration of the post type should get rid of the editor and the title, along with every other default box in the edit post page.

$supports = array ('');
    $args = array(
      'label' => 'people',
      'supports' => $supports,
      'hierarchical' => false,
      'public' => true,
      'rewrite' => true

    register_post_type( 'people', $args);

Result: alt text Populate 'supports' with whichever elements you want to show up, such as trackbacks, comments, etc. Or just leave it blank to leave the page empty, except for the box that lets you save your posts. Make sure to visit here if you want to get rid of hierarchical taxonomy metaboxes as well.

  • Thanks so far. My problem is that i can't set everything to empty. I wrote three classes to speed up the generation of custom post types, custom taxonomies & tags. They got defaults. In the case of custom post types it's simply everything. But i need to deregister some boxes for specific post types. And for one i need to deregister the editor box too.
    – kaiser
    Commented Jan 13, 2011 at 5:58
  • I'm interested in what do you mean by setting everything to empty? If you want to get rid of the editor, just don't put in ;editor' into the 'supports' array when you create the post type in your class. Commented Jan 13, 2011 at 6:09
  • 2
    @kaiser if it's your own classes what is the issue? Make them handle it?..
    – Rarst
    Commented Jan 13, 2011 at 6:26
  • @Rarst: It's only a base that makes the following things: register post types and taxonomies from an array and offering a filter for $labels and $args (default and specific). The terms class only generates non-deleteable terms that update and asign from an array. Meta boxes can be easy without the class and wouldn't make sense for me to integrate. The classes are only there to save me time and hold clients from deleting terms the system needs. But thanks for looking. Your help is highly appreciated (again) :)
    – kaiser
    Commented Jan 13, 2011 at 6:33
  • 2
    @kaiser then what is the problem with setting supports to empty array via filter?
    – Rarst
    Commented Jan 13, 2011 at 7:04

If you pass nothing for the supports argument, the default settings of 'title', 'editor' is used (where "nothing" is anything that is empty()).

However, just like you can add support for something after registering the post type with add_post_type_support( $post_type, $feature ), you can remove support for something by calling remove_post_type_support( $post_type, $feature ). So calling this after registering your post type should remove the editor:

remove_post_type_support( 'my_post_type', 'editor' );

These functions just manipulate the global $_wp_post_type_features variable, but it's always better to do this with API functions than to fiddle with it yourself.

  • SOLLUTION! I always thought this was just to remove ex. thumbnails or nav_menu via a child theme. Thanks a lot!
    – kaiser
    Commented Jan 13, 2011 at 8:38
  • 1
    Ouch, I missed that. Good point, passing empty array will evaluate to empty... Passing empty values is always such a mess, it is counter-intuitive so that is treated like default instead of nothing. :(
    – Rarst
    Commented Jan 13, 2011 at 9:31
  • 1
    @Rarst: I think it would also work if you passed a dummy feature name. It's just an array key, so it doesn't matter if dummy data gets inserted. I once used 0.1 instead of 0 for a parameter to pass the empty() check.
    – Jan Fabry
    Commented Jan 13, 2011 at 9:36
  • 1
    @Jan Fabry yep, it's just not the first time I stepped on empty() mine. As above - highly counter-intuitive.
    – Rarst
    Commented Jan 13, 2011 at 9:42
  • Hm. It's not working with keys and therefore i think "dummy values" could become another "mine" when upgrading later (try to find the bad value). Anyway: thanks a lot to both of you! :) Edit: would be handy if the values wouldn't just be there, but are key/value pairs. Ex. 'support' => array('thumbnail' => true, 'editor' => false);
    – kaiser
    Commented Jan 13, 2011 at 9:59

I use the Custom Post Type UI plugin to create custom post types. Using this plugin, you can disable the post-editor under the advanced options.

Manage Post Type -> View Advanced Options

Here is a link to the plugin: http://wordpress.org/extend/plugins/custom-post-type-ui/

PS - It lets you disable the title field too :)

  • As said above, i wrote three classes and therefore can't switch to a plugin. I mean i wouldn't even consider using a plugin anyway. Plugins are (imo) for development or easy interchangeable stuff like comment forms and not core stuff like post types or taxonomies. Thanks anyway!
    – kaiser
    Commented Jan 13, 2011 at 6:00
  • 1
    Actually plugins are able to customize pretty much anything about Wordpress, including custom post types. I'm creating a plugin right now that creates numerous post types, their metaboxes and their various custom fields. Commented Jan 13, 2011 at 6:29
  • @Manny Fleurmond: If you are going to share, pls drop me a link. I'm still thinking about maybe-maybe writing a routine for advanced meta-boxes in my classes too.
    – kaiser
    Commented Jan 13, 2011 at 6:37

Check out register_post_type(); in the codex. Under the Arguments section scroll down until you see Supports.

As of 3.5, boolean false can be passed as value instead of an array to prevent default (title and editor) behavior.

Or customize your custom post type how you want by adding in the values you want for example:

'supports' => array(

These supported options in my array will appear in my wordpress backend.


You may also set style for admin edit page to hide sertain elements, such as editor etc.

function custom_colors() {
   echo '<style type="text/css">
            body.post-type-events #postdivrich {
            display: none;

add_action('admin_head', 'custom_colors');
  • Thanks for your answer, but this would (a) make it non removable as it's not registered with the Dependencies API and (b) make it accessible for people who know how to use the browsers developer tools.
    – kaiser
    Commented Sep 3, 2014 at 19:20

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.