Make WordPress Core

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#3994 closed defect (bug) (wontfix)

MetaWeblog metaWeblog.getCategories problem

Reported by: whilo's profile whilo Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.2
Component: XML-RPC Keywords: xmlrpc, compliance, specs, clients, metaweblog, categories
Focuses: Cc:


As stated in the "standard" at the server should respond with a struct of structs instead of a data array of structs, as wordpress does.

"The struct returned contains one struct for each category, containing the following elements: description, htmlUrl and rssUrl."

Change History (11)

#1 @foolswisdom
15 years ago

Does this problem exist in other versions of WordPress? What makes the severity critical? What scenario did you discover the problem in? Thank you!

#2 @westi
15 years ago

  • Milestone 2.0.10 deleted
  • Severity changed from critical to normal
  • Version set to 2.2

I can reproduce this - The code in class-IXR that determines what type to return for this call and any other similar call to which we return and anonymous array or arrays will result in an XMLRPC response containing an array of structs.

However, I am not convinced this is a bug as the original metaweblog spec as linked is not very detailed and other implementations appear to return an array of structs e.g.

#3 @whilo
15 years ago

Sure it is not very precise, but it says a struct of structs. This is still not an array. Either it is standard or it is not. In my opinion it is very important to keep as close as possible to a standard, even if it is not a good one. It makes using the interface much more frustrating, if serverside software works different with the same standard.

#4 @Otto42
15 years ago

Standards are important, but so is compatibility. Can you point to other implementations that do actually return a struct of structs?

#5 @Nazgul
15 years ago

  • Milestone set to 2.4 (future)

#6 @josephscott
15 years ago

  • Cc josephscott added

#7 @dougal
15 years ago

  • Keywords xmlrpc compliance specs clients metaweblog categories added

This mis-implementation has been out there for several years now, so the major clients are either explicitly or implicitly working around it. We need to test the clients against a 'fixed' version of the method and make sure nothing breaks. If the major clients don't break with the change, we can get a fix committed. Otherwise, we might need to coordinate with the client authors to see how we can smooth out a more gradual migration to spec compliance.

The spec is vague. One must assume that the category name is what should be used as the 'name' portion of the parent struct, though the category slug might be a good candidate, as well. The use of an array probably stemmed from the fact that the category portion of a post struct is implemented as an array in the spec.

#8 @josephscott
15 years ago

Just as a note to whilo and others who might be following this, there is discussion on the list about this issue.

#9 @redsweater
15 years ago

foolswisdom said it best at the outset. Unless there's a clear scenario where not fixing this is causing harm, it shouldn't be considered. The MetaWeblog spec is not clear enough or widely enough followed to have fixes done "just to be in compliance."

Also, MetaWeblog API per se is rather uncommonly used these days as most clients will prefer the MovableType or WordPress supersets, in which case the mt.getCategoryList method would be used instead.

I don't think you guys should waste your time trying to fix or compromise for this issue. It would be change for change's sake, and a waste of time when real problems need fixing.


#10 @josephscott
15 years ago

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

As others have noted, the spec if vague on what exactly the returning data structure looks like, most others seem to have implemented it the same way WordPress has, clients have long since adapted to the way WordPress is returning this data.

There doesn't appear to be a compelling reason to change at this point, so I'm closing this as wontfix.

#11 @lloydbudd
15 years ago

  • Milestone 2.4 deleted
Note: See TracTickets for help on using tickets.