#9463 closed enhancement (invalid)
WP XML-RPC server classes should be in a separated file + PATCH
Reported by: | nicolagreco | Owned by: | josephscott |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | XML-RPC | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description
If i would extends the wp_xmlrpc_server class (for buddypress for example) i can't, because this class is in /xmlrpc.php and i can't call only the class.
Anyway have the class in a separated file ( maybe in /wp-includes/classes-xmlrpc-server.php ) might be better
Attached there is the patch file that might help you ;)
Nicola
Attachments (1)
Change History (14)
#2
@
15 years ago
i agree with you, having 1 xml-rpc entry point is good,
but think that:
BuddyPress is not built-in in bp so if i would to integrate xml-rpc in bp, but keeping wp_xmlrpc_server class, i can't
i don't say to remove xmlrpc.php to /wp-includes !
I want that the class 'wp_xmlrpc_server' declared in xmlrpc should be in wp-includes so others can extend it :)
Nicola
#3
@
15 years ago
i agree with you, having 1 xml-rpc entry point is good,
And that just seems to negate the need to move it elsewhere.. I mean, Its not like you CAN re-use it for other purposes.. You'd just extend IXR_Server for a different server role.. The wp_xmlrpc_server class is just IXR_Server with the default methods included, if you need to add extra methods, then use the filer..
Sorry, I could just be mising something :)
#4
@
15 years ago
I don't mean to move xmlrpc! but only the class inside to another file so if i require it in a plugin i can require only the class :)
requiring IXR_Server i won't have the wp methods :S
(think on the bp xmlrpc integration workflow)
#5
@
15 years ago
+1 I see no problem with having an include, just a little more i/o on disk. but including is a famous concept in WP so I see no real argument against this.
#6
@
15 years ago
- Keywords reporter-feedback added
What exactly are you trying to achieve here.
If you want to add methods to what WordPress supports then that can easily be achieved using the xmlrpc_methods filter - you can even change what function supports the current methods if you want.
Could you try an explain what you can't achieve - maybe a code example would help?
#7
@
15 years ago
i can not speak for the poster, but if it is easily includeable, a simple code example can be:
class modded extends wp_xmlrpc_server { // subclassing: overwriting, extending etc. } $modded = new modded();
this way an instance w/o an instance of wp_xmlrpc_server is possible.
if definition and instantiation is within the same file (like it is currently), this won't be possible.
#8
@
15 years ago
I now took a closer via to the XMLRPC class. If a plugin developer want's to add a RPC method, he/she can not, because the current method-calls via RPC prevent adding hooks dynamically. The methodnames must be defined in class wp_xmlrpc_server which can not be achieved by runtime.
Even it is already possible to filter the methodnames, this only makes sense to remove them, but not to add.
So far I'm concerned about nicolagreco motivation, he was after getting xmlrpc extended to be able to provide bbpress xmlrpc funcitons.
adding hook:methods might help here. it could be quite easily implemented by subclassing IXR_Server::call with wp_xmlrpc_server::call and filtereing those.
#10
@
15 years ago
I've read through the comments and I'm still not sure what nicolagreco is wanting to do that can't already be done.
It's very easy on WordPress to add new XML-RPC methods, I wrote a post on this very subject last year:
http://josephscott.org/archives/2008/11/adding-xml-rpc-methods-to-wordpress/
The 'xmlrpc_methods' filter can be use to remove, replace and add XML-RPC methods. It's very stable and works well.
What would you like to extend it to do exactly?
For most uses, Adding an extra XML method can be done via the 'xmlrpc_methods' filter.
Its' best to have a single XML-RPC entry point (AFAIK), and the current one is exposed in the headers.. so it wouldn't make sense to have another entry point elsewhere, it could just confuse other XML-RPC clients.