WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#4115 closed defect (bug) (fixed)

getCategoryList should not include Blogroll in list of categories

Reported by: redsweater Owned by:
Milestone: 2.3 Priority: normal
Severity: normal Version: 2.2
Component: XML-RPC Keywords: needs-patch
Focuses: Cc:

Description

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.

This is accomplished in xmlrpc.php by adding a " WHERE category_count > 0" clause to the (questionable) direct SQL lookup.

Patch attached: xmlrpc.php.diff

Attachments (1)

xmlrpc.php.diff (688 bytes) - added by redsweater 8 years ago.
Patch to exclude empty categories from the getCategoryList function call.

Download all attachments as: .zip

Change History (18)

@redsweater8 years ago

Patch to exclude empty categories from the getCategoryList function call.

comment:1 @redsweater8 years ago

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

comment:2 in reply to: ↑ description ; follow-up: @rob1n8 years ago

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.

comment:3 in reply to: ↑ 2 @foolswisdom8 years ago

  • Milestone changed from 2.4 to 2.2

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?

comment:4 @foolswisdom8 years ago

  • Keywords has-patch added

comment:5 follow-up: @Otto428 years ago

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.

comment:6 in reply to: ↑ 5 ; follow-up: @foolswisdom8 years ago

  • Keywords needs-patch added; has-patch removed

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.

comment:7 in reply to: ↑ 6 @redsweater8 years ago

  • Cc redsweater added

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.

comment:8 follow-up: @rob1n8 years ago

  • Milestone changed from 2.2 to 2.3

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.

comment:9 in reply to: ↑ 8 ; follow-up: @foolswisdom8 years ago

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?

comment:10 in reply to: ↑ 9 @rob1n8 years ago

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.

comment:11 @josephscott8 years ago

  • Cc josephscott added

comment:12 @Otto428 years ago

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.

comment:13 @redsweater7 years ago

  • Summary changed from getCategoryList should exclude empty categories by default to getCategoryList should not include Blogroll in list of categories

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).

comment:14 @josephscott7 years ago

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

comment:15 @redsweater7 years ago

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/)

comment:16 @redsweater7 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:17 @lloydbudd7 years ago

  • Milestone changed from 2.4 to 2.3
Note: See TracTickets for help on using tickets.