no new nodes when there are new nodes
| Project: | Content Distribution |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Hi,
First off, this is a great module if I can get it working! Now to the issue I'm having. I have the server/slave connection working in that on the slave side, I can see the correct contenttype and nodequeue on the server.
When I create new content and add it into the nodequeue on the server side and then content retrieval on the slave side, I'm getting the message that "There are no new nodes to retrieve. Process complete." I've haven't yet been able to get any nodes retrieved. I have tried changing the date back in time but this does nothing. I am using API but have tried with and without. Session ID is checked on both sides and I increased the session time to 120 but keeping it at 30 didn't make a difference.
Permissions appear fine. I've added the correct permissions for the anonymous user on the server side as specified in previous posts. When I run the content retrieval, in the log on the server side, I get the message that the session was opened for the specified account and then closed. There are no other messages. On the slave side, there are no messages in the log.
I'm running services 0.13, CC 1.1, nodequeue 2.0 and using the latest nodequeue_service module listed here: http://drupal.org/node/310177#comment-1019252.
I also created a specific contenttype for testing purposes which does not have any CCK fields attached to it to keep things simple. contentdistributor is only enabled on the server and contentretriever only on the slave. I haven't tried any of the dev versions of the specified modules.
Any thoughts?
thx, Aaron
#1
hi Aaron, i'm using the same versions of the module as you, it seems like you have set everything up correctly. one thing i checked which is different is a have patched views_service.inc to be slightly different, the function i have changed is views_service_get_access() to -
/**
* Check the access permission to a given views.
*
* @param $view_name
* String. The views name.
* @param $display_id
* String. The display name. (optional)
* @return
* Boolean. TRUE if the user is allowed to load the given view.
*/
function views_service_get_access($view_name, $display_id = 'default') {
$view = views_get_view($view_name);
if (empty($view)) {
return FALSE;
}
global $user;
return TRUE;
//return $view->access($display_id);
}
i have a backlog to update the content_distributor module to work with the latest version of the services module, which should not require this small patch, which i havent got round to yet, but try this and see if it helps you out for now.
#2
Hi
Thanks for the checking on that. I gave it a shot updating that file with your mods but there's no difference. I'll wait until you get the another version out and then give it another go on those versions as its not pressing to use this module at the moment. thanks again!
Aaron
#3
actually one other thing to add after reading one of the other issues in the queue. On the distribution site, when I run views.get from the services page and input the content_distribution_queue viewname and a list of arguments (1/nodetypename/20090101), I don't get any results coming back to me. But if I go directly to this view (distribution/1/nodetypename/20090101) , I see my content thats in the nodequeue.
Not sure if that helps with trying to figure out what may be happening, as I assume that I should see something when running views.get. If I put in the name of other views, I do see results.
thanks,
Aaron
#4
@aswalla
think you are querying the view wrongly, it requires a time as well as a date, so the query would actually be -
distribution/1/nodetypename/200901011200
in the admin/build/services/browse/views.get - the parameters would be
view name: distribution
display id : default
args : 1, nodetypename, 200901011200
#5
okay thanks, that makes sense for what to put in there to get it to run correctly. The response I get back this time is: Array ( )
So the array is empty for some reason.
What is interesting though is that when I look at the view, it doesn't seem to require the hour to display the same nodes in the queue:
http://mysite.org/nodequeue/distribution/2/example/20090101
http://mysite.org/nodequeue/distribution/2/example/200901011200
I'm perhaps totally off but maybe its some some weird conflict with the date module version i'm using but I'm wondering which one you are using? I'm using 2.1.
#6
hi aswalla,
i'm using 6.x-2.0-rc6, haven't tested with 2.1 yet.
i need to upgrade all my modules soon, and re-test this module with all latest versions (i know there is some new things in the services next release out which will require some changes here) and then release a new version of this module.
#7
hi tayzlor - sounds good! Will be happy to test out dev versions.
#8
The Retriever site seems to have all the right view parameters.
However, an empty array is still coming back.
So on the Distributor site, I added this to views_service_get():
file_put_contents('DEBUG', print_r($view, 1));file_put_contents('DEBUG-NODES', print_r($nodes, 1));
This shows that $nodes is indeed empty.
The reason is probably this in the debug dump of $view:
[pager] => Array
(
[use_pager] =>
[items_per_page] => 0
[element] => 0
[offset] => Array
(
// THESE are my view arguments! How did they end up in the pager array?????
[0] => 1
[1] => sponsors
[2] => 197001010033
)
[current_page] => 0
)
#9
This, with clearer formatting, is how the Retriever is calling the xmlrpc method:
$result = xmlrpc($endpoint, $method, $session_id,(string) $param1, // $param1 is view name
'default', // 'default' is display_id parameter hardcoded to default.
array(),
(array) $param2, // $param2 is array of view arguments
0, // offset
0 // limit
);
and these are the params for the views service:
* @param $view_name* String. The views name.
* @param $fields
* Array (optional). Array of fields to return.
* @param $args
* Array (optional). Array of args to pass to the view.
* @param $offset
* Array (optional). Offset record to start from.
* @param $limit
* Array (optional). Max number of records to return.
Display is not there.
This was removed from Services in Feb 2009: http://drupalcode.org/viewvc/drupal/contributions/modules/services/servi...
The change is on the DRUPAL-6--1 prior to branching for DRUPAL-6--2 -- in other words, there is no release out there compatible with our current code, so we should change it on our 6--1 branch too.
#10
Arg.
Services 6--2 was updated yesterday.
With the fresh code:
* @param $view_name* String. The views name.
* @param $display_id
* String (optional). The display name.
* @param $offset
* Integer (optional). An offset integer for paging.
* @param $limit
* Integer (optional). A limit integer for paging.
* @param $args
* Array (optional). A list of arguments.
* @param format_output
* Boolean (optional). TRUE if view should be formatted using the defined
* style plugin.
so there still is fixing to be done on our end.
In most circumstances it might be a good idea to start a 6--2 branch to work in tandem with the same branch name on Services, but I want a new branch to work on new stuff here too.... :/
#11
Got the view to work.
Now I'm not managing to get ANYTHING with node.get.
#12
This fixes the view:
- //$param1 is view name, $param2 is array of view arguments- //'default' is display_id parameter hardcoded to default.
- $result = xmlrpc($endpoint, $method, $session_id, (string) $param1, 'default', array(), (array) $param2, 0, 0);
+ $result = xmlrpc($endpoint, $method, $session_id,
+ (string) $param1, // $param1 is view name
+ 'default', // 'default' is display_id parameter hardcoded to default.
+ (array) $param2, // $param2 is array of view arguments
+ 0, // offset
+ 0 // limit
+ // format_output which we're not passing at all.
+ );
} else {
//var_dump($endpoint, $method, $hash, $domain, $timestamp, $nonce, $session_id, $param1, $param2);
- $result = xmlrpc($endpoint, $method, $hash, $domain, $timestamp, $nonce, $session_id, (string) $param1, 'default', array(), (array) $param2, 0, 0);
+ $result = xmlrpc($endpoint, $method, $hash, $domain, $timestamp, $nonce, $session_id,
+ (string) $param1, // $param1 is view name
+ 'default', // 'default' is display_id parameter hardcoded to default.
+ (array) $param2, // $param2 is array of view arguments
+ 0, // offset
+ 0 // limit
+ // format_output which we're not passing at all.
+ );
Will patch properly later.
Note that this change will mean we are working with Services 6.x-2.x rather than 1.x.
#13
... and now it works.
This services stuff is all very frustrating, and the amount of hoop jumping just to make a call... *sigh*
#14
I'm committing this patch and calling this fixed; I'm not sure if this fixes the OP's problem as that was ages ago.
If not, reopen.
#15
Automatically closed -- issue fixed for 2 weeks with no activity.