I am not sure if this is a bug in deploy or in nodewords, but if I enable "Nodewords - basic meta tags" of the nodewords module, then a node deployment fails with the following error on the source:

"An illegal choice has been detected. Please contact the site administrator."

On the destination, the watchdog log has the following error:

Type		form
Date		xxxx
User		admin
Location	http://mysite.com/services/xmlrpc
Referrer	
Message	Illegal choice 0 in Robots element.
Severity	error

I tried changing the <robots> tag in the site settings and it didn't work.. You have to disable the basic metatags before doing the upload.

Comments

teastburn85’s picture

Bumping this issue. I got the same error and same resolution. I would love to be able to deploy nodewords along with a node.

Running:
Drupal 6.15 (soon to be 6.16)
Ubuntu 9.10 Karmic Koala
PHP 5.2.10 (with suhosin path)
Deploy module 6.x-1.x-dev
Nodewords 6.x-1.12-beta3

teastburn85’s picture

Could someone point me in the right direction of how to resolve this? Would it be similar to how taxonomy is handled, e.g. with taxonomy_deploy.module and such? Any help is appreciated.

Thanks

pavel.karoukin’s picture

basically - FormAPI on destination end checks for correct values for some node_form field and this value either not sent correctly or not sent at all, but required.

So you need to do one of this:
1) Provide correct node_form structure, submitted via xmlrpc to destination with correct field for Robots.
2) "Fix" (or remove, or something) this field on the destination when deployment works.

Both are non trivial and require some debugging on both ends, and this is hard, since servers communicating directly, not trough browser.

Probably this patch will give you any ideas how to deal with that - http://drupal.org/files/issues/filefield_deploy.module.patch - basically I had to disable autoconversion of already converted videos.

Sorry, can't help with anything ready right now. If you will find how to solve this I bet community will appreciate patch =)

teastburn85’s picture

Status: Active » Patch (to be ported)
StatusFileSize
new730 bytes

OK, I've run down the problem, and found a temporary solution to it. The problem is indeed as hippich noted.

Fix #1 he mentioned would require adding to the node_form structure a field that (afaik) is not used and would be extraneous.
Fix #2 (the route I took for a quick fix) removes the problem after it has already occurred but before it causes a failure.

A real fix, however, will ensure the problem does not occur in the first place.

THE PATCH (easy fix):
I almost don't want to share the patch, since it's a TOTAL HACK and this bug should be fixed at the source of it's occurrence. However, I haven't found that source and I am on a time constraint, so this will have to do for now. As of 4/21/2010, this patch has only been tested by 1 person on 1 machine set up. I have tested single article deployment and deploying a plan of different content types. Apply patch from the modules/deploy folder.

THE PROBLEM (harder fix):
For anyone interested in fixing the real bug before I get the time (if I get the time) to do it. I think the Form API adds an item to the 0 index of the Robots form field values. This happens in includes/form.inc:form_type_checkboxes_value:~1216-17 which is between the form being submitted and getting sent to the destination server. Then, when the info gets validated on the destination server, it barfs on the 0 index because it was not declared as an option for the Robots field. However, changing line 1216 to be "as $key => $val" breaks other things. So maybe it's a matter of declaring the Robots form elements properly?

Below is a print_r snippet of what the destination server gets sent when deploying a single node (when only the "noydir" and "Use default" Robots checkboxes are ticked).

[values] => Array
(
	[nid] => 3879
	[title] => My cool new dev blog entry
	...
	[nodewords] => Array
		(
			...
			[robots] => Array
				(
					[value] => Array
						(
							[noydir] => 1
							[0] => 1
							[noarchive] => 
							[nofollow] => 
							[noindex] => 
							[noodp] => 
							[nosnippet] => 
						)
					[use_default] => 1
				)
			...
		)
	...
)

As you can see, the 0 index item causes validation on the remote server to fail. All my patch does is simply remove the 0 index item if it exists before sending.

Thanks to hippich for pointing me in this direction!

gdd’s picture

