wp_list_categories feed links unaware of custom type

[belg4mit]

wp_list_categories accepts a taxonomy argument to specify a custom taxonomy, and correctly lists item of said taxonomy. However the feed links produced lack the necessary ?post_type= for the corresponding custom post types that may be used with a category.

Ideally the function could auto-detect stuff and do the right thing automatically. Less ideally it might accept another argument to define the post types used in the category. At a minimum, this should be documented, and a work-around such as the following included:

function wp_list_cat_custom_feed($txt){
  return preg_replace('/\/feed\/?/', '/feed/?post_type=foo', $txt);
}
add_filter('wp_list_categories','wp_list_cat_custom_feed');

[nacin]

?post_type=foo should not be necessary in this case. If you are viewing a taxonomy query, it should automatically pick up all post types assigned to that taxonomy.

For tags and categories, I think this might be different, for backwards compatibility reasons. But your solution should probably be to set post_type on pre_get_posts to the valid post types for that taxonomy when is_category or is_tag.

[belg4mit]

Sorry, we're making different assumption here. I named the function explicitly because
it is being called explicitly. I have a custom taxonomy 'bar' in which I place custom
posts of of type 'foo'. I have a template in which I call wp_list_categories explicitly
to list all 'bar's, and the feed links fail without the filter.

I just spent 3 hours this morning trying to get it to work with a rewrite rule only.
In the end no rewrite is required, but the parameter is.

[nacin]

/bar/some-term-in-bar/feed/ should show posts of type 'foo' (and any other types for which the taxonomy 'bar' is assigned). Is that not the behavior you are seeing?

[belg4mit]

Replying to nacin:

/bar/some-term-in-bar/feed/ should show posts of type 'foo' (and any other types for which the taxonomy 'bar' is assigned). Is that not the behavior you are seeing?

Alas, no, it is not. I get 404s without the added parameter.

[belg4mit]

You are right, it's not needed. It turns out in my hours of fiddling about I made a different change that actually fixed things, I had also added a negative look-ahead assertion to my rewrite-rule:

#add_rewrite_rule('^bar/[^/]+/([^/]*)/?',        'index.php?foo=$matches[1]','top');
 add_rewrite_rule('^bar/[^/]+/((?!feed)[^/]*)/?','index.php?foo=$matches[1]','top');

(The rule is part of a tag and post link filter to make foo's appear /bar permalinks.)

[johnpbloch]

belg4mit seems to be saying that his original bug report was invalid. Closing.