Sorry I missed this — my notification settings were off for some reason.
Prior to version 0.9.4, you cannot rename the post_type. You can do some surgery on the data structure stored in the wp_options table to achieve this, but that’s not generally recommended.
I’ve implemented this in version 0.9.4 which will be out soon, so stay tuned for that.
Hi fireproofsocks,
First of all, thank you for this great plugin! I like it so much, that I switched from the Custom Post Type UI plugin to yours. I have some remarks/tips however to make it even better:
First of all, what crashintoty suggests would be very welcome indeed. Renaming the post_type name isn’t only very user friendly, but it will make switching between plugins even easier.
Another thing; your plugin doesn’t seem to support a dash in it’s post_type name. When you enter something like ‘custom-post‘ it will save it as ‘custom_post‘. If you happen to have created a custom post type called ‘custom-post‘ with another plugin, migrating gets very time consuming.
The last thing I’m really missing is the show_in_menu parameter. If you want to group certain custom post types in the admin menu, this parameter can be very convenient. Right now I have to add this function to my custom post type manually in my functions.php file like this:
add_action('init', 'codex_custom_init');
function codex_custom_init() {
$labels = array(
'menu_name' => 'Child post type'
);
$args = array(
'labels' => $labels,
'show_ui' => true,
'show_in_menu' => 'edit.php?post_type=parent-post-type'
);
register_post_type('child-post-type',$args);
}
Thanks for your work so far!
Cheers, Toine
Hey, thanks for the detailed note!
Yes, the data structure in versions 0.9.3 and before doesn’t use normalized field data –that was because initially this plugin was trying to keep things really simple for the book that I wrote it for (WordPress 3 Plugin Development Essentials). There’s nothing wrong with that format, and you should never be required to edit the JSON file directly. It just has the obvious limitation that any non-normalized data has: data ends up being repeated.
However, version 0.9.4 has updated the data structure and it has normalized the custom field data (see Issue 40). Version 0.9.4 should be out this week.
The limitations for the post_type name have been removed in version 0.9.4 — initially the limitation had to do with how I was handling posts via objects: so it used to be that the post type name would be used basically as a function name, so a dash would not have been allowed. (This is the type of thing that should be added as a feature request in the bug tracker, but again, this has been fixed in version 0.9.4).
There is basic support for the “show_in_menu”, but not for what you outlined. Go to the Custom Content Types menu and choose to edit the content type in question: on the “Advanced Tab” there’s a checkbox for “Show in Nav Menus” which implements the “show_in_menu” attribute in its boolean value — again, this would make a great feature request to add support for the string version of this attribute which would let you get the grouped menu items — I think that’s a new feature of the register_post_type() function (I wasn’t aware of it until now, so thanks for the heads up).
Cool, thanks! Looking forward to the 0.9.4 version.
