Unable to retrieve a list of content types from the remote server

hi there,
looks like it could be a permissions problem to me.
also i dont think the current version supports the use of API keys in the service method calls so you might want to try disabling that in the service settings.

we're actively developing this right now and its nearly ready to upload another release + dev snapshot which has significant changes to it - for example API keys will be supported in the next version.
we'll likely add some documentation to it as soon as possible (when we have time) - probably very shortly after the new year detailing the configuration steps to get it up and running as there is quite a lot of administration to set it all up properly.

@prston

i've added an initial start to some documentation in the form of readme.txt to the module folder as well as some bugfixes and additional updates to the module. e.g. the modules now support the use of API keys and session IDs in the service calls.
the readme should give you a decent starting point on how to setup the configuration for distributing content via your various drupal instances.

Automatically closed -- issue fixed for two weeks with no activity.

I'm experiencing exactly the same thing here, was the original issue ever resolved ?

Part of a bigger test here to see if Drupal can handle working in a web-services environment and using a content network.

Using this as an initial proof and set up; though isn't working atm and seems very dependent on the distribution web-service being Drupal and passing the node ids opposed to being an encapsulated service. If I can get this working the content distributor will likely be changed to a scalable option that manages the whole systems content.

Though here and now just need to sort this out :)

No manner of permissions juggling can shift : "Could not retrieve a list of content types from the remote server " though lots of 403 in the web logs, any ideas what else could be blocking it ?

Thanks
J

@JerryH

Without looking at your setup, i can't really tell what the problem is. I would say, 99% of the time it usually is a permissions problem with the web services not being able to access from retriever > distributor side.
We have it working in our production environment, and it does actually function well. It is however a bit of a nightmare to setup regarding all the admin settings.
Have you also checked - Is your webservice endpoint correct?
Have you set up any content types on the distribution side to be distributable? - in admin/content/types , 'edit'

Ola,

Yup on the distribution side I have a the default story and page and have set them both checked for : "Distribute content of this type".

The server example.com/services/xmlrpc responds with :

XML-RPC server accepts POST requests only.

So thats running.

And is what the reviver is pointed too.

The key is the same on both and the user pass on the client is that of the webservice user name on the distributor.

The view is the default nodequeue_1.

Is there any where that debug can be added to either side, or some kind of log to follow the behavior ?

I just up the receiver on the distributor as well as another test and it can't get the data either atm.

Though the live preview in view/edit returns the data.

cheers for the response :)

@jerry the default view is actually called 'content_distribution_queue' and not nodequeue_1

if you have a look in content_retriever_xmlrpc() function inside content_retriever.module , that's where all the service calls are being made. if you print_r() around the results of them, you will see which one is not returning anything, which should be where your problem lies (ie which service - system, node, views). hope that helps. if you have a look at content_retriever_save_nodes() you should be able to see the order of the service calls.

Cheers, getting closer now.

As it's system.connect, and :

case 'system.connect':
die($method . ' :: ' . $endpoint);

returns :

system.connect :: http://example.com/distributor/services/xmlrpc

and that URL directly :

XML-RPC server accepts POST requests only.

Though the web logs show 403, so I'm guessing it's one of the various Drupal .htacces files blocking something atm.

127.0.0.1 - - [19/May/2009:13:59:49 -0700] "POST /distributor/services/xmlrpc HTTP/1.0" 403 4464 "-" "Drupal (+http://drupal.org/)"

if you're using the shared sign-on module across sites, you might need to, in the settings add the following in the bottom box (target URL) -

\/admin\/reports\/request-test$
\/services\/xmlrpc$

which should allow services access to those URLs cross-domain.

I have the same problem.

I've tried some debugging in content_retriever_admin_types_form():

shows me that the retrieving site connects, but gets an anonymous user only.

Is there a missing obvious step, such as creating a matching user on the retrieving site?

This is definitely a permissions things on the remote (distribution) site: if I give the retriever my UID 1 name and password, then everything works as expected.

However, I've tickied every permission that has 'service' in it!

The flaw is this in distributor_service.module:

elsewhere in the code...

This is pretty much a WTF: a function whose sole purpose is to return what user_access() returns? And does an if check on it to boot? And gets a global $user for no reason?
No, no, a thousand times no.

Replace that line with this:

and all works as expected. There is a reason why hook_service (and other hooks like this) have user_access as a default: in most cases it suffices!

EDIT: Though further investigation shows that distributor_service_get_access() just doesn't get called at all -- a bug in services module perhaps? Anyway, one that needn't bother us here, and we get simpler code too!