Opened 17 years ago
Closed 17 years ago
#5744 closed enhancement (wontfix)
Pluggable XMLRPC
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | XML-RPC | Keywords: | has-patch |
Focuses: | Cc: |
Description
IT is reasonable to provide plugin authors a way of providing their own xmlrpc engine. Though standard methods likely remain the same to maintain compatibility with XMLRPC API clients, adding additional methods or functionality is hampered right now as xmlrpc.php is not pluggable.
Enter this patch which adds a new hook, load_xmlrpc_engine that can override the stock xmlrpc.php functionality.
Attachments (2)
Change History (9)
#1
follow-up:
↓ 3
@
17 years ago
I can see that plugin authors would want to add/override XMLRPC functions, But i cant personally see a reason to want to override the entire class, Afterall, if theres a problem with the current class, it should be fixed.
If someone wants to add/remove a RPC function, the 'xmlrpc_methods' filter allows it to happen.
(Apologies if its right off what you're wanting, I've got little experience with the RPC code)
#2
@
17 years ago
- Keywords has-patch added
- Milestone changed from 2.5 to 2.6
- Owner changed from anonymous to josephscott
#3
in reply to:
↑ 1
;
follow-up:
↓ 4
@
17 years ago
Replying to DD32:
I can see that plugin authors would want to add/override XMLRPC functions, But i cant personally see a reason to want to override the entire class, Afterall, if theres a problem with the current class, it should be fixed.
If someone wants to add/remove a RPC function, the 'xmlrpc_methods' filter allows it to happen.
(Apologies if its right off what you're wanting, I've got little experience with the RPC code)
In my case, all the methods need to be altered slightly - but I know what you're saying and in principle you're right. This kind of "whole class overriding" has precedent. We used this method to solve the Magpie question.
http://trac.wordpress.org/changeset/5776
http://trac.wordpress.org/changeset/5845
#4
in reply to:
↑ 3
;
follow-up:
↓ 5
@
17 years ago
Replying to technosailor:
In my case, all the methods need to be altered slightly - but I know what you're saying and in principle you're right.
This kind of "whole class overriding" has precedent. We used this method to solve the Magpie question.
Yup.. Thats what poped into my mind, But what occurs to me is that if the current implementation isnt flexibly for what developers need, then maybe its best to fix it so that it can handle what devs need.
By allowing full class overrides, it limits users to only running one plugin which modifies it, And unless its for a single highly customised WP install, It seems limiting on users(Ok, Its nearly a moot point, The fact that the chances of WP users wanting to run 2 different plugins which override the same class is incredibly small).
Its just by 0.03c(Inflation & Exchange rates), and i dont expect it to make much of a difference overall anyway :)
#5
in reply to:
↑ 4
@
17 years ago
Replying to DD32:
Replying to technosailor:
In my case, all the methods need to be altered slightly - but I know what you're saying and in principle you're right.
This kind of "whole class overriding" has precedent. We used this method to solve the Magpie question.
Yup.. Thats what poped into my mind, But what occurs to me is that if the current implementation isnt flexibly for what developers need, then maybe its best to fix it so that it can handle what devs need.
By allowing full class overrides, it limits users to only running one plugin which modifies it, And unless its for a single highly customised WP install, It seems limiting on users(Ok, Its nearly a moot point, The fact that the chances of WP users wanting to run 2 different plugins which override the same class is incredibly small).
Its just by 0.03c(Inflation & Exchange rates), and i dont expect it to make much of a difference overall anyway :)
No, no. My (our) implementation has nothing to do with inaccuracies or weakness in the existing class. We need to support our own login methods, etc. Like you said, probably moot for most users. :)
#6
@
17 years ago
- Component changed from General to XML-RPC
If all you need is to authenticate from somewhere else besides the regular WordPress database then you should be looking at the plugin features for WordPress auth.
All of the XML-RPC methods make use of login_pass_ok(), which uses user_pass_ok(), which uses wp_authenticate() which is in pluggable.php so that you can override it to use what ever back end auth mechanism you'd like.
For WP 2.3 - will include patch for WP 2.5 as well