Better support for custom post types in WP_Rewrite

[nacin]

See also #12605 and [13773].

We currently use bitmasks in WP_Rewrite, which we should remove and convert to an array of URL types that can be checked using in_array(). We currently do not use bitmask operations in WP_Rewrite that would make them preferable for use.

To currently use custom post types with endpoints, a plugin would need to do the following, from dd32 in #12605:

define('EP_WIKI', 131072); // 2^17. 2^13 is used by core.
register_post_type('wiki', array(
	'label' => __('Wiki'),
	'public' => true,
	'supports' => array('revisions', 'editor', 'title'),
	'permalink_epmask' => EP_WIKI,
	'hierarchical' => true
));
add_rewrite_endpoint('history', EP_WIKI);

In particular:

Care would need to be taken that any custom endpoints are in 2^x format, and not currently in use by any other plugins loaded.

This would need to be backwards compatible with the existing bitmasks. More or less, WP_Rewrite::add_endpoint() would need to still take bitmasks and convert them to the new format.

Incomplete patch. Incomplete support. Hardly tested. Probably buggy. Probably a better way.

As well as using strings like that, I'd like to have a supports style granity to it.

For example, Take adding post_types, they'll all get given the same set of permalinks regardless of if they support a function or not, for example, all will receive paging and comment paging rules regardless of if they actually support it.

This might be part of a larger write to make the rewrite rule generation/parsing more optimized for various cases..

Moving to 3.1 due to lack of full patch and enough testing time for this.

-1 on using end_point mask constants for this. Too cryptic for 80% of the people who will be struggling to write the register_post_type() code for what they need. Use strings instead.

How about bundling all the endpoints in the 'rewrite' arg?

Example:

register_post_type( 'foo', array(
  ...
  'rewrite' => array(
    'slug' => 'fooz',
    'extra_endpoints' => array( 'bar', 'baz' )
  )
);

Sidenote:

Instead of using EP_MASK, I found it much easier to just use add_rewrite_rule(), with the CPT slug prefixed to it. Now, if only add_rewrite_rule() had a $with_front arg...

conflict free EP_MASK defines

Above patch offered as a quick and easy alternative

Related #16303

Interesting solution in add_register_epmask.patch​, but you mispelt $wp_ep_increment.

Doh! Er, would ya believe "incement" as meaning solid?