Note that both the Nodewords and File problems center around the fact that CCK checkboxes are broken. I had to add a hack for this for user deployment with the authenticated role as well. I don't have an answer, I'm just pointing it out.

jaxpax’s picture

I'm experience the same problem with nodewords and posted a duplicate issue: #780900: Error when deploying Page and Story content

teastburn85’s picture

Just wanted to share a new approach I've taken that requires no module hacks or patches. Still doesn't fix the problem at the source though, which is (as heyrocker said) the CCK checkboxes grabbing the wrong values.

This approach adds a module hook for node_deploy. You'll have to add any checkbox fields you may have by hand to the switch statement or afterward. My "image" and "blog" node types have checkboxes to choose categories they should belong to. The categories are referenced by node IDs (whereas robots is boolean and doesn't require an ID), so we pass in true as the second param to mymodule_fix_cck_checkboxes to set the array values to the corresponding node IDs (which is the array key).

/**
 * Implements hook_node_deploy
 *
 * Edit a node before it gets sent off. This is mostly to fix CCK checkbox faults.
 * @param object $node A reference to the node that will be deployed
 * @return $node The edited version
 */
function mymodule_custom_node_deploy(&$node) {
  switch ($node->type) {
    case 'image':
      // fix categories checkboxes
      mymodule_fix_cck_checkboxes($node->field_image_blognames['value'], true);
      break;
    case 'blog':
      // fix categories checkboxes
      mymodule_fix_cck_checkboxes($node->field_blog_categories['value'], true);
      break;
    default:

      break;
  }

  //always fix robots
  mymodule_fix_cck_checkboxes($node->nodewords['robots']['value']);

  return $node;
}

/**
 * A helper function to fix CCK checkbox arrays.
 * If a 0 index is set in the array, it will get unset. It optionally sets IDs to
 * be values of the array as well in cases where code needs the ID but just gets
 * 1 or true.
 * @param array $aCheckboxValues The "value" array for the checkboxes set.
 * E.g. $node->nodewords['robots']['value']
 * @param boolean $bSetIdToVal If set to true, all values that evaluate to True
 * will be re-set to match the key. This fixes most taxonomy checkbox problems.
 * @return array The fixed array
 */
function mymodule_fix_cck_checkboxes(&$aCheckboxValues, $bSetIdToVal = false) {
  if (isset($aCheckboxValues[0])) {
    unset($aCheckboxValues[0]);
  }
  if ($bSetIdToVal) {
    foreach ($aCheckboxValues as $key => &$isChecked) {
      if ($isChecked) {
	$isChecked = $key;
      }
    }
  }
  return $aCheckboxValues;
}

Hope this helps

Andrey Zakharov’s picture

StatusFileSize
new1.05 KB

Here code above just as module ready to use.
Helps me! Thanx!

johannesdr’s picture

I have the same problem.
Both the patch in #4 as the fix module in #8 work. But I have spend some time tracking down the source of the problem.

In node_deploy.module the robots array is still ok after node_load() on line 102

[robots] => Array ( [value] => Array ( [noarchive] => 0 [nofollow] => 0 [noindex] => 0 [noodp] => 0 [nosnippet] => 0 [noydir] => 0 ) [use_default] => 0 )

but then after $node = (object) $form_state['values'] on line 162 we get

[robots] => Array ( [value] => Array ( [0] => 1 [noarchive] => [nofollow] => [noindex] => [noodp] => [nosnippet] => [noydir] => ) [use_default] => )

Like teastburn85 suggested in #4 it is the form API that adds the extra 0 index.
So it is not really a bug in the deployment module, but in the forms API.
I found 2 related bug reports with the same problem:
http://drupal.org/node/297451
http://drupal.org/node/508362

gdd’s picture

So seeing as this is not an issue in Deploy, and there are workarounds above that I don't think really fit as fixes, I'm going to won't fix this. However thanks everyone for their work on it, and hopefully this will help some folks in the future.

gdd’s picture

Status: Patch (to be ported) » Closed (won't fix)