I'm working on a site with an unusual workflow. Content is created/edited on one Drupal site ("Management"), and is then published one of several other Drupal sites ("Target") via xmlrpc.

On the "Management" install, we have a custom field to hold a Scheduled Publishing Date which the publishing template for the xmlrpc part can manipulate into any format we need.

No matter how I try to schedule an article on the "Target" site, nothing gets passed.

For most other fields what works is:
$forms[0]['form_state']['values']['field_something']['und'][0]['value'] = $node->field_something['und'][0]['value'];
or
$forms[0]['form_state']['values']['promote'] = $node->promote;

This is what I've tried for the Scheduler:
$forms[0]['form_state']['values']['publish_on'] = strtotime($time_field)

I've also tried adjusting our xmlrpc processor to assign a value to $node->publish_on based on what I see in the module file, but have had no luck.

Has anyone had experience with anything like this, and if so what have I done wrong?
Is what I'm trying to do even possible?

Thanks for your time!

CommentFileSizeAuthor
#4 form_state.txt9.76 KBNels
#4 form.txt11.29 KBNels
#4 sample_form.txt11.29 KBNels
#4 sample-processing-node.txt1.32 KBNels
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Nels’s picture

Issue summary: View changes

To clarify, perhaps:
Each item in $forms is then passed to the Target site via xmlrpc(), the receiving site then performs

$node = (object) NULL;
$node->type = $form['type'];
drupal_form_submit($form_id, $form_state, (object)$node);

The $form_id (in a specific case it is "article_node_form") and $form_state being derived from what is passed in with $forms.

I'm a bit stuck with including Scheduler publish dates, but every other aspect of publishing is working so I may just add a field to the article type for the publishing date and use Rules.

Nels’s picture

Priority: Normal » Minor
Status: Active » Postponed
jonathan1055’s picture

Status: Postponed » Active

Hi Nels,
That is an interesting situation, and I'm sure we can work out how to get the Scheduler part working for you. Just a few questions to make sure I understand what you need:

  1. I presume you only want to use Scheduler on the target site, and that on the management site the nodes are always published.
  2. What exactly is the outcome you get? Is it just that no publish_on date is stored when the target node is saved, or are there any errors which are going untrapped behind the scenes?
  3. In the code in #1 it looks like you have access to both $form and $form_state. Are these the regular values we are familiar with during normal node edit process?
  4. You also talk about $forms plural. Is this a collection of many node forms? How does it relate to the $form on the target site?
  5. Could you post an example dump of $form and $form_state (in an attachment if they are large) so that I can try to replicate what you are doing.

That's enough to get started. Thanks for your interest in Scheduler.

Nels’s picture

FileSize
1.32 KB
11.29 KB
11.29 KB
9.76 KB

Hi Jonathan,

I ended up using a Date field and Rules to accomplish what I needed at the moment, but I'll try to answer your questions as best I can.

1.) Yes, I was trying to use Scheduler on the Target site, but the "published" status on the Management site is inconsequential and could always be published

2.) Yes, no publish_on date was being stored when and article was published/pushed from the Management site to the Target site. There didn't seem to be any errors in the php logs or site logs.

3.) Yes, "we" try to be as drupal-ish as possible, so $form and $form_state are what you would expect.

4.) Great eye. The Management site can "bulk-publish" articles to the Target site. $forms is just a collection of individual $form elements (one per article). The Target site then handles each $form as it's own item to create a node from..

5.) I've attached some files. sample_form.txt is the $form that is passed via xml (one of potentially multiple items in $forms). form.txt and form_state.txt is what is passed to drupal_form_submit. I've also attached the function that processes each $form item.

As I mentioned, I found a work-around using a Date field and Rules. This may be sort of an edge case, but thanks for your time!
N

jonathan1055’s picture

Status: Active » Closed (works as designed)

Hi Nels,
Sorry I did not get round to replying. This was an interesting problem and we should have been able to solve it, but I guess when you said you had a work-around I must have put this issue in the 'look at later as the user is OK for now' category, and then just left it there! Good that you can use Rules.

Closing it now, to keep the queue tidy. It would be nice for support issues to have a better 'closed' status to choose, as none of the given statuses really apply.

Jonathan