Posted by inzaghi on May 11, 2009 at 8:23am
| Project: | Deployment |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
When I test deploy module, I found it's not work when enabling upload module.
After I choose a node which is new created and sync it, I get successful message in source server, but content of destination server is not changed.
After researching code, we found the problem should be from line 1025 in include/form.inc:
if (_form_button_was_clicked($form)) { ------------------- (1025 line)
...
...
...
if (isset($form['#submit'])) {
$form_state['submit_handlers'] = $form['#submit'];
}
}
After enabling upload moudle, the value of $form_state['submit_handlers'] will changed from "node_form_submit" to "node_form_submit_build_node", so the synchronized node will not save.
Thanks!
Comments
#1
I can confirm that this is still occuring with the current dev versions of both services 2.x and deploy modules.
My fix is to temporarily disable upload module on the destination.
#2
Hello. I just installed the deploy module but when i try to actually deploy anything I get this error:
Error
category: illegal value.
it appears to have something to do with a text field 'category' that I've created to filter nodes in views?
Is there anything I can do to make this work?
thanks!
#3
#4
A little quick fix is to add this in node_deploy.module on line 188:
//temporary fix for upload moduleunset($node->attach);
#5
#6
Still having issues here with the latest dev release. Unfortunately it's not feasible to temporarily disable the Upload module, and my group is rather update-happy, so a patch isn't exactly do-able for us either. I guess I can only throw my support behind a fix for this in the next dev release.
Thanks for the work on Deployment. It's quite a tool and I'm glad to the project's still actively going strong!
#7
great module! confirmed on latest dev version. thanks for all your work :-)
#8
Changing this to feature request, since it is not actually a bug (I never attempted to support upload module.)
#9
Any change on this subject?
I think that feature request or bug... whatever... it is really important to support upload module.
The concept and implementation of Deployment module is excellent and fulfill the needs of many of us.
#10
@moropo We are supporting the FileField module, as that is a much more widely used approach to uploading. Could that be an alternative to you?
#11
I used the unset($node->attach); suggestion above, but I'm not sure what other effects that might have.
However I disabled file uploads, and used filefield for attaching images/media to my content as well as Insert for inserting media automatically. So far it's a perfect replacement.
#12
Confirm that the fix in #4 works, as far as content types with file attachments enabled actually get deployed instead of failing silently, but attachments themselves are not transferred or attached.
The attached modules extend this further. upload_deploy ensures that file attachments are given UUIDs and are deployed in a similar way to filefields, and upload_service handles saving $node->files on the remote end after the node has been transferred. I couldn't get this working directly during node deployment; new nodes would transfer correctly, but when updating existing nodes, $node->files always ended up empty after drupal_execute()'ing the node form, even if all values (including 'new') were set correctly - this seems to be a limitation of the way the upload element is attached to the node form and Form API's handling of this. This workaround of sending the file list afterwards seems to work.
The fix in #4 is included in upload_deploy but should perhaps be moved to node_deploy so deploy does not fail when upload is enabled but deployment of uploads is not required.
Development of these modules was sponsored by Opsview.
#13
Would it be possible to get these modules as actual git patches? That way we can test and review them properly.
#14
#15
The patch seems to do it's job! Nice! But I'm not totally satisfied with the approach, though. I would like it to use the already existing
file_service.modulefor deploying the actual file.I won't mark this as a beta blocker, but I will definitely come back and work on this later.
#16
To help version 6.x-1.x move forward, please see this issue: #526936: Find best way to proceeding with 6.x-1.x and more specifically this comment: http://drupal.org/node/526936#comment-4931548