#3994 closed defect (bug) (wontfix)
MetaWeblog metaWeblog.getCategories problem
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.2 |
Component: | XML-RPC | Keywords: | xmlrpc, compliance, specs, clients, metaweblog, categories |
Focuses: | Cc: |
Description
As stated in the "standard" at xmlrpc.com 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)
#2
@
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. http://msdn2.microsoft.com/en-us/library/aa905667.aspx
#3
@
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
@
15 years ago
Standards are important, but so is compatibility. Can you point to other implementations that do actually return a struct of structs?
#7
@
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
@
15 years ago
Just as a note to whilo and others who might be following this, there is discussion on the http://lists.automattic.com/mailman/listinfo/wp-xmlrpc list about this issue.
#9
@
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.
Daniel
#10
@
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.
Does this problem exist in other versions of WordPress? What makes the severity critical? What scenario did you discover the problem in? Thank you!