Add plugin information to XML-RPC

[joehoyle]

Currently XML-RPC does not provide any method to access plugin information. I wrote a patch for xmlrpc.php that adds the wp.getPluginList method (calls wp_getPluginList()). The method basically returns get_plugins(), but also adds in two keys to each plugin array:

['active'] (bool) //if the plugin is currently active
['latest_version'] //the latest version of the plugin (using get_transient( 'update_plugins' )

[joehoyle]

can anyone provide any information on acceptance etc of this? I created this patch over 3 months ago and have not had any response. I did post this issue on the xml-rpc mailing list to which Josepth replied saying this should be able to be included in core, but to create a trac ticket with a patch. After taking the time to write this I am a little disappointing that it seems to have fallen on deaf ears.

[lloydbudd]

Replying to joehoyle:

can anyone provide any information on acceptance etc of this?

If it was my patch, I would follow up directly to Joseph over email... failing that, I would follow up on the wp-xmlrpc list to get additional champions to your cause.

Also, providing a link to the discussion on the mailing list doesn't hurt!

Thanks for the initiative and for persevering!

[joehoyle]

thanks for the followup lloyd.

The mailing list discussion is here: ​http://lists.automattic.com/pipermail/wp-xmlrpc/2009-September/000413.html. I will try get some more interest in this ticket via the mailing list.

[joehoyle]

Moved $version out of if statement for clarity

[josephscott]

I generated an updated patch that fixed a typo (missing ;). While I was in there I made some style changes to bring it closer to the WP style. Not a big deal as most of xmlrpc.php has a funky mix of styles any way. Figured this was a good a place as any to start cleaning it up.

This exposes one more piece of data from wp-admin via the XML-RPC API, which is a good thing. I'm fine with adding this, I've changed the milestone to 3.0.

[westi]

I'm 50/50 on including this in core.

I am trying to understand how it fits in with the use of XML-RPC as a publishing interface and what use it has for the majority of end-users.

• Is something like this already provided by one or more plugins?
• What would a consumer of the XML-RPC interface use this for?

I am wary of adding things like this piecemeal - for example if we want to make something like plugin upgrade management available over XML-RPC then we should do the whole thing.

What is the reason this code should be in core and not in a plugin?

[josephscott]

My general goal is to expose all of the same features, data and abilities via external APIs (XML-RPC and AtomPub, though mostly XML-RPC) that you can do via wp-admin. Some of these might be tricky (or not reasonably possible), but we are a fair ways away from having to worry about those.

I'd consider this a first step in providing a plugin management feature via XML-RPC. Perhaps this ticket should be changed to cover providing some plugin management abilities via XML-RPC then.

[joehoyle]

Replying to westi:

I'm 50/50 on including this in core.

I am trying to understand how it fits in with the use of XML-RPC as a publishing interface and what use it has for the majority of end-users.

I guess it depends if you consider XML-RPC to be a publishing interface, or just a way of remotely interfacing with WordPress.

What would a consumer of the XML-RPC interface use this for?

Things like the WordPress iPhone app could show the user what plugins they have activated, and more importantly - what plugins need updating. Currently, the only way to manage a WordPress site is via the Admin, I believe the XML-RPC API should provide all the functionality that the admin can - allowing third party tools to act in place of the admin (just as you can currently do for writing posts etc).

Ideally, providing plugin information is the beginning, going on to allow activating plugins, upgrading plugins etc I think would be great, but thought that was a little bit bold to write a patch for that right now. I guess it depends on the devs general approach to what XML-RPC should allow / what it's purpose is.

[Denis-de-Bernardy]

I'm partially agreeing with Westi here: if we add this, we might as well add the entire thing, i.e. also methods to add/remove plugins, and most importantly to upgrade them.

I like the idea, though. Suggesting we stick to leaving this as plugin material in 3.0, punt the ticket accordingly, and revisit in 3.1 with a tried and tested plugin around.

plugins have a hook to add methods already, right?

[dd32]

Moving to 3.1, This has missed the Feature Freeze.

[dklon]

I had also made some patches recently with a few more functions to expose plugin management (#14236) which was closed because it was a duplicate of this one. Is this ticket considered on hold until 3.1? I would like to submit my patches which round all of this out but if not I can wait.

Sorry but I have not submitted anything before to this project and am still getting my legs.

[nacin]

Replying to dklon:
Is this ticket considered on hold until 3.1? I would like to submit my patches which round all of this out but if not I can wait.

We're not starting 3.1 development until September, but you're welcome to submit a patch for consideration now. We cleared the 3.1 milestone a few weeks ago, that's why this is waiting in "Triage". If you want this to be considered, I would certainly cycle back in a few months. westi is one of the lead developers so he will need some convincing, but we're quite susceptible to well-thought arguments. As josephscott alluded to above, we have to decide on a roadmap and set of goals for XML-RPC.

[dklon]

Replying to nacin: We're not starting 3.1 development until September, but you're welcome to submit a patch for consideration now. We cleared the 3.1 milestone a few weeks ago, that's why this is waiting in "Triage". If you want this to be considered, I would certainly cycle back in a few months. westi is one of the lead developers so he will need some convincing, but we're quite susceptible to well-thought arguments. As josephscott alluded to above, we have to decide on a roadmap and set of goals for XML-RPC.

I will submit the patches that I have then for XML-RPC plugin management here according to the standards and see if they are acceptable. The reason I had made them in the first place was because there was a real-world need for it in an app I was working on. The biggest benefit to having administration functionality within XML-RPC is in allowing third-party applications to utilize it without having to reinvent the wheel.

My own humble recommendation is that XML-RPC eventually have all of that administration functionality exposed the same as the web interface. This would make WP even more flexible in terms of what third-party applications can hook into and use.

[dklon]

XML-RPC plugin functions and get_plugin_data() mod for plugin.php

[joehoyle]

Should this be closed? Seems there is not much interesting in getting it in - perhaps doesn't make so much sense now, as XML-RPC is used for content, and not much else, perhaps when WordPress offers a JSON api it could be done there. I get the impression there is not much motivation to put time into XML-RPC (for obvious reasons)

[markoheijnen]

Closing this since wouldn't really be used and when you need something you can easily build something