Make WordPress Core

Opened 17 years ago

Closed 17 years ago

#5744 closed enhancement (wontfix)

Pluggable XMLRPC

Reported by: technosailor's profile technosailor Owned by: josephscott's profile josephscott
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)

wp23xmlrpc.diff (118.8 KB) - added by technosailor 17 years ago.
For WP 2.3 - will include patch for WP 2.5 as well
wp25xmlrpc.diff (132.1 KB) - added by technosailor 17 years ago.
and for trunk

Download all attachments as: .zip

Change History (9)

@technosailor
17 years ago

For WP 2.3 - will include patch for WP 2.5 as well

@technosailor
17 years ago

and for trunk

#1 follow-up: @DD32
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 @lloydbudd
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: @technosailor
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: @DD32
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 @technosailor
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 @josephscott
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.

#7 @josephscott
17 years ago

  • Milestone 2.6 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Setting this as won't fix, so far no use case has been brought up that can't already be done.

Note: See TracTickets for help on using tickets.