Pluggable XMLRPC

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

and for trunk

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)

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

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 :)

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. :)

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.

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