randyhoyt/subpost

WordPress: Plugin: Subordinate Post Type Helpers

subpost's Issues

Make Content textarea a rich editor

Allow Advanced Custom Fields in subordinate post type lightbox

Lots of notice warnings when activated.

Thanks Randy for fixing the other issues!

Another one I wanted to flag is when define('WP_DEBUG', true) there a lot of notices that show up in the admin and subordinate post type interface all over the place.

Title is marked as required, but a blank title is allowed

Error in lightbox in debug mode

Here's the notice:

Notice: Undefined offset: 1 in /home/polumetis/webapps/polumetis_subpost/wp-includes/vars.php on line 28

Because children.php is in /wp-content/ instead of /wp-admin/, the $self_matches array is empty. I posted a question here:

• http://wordpress.stackexchange.com/questions/71437/error-with-custom-admin-screen-in-iframe-thickbox

Set default View All label in sidebar

Just some feedback on what this looks like with show_in_menu true on subordinate post types ... in my case I will need to leave these in the menu to be accessed on their own as well as from within the parent editor ... but, as is, the visual structure is confusing. There are two links ... one for the title, and one for the dash. Wouldn't it be better to lose the redundant dash?

Bug with getCurrentPostType

I have three subordinate custom post types which all share one parent post type.

On the parent admin edit screen:
subpost_add_meta_box renders correctly for all three subordinate post types
However ...
subpost_render_meta_box renders the same post type in all three metaboxes

$post_types[$sub_post_type_factory->getCurrentPostType()] returns only one value

I believe the problem is happening here ...
public function getCurrentPostType() {

    return self::$sub_post_type_current;

}

but, I am not skilled enough to confirm that.
Anything I can do to test this to get it fixed?

Use 'post' as parent post type

Unregistration

Randy, I use the following function courtesy of Nacin to properly remove stuff when I decide I don't want the post type I've created any more ( for instance I created a "test" custom post type while trying to figure out the issue with the add_meta_box ) ... it would be great to extend this to include all things subordinate.
When I used this unregister function to remove the test subordinate post type, the menu items still lingered until I actually removed the registration code ... so, I imagine it isn't an entirely clean unregistration right?

if ( ! function_exists( 'unregister_post_type' ) ) :
function unregister_post_type( $post_type ) {
global $wp_post_types;
if ( isset( $wp_post_types[ $post_type ] ) ) {
unset( $wp_post_types[ $post_type ] );
return true;
}
return false;
}
endif;

add_action( 'init', 'remove_post_init', 11 );

function remove_post_init()
{
unregister_post_type( 'tsa_test' );
}