possible bug in register_post_type() in handling of 'supports' arg

  • I’ve discovered what I think is a bug in register_post_type(). I’ve searched the forums and tickets and haven’t found anything about this issue. I wanted to ask about it here before opening a ticket to make sure I’m correct.

    Suppose I call:

    register_post_type ('test', array ('supports' = array ('title', 'revisions'))) ;
$supports = array_keys (get_all_post_type_supports ('test')) ;
// $supports is now array ('title', 'revisions'), as it should be

    After that, suppose I call:

    // re-register post type with additional supported features
register_post_type ('test', array ('supports' => array ('title', 'editor', 'revisions'))) ;
$supports = array_keys (get_all_post_type_supports ('test')) ;
// $supports is now array ('title', 'editor', 'revisions'), as it should be

    After that, suppose I call:

    // re-register post type with fewer supported features
register_post_type ('test', array ('supports' => array ('title', 'editor'))) ;
$supports = array_keys (get_all_post_type_supports ('test')) ;
// $supports is now array ('title', 'editor', 'revisions'), but should be array ('title', 'editor')

    That is, if I re-register a post type with more supported features, those extra features are there. However, if I re-register a post type with fewer supported features, the larger list of features is still there.

    Digging into the core source for register_post_type() at line 1277, I see

    if ( ! empty($args->supports) ) {
		add_post_type_support($post_type, $args->supports);
		unset($args->supports);
	} elseif ( false !== $args->supports ) {
		// Add default features
		add_post_type_support($post_type, array('title', 'editor'));
	}

    and at line 1578, I see:

    function add_post_type_support( $post_type, $feature ) {
	global $_wp_post_type_features;

	$features = (array) $feature;
	foreach ($features as $feature) {
		if ( func_num_args() == 2 )
			$_wp_post_type_features[$post_type][$feature] = true;
		else
			$_wp_post_type_features[$post_type][$feature] = array_slice( func_get_args(), 2 );
	}
}

    Since add_post_type_support() just (as it’s name implies) adds to whatever features are already there, shouldn’t register_post_type() remove any existing supported features before calling add_post_type_support()?

    That is, shouldn’t there be something similar to the following added before line 1278?

    global $_wp_post_type_features ;
if (isset ($_wp_post_type_features[$post_type])) {
	$_wp_post_type_features[$post_type] = array () ;
	}

    Note: I’m not suggesting this is the best fix (I’m not that familiar with the core code), but it seems to produce the correct behavior.

Viewing 1 replies (of 1 total)
  • Moderator bcworkz

    (@bcworkz)

    You could say it’s a bug because register_post_type() creates or modifies post types, and part of modification is removing features, which does not work as expected.

    But if you take things quite literally, things work as intended, so it is not a bug. Intent and expectation being very different criteria in this case!

    How is it not a bug? (I’m not saying you’re wrong, just presenting a different point of view for the sake of discussion) It is clear the “supports” argument is a simple alias for add_post_type_support(). And we should not expect to remove support by calling add support. There is a remove support function for that.

    So I’m not sure this is an actual bug per se, rather perhaps a poor design that fails to meet expectation. I’d rather it was an alias for something called replace_post_type_support(). When provided with an argument, the old contents are removed and replaced with the new arguments.

Viewing 1 replies (of 1 total)
  • The topic ‘possible bug in register_post_type() in handling of 'supports' arg’ is closed to new replies.