getCategoryList should not include Blogroll in list of categories

Patch to exclude empty categories from the getCategoryList function call.

Thinking about this a bit more, it might be a mistake to change the existing functionality to exclude categories that were previously included. I suppose some clients might rely on this behavior.

I wonder if it would be reasonable to instead add some custom fields to the struct, to advertise the "has children" attribute.

Daniel

Replying to redsweater:

The list of categories returned by getCategoryList should exclude "empty" categories by default, as this is how the web UI behaves. It's awkward for desktop clients to have a list with weird category names such as "Blogroll" that are only used in Links.

I don't agree. Technically, even though they are empty, empty categories are still categories and thus should be included when getCategoryList is called.

Making the XMLRPC work exactly like web UI doesn't exactly make sense, as they're two different implementations.

Replying to rob1n:

I don't agree. Technically, even though they are empty, empty categories are still categories and thus should be included when getCategoryList is called. Making the XMLRPC work exactly like web UI doesn't exactly make sense, as they're two different implementations.

I think redsweater describes the best experience for the customer. What is your concern with that experience rob1n?

I agree with rob1n. getCategoryList should return a list of all viable categories for posting into, empty or not. It may make sense to exclude link categories, but empty categories must be returned.

Specific example: I'm using an XML-RPC posting client on, say, my cell phone. It pulls the categories and lets me type a post in. It can't create a category, and it can't assign multiple categories, because it's a crap client. But still, it's got a list of cats and I can pick one.

So I make a new category in WP, called "Phone Posts". I go to my phone, pull up the client.. Only the category is not in my list. And it's not going to be until I make a post to that category using something other than the XML-RPC client, because we exclude empty categories? That makes little sense.

Replying to Otto42:

I agree with rob1n. getCategoryList should return a list of all viable categories for posting into, empty or not. It may make sense to exclude link categories, but empty categories must be returned.

Filtering out link categories that have only been used for link categories seems like a decent compromise with a goog UX.

Replying to foolswisdom:

Replying to Otto42:

I agree with rob1n. getCategoryList should return a list of all viable categories for posting into, empty or not. It may make sense to exclude link categories, but empty categories must be returned.

Filtering out link categories that have only been used for link categories seems like a decent compromise with a goog UX.

I like this compromise too, for what it's worth :)

In fact, I think giving users the ability to select empty, non-link categories is perhaps a preferrable user experience to the "hide empties" behavior in the web interface.

I don't think hiding link categories is correct, since unless I'm missing something big, posts can go into link categories. The categories are essentially transient -- they're post categories, link categories, and tags. Don't ask about the last one... I along with many others wanted tags in another table.

Replying to rob1n:

I don't think hiding link categories is correct, since unless I'm missing something big, posts can > go into link categories.

A link category is defined to me as one that has been used for links, but has not yet been used for posts. That seems like a good compromise. Do you have a suggestion for a better experience?

Replying to foolswisdom:

Replying to rob1n:

I don't think hiding link categories is correct, since unless I'm missing something big, posts can > go into link categories.

A link category is defined to me as one that has been used for links, but has not yet been used for posts. That seems like a good compromise. Do you have a suggestion for a better experience?

Yes, but in the current category setup, link categories and post categories are transparent. So technically they're only "categories," from a semantic point of view. If we didn't show these in getCategoryList, then it wouldn't *really* be getCategoryList, would it? ;)

But it also detracts from being able to post into all categories that you *can*, since the XML-RPC client wouldn't be aware of the other categories unless we extend and make a new API, but that wouldn't be supported at all.

Is this even relevant anymore? With the new terms stuff, categories got separated again. We now are (sadly) back to having more or less completely separated post and link categories. Same table, but with a separation on column content nevertheless.

Somebody should check to make sure XMLRPC works as expected for getCategoryList and if so, mark this one as invalid.

I'm changing the Summary from:

getCategoryList should exclude empty categories by default

to:

getCategoryList should not include Blogroll in list of categories

That better emphasizes my core concern here. I thought when I first reported this that it might get better traction if I stated the problem as more of a "consistency problem." But what I really want is to get that dang "Blogroll" item out of the category list, because it confuses my users (and ultimately causes users to resent WordPress's behavior).

I've been trying to reproduce this with no luck. I suspect that r5758 fixed this for us back in June.

When I do a getCategoryList against my test blog on Wordpress.com, I still get the Blogroll item:

<value><struct>

<member><name>categoryId</name><value><string>1356</string></value></member> <member><name>categoryName</name><value><string>Blogroll</string></value></member>

</struct></value>

Wouldn't the Wordpress.com install have the fix from June that is alleged to have fixed it?

(My test wordpress.com blog: http://sweatertest.wordpress.com/)

It looks like the Blogroll item I described above was a fluke. Somehow in my testing I must have selected that Blogroll item from the list and thus caused a real Blogroll category to get created on my Wordpress.com test account.

I tested against a clean 2.3.1 install and the bug does appear to be fixed! Nice.