Drop the blog API from core

I think people use it. But they don't contribute much, as this is always the last module to get its critical issues fixed up before released. It also has had more than its share of security patches. I'm quite fine with letting this grow or decay in contrib. Evolution!

I'm ok with this. Damien McKenna already started http://drupal.org/project/blogapi_new in contrib to try and get the D6 version up to speed. This module is in a situation where it'd likely be better off in contrib anyway with changing standards and clients and whatnot.

I've marked RTBC, but this decision needs to be made by Dries, methinks.

Oh. wait. There's a MAINTAINERS.txt hunk too. ;) Best to mention in CHANGELOG.txt as well.

I guess that last patch was mixed with something else.

I support that.

I'd also like to see this go. We have test coverage of hook_xmlrpc() in modules/simpletest/tests/xmlrpc_test.module now.

This would also allow us to revert the taxonomy hunks from #474072: Use taxonomy_load functions in blogapi.module which are going to be one of the harder things to convert in #412518: Convert taxonomy_node_* related code to use field API + upgrade path.

Subscribe. I'd like to see this happen, too.

why is status "failed to apply patch"? can't really rtbc until we fix that.

blogapi files have been modified by http://drupal.org/cvs?commit=252190, so probably needs a reroll :-)

Tagging.

I'm against the removal of Blog API from Drupal core as it's the one core method to allow external services to interact with Drupal. However, I am in support of revamping Blog API with a Services-like interface. If we abstract the Blog API methodology into a external data services API, then we would gain the ability to also retrieve other data in many different formats (XML-RPC, JSON, REST, etc).

Nedjo started a discussion on this a long time ago in a galaxy far far away: #145551: Enable loading and rendering into multiple formats (html, xml, json, atom, etc.).

+1 for removal. Rob, maybe removing it will inspire more activity for getting an external data services API.

The current (awkward) BlogAPI allows only a very limited interaction with Drupal. We try to emulate some CMSes that are incongruent with how Drupal works. A an example; there's no way to associate files uploaded via the blogapi with a post.

Another issue with BlogAPI is that it is quite undermaintained. To paraphrase DamZ: I wouldn't trust it to watch my food. We either need to ditch it, or commit to make it sound and secure.

I've never, ever used it. The only time I've ever dealt BlogAPI was due to sec issues or test failures.

Re-upload of last patch. No changes.

I support this as well. Committed.

So is there a new module for the removed Blog_API module?

oopsie!

DamienMcKenna's module was referred as the alternative implementation, but apparently, he doesn't know and didn't expect and didn't intend to and ... what wuhuh? What about Drupal users? :)

(Note: I'm re-opening this issue after someone asked in IRC about the proper drop-in replacement for D7 ;)

subscribe

pushed the button without reading then it closed so i reopened :)

im not sure about what i would like
i think that it can be fine to keep the module in core but in the same time, i think that the "services" module is better and can be used for people needed this functionnality
so the best would be to integrate the services module in core but i think that its too late for that in d7

So, now we have xmlrpc.php, includes/xmlrpc.inc and includes/xmlrpcs.inc, along with its hook, that are being used by absolutely nothing in Drupal core. If we removed the Blog API, then we should also remove those.

If we were to bring back the Blogger API correctly into Drupal core, we would:

1. Bring in something like the Services API, which abstracts the communication layer between the server and its clients
2. Introduce a new XML-RPC library with an interface for this new Services API
3. Re-implement the Blogger API using this abstracted communication layer

I see no reason to remove perfectly fine XML-RPC handling from core just because core isn't making use of it. Core doesn't make use of lots of things (such as node-level access control), but we still provide them as part of the framework.

If/when Services moves into D8, then we would of course remove our custom XML-RPC handling in favour of something pluggable. But IMO this move would just make Drupal less flexible out of the box, as opposed to removing a little-used, effectively abandoned module with a broken implementation.

I do not support the removal of XML-RPC either. Given that webchick already voted against this and I am the former maintainer of XML-RPC I do not think we need to wait for Dries to say no.

So, is there a dedicated drop-in replacement for Drupal users? Not sure whether Services module counts, but we should at least have a handbook page about this.

There's http://drupal.org/project/blogapi_new but it seems the maintainer didn't volunteer to be the new point of contact for all blogapi users.

re #34: Many of us saw no reason to remove a perfectly usable API from core either, but it was still removed :-P

Given that blogapi has already been removed from core, as the maintainer for blogapi_new I'd like to move this to a new module just named "blogapi" to clearly indicate this is the extracted core module. At that point I'd then scrap the blogapi_new module and focus efforts on blogapi, add additional maintainers, draw up some concrete plans, etc. Is there a way to rename modules - we can scrap everything that's currently in CVS, or what is the best approach?

Starting a new project at blogapi ought to work fine for this, renaming a project in cvs is very hard and requires db access as far as I know.

Anyone know what contrib modules use xmlrpc.php? The issue to port Blog API Improved is at #559088: Drupal 7 small core effort has removed Blog API, merge this with the moved-to-contrib Blog API.

If we aren't removing this unused feature in core, then let's move this issue over to Drupal 8. An abstracted communication layer is still a much needed feature. All those JSON menu callbacks, XML outputting, they'd all gain huge benefit from this.

Thanks David, re-purposing the issue wasn't the right way to go. Just, looking back at your original question and the original intent of the issue: "Does anyone actually use this?". Now that Blog API is out, does anyone actually use the XML-RPC library? The answer is no. The timeline is too short to do this with Drupal 7, but makes complete sense in Drupal 8. Thanks a lot!

I think sun made a good point in #35 though, we need some handbook upgrade documentation pointing people to a Blogger API implementation for Drupal 7.

Mollom for one uses the XML-RPC API.

.

rather create a generic api to handle content, including custom content field. Also keep it simple!

Like:
$content = new Drupal_Content();
$content->insert(array('title' => 'my awesome title', 'body' => 'my amazing body', 'image' => 'someprettypicture.jpg')); // returns true if success
$content->save(); // returns id of node

$content->update(array('title' => 'my new title'), 42); // returns true if success
$content->save(); // returns id of node

$content->delete(42); // returns true if delete was success

mmmmhm generic api goodness

Per #35 and #42 and a look at the converting 6.x to 7.x page it looks like this issue is still in need of documentation.

Added docs to http://drupal.org/node/727352

Pushed #727680: Remove XML-RPC from core to Drupal 8.

FWIW, some or my contrib modules use XML-RPC, and most sites I've worked on rely on it critically (which is why I introduced hook_xmlrpc_alter() in the first place: it was really missing for practical cases).

Sorry to re-open this, docs added by sun in #49 now go to access denied: http://drupal.org/node/727352

I think we should not remove documentation pagesin general, but at any rate in this case i think there's wide agreement to document features removed from one version to the next. And i cannot find that documentation (for BlogAPI at least).

http://drupal.org/project/blogapi is funded and appears in progress so we do have something to link to, question is where.

The issue about missing documentation #1435192: Write documentation