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!
Comment | File | Size | Author |
---|---|---|---|
#14 | deploy-uploads.patch | 8.25 KB | longwave |
#12 | upload_deploy.tar_.gz | 2.07 KB | longwave |
#12 | upload_service.tar_.gz | 921 bytes | longwave |
Comments
Comment #1
johngriffin CreditAttribution: johngriffin commentedI 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.
Comment #2
markmainsail CreditAttribution: markmainsail commentedHello. 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!
Comment #3
mcrittenden CreditAttribution: mcrittenden commentedComment #4
stijnbe CreditAttribution: stijnbe commentedA little quick fix is to add this in node_deploy.module on line 188:
Comment #5
mcrittenden CreditAttribution: mcrittenden commentedComment #6
toh CreditAttribution: toh commentedStill 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!
Comment #7
ngstigator CreditAttribution: ngstigator commentedgreat module! confirmed on latest dev version. thanks for all your work :-)
Comment #8
gddChanging this to feature request, since it is not actually a bug (I never attempted to support upload module.)
Comment #9
moropo CreditAttribution: moropo commentedAny 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.
Comment #10
dixon_@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?
Comment #11
thezombieguy CreditAttribution: thezombieguy commentedI 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.
Comment #12
longwaveConfirm 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.
Comment #13
dixon_Would it be possible to get these modules as actual git patches? That way we can test and review them properly.
Comment #14
longwaveComment #15
dixon_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.module
for deploying the actual file.I won't mark this as a beta blocker, but I will definitely come back and work on this later.
Comment #16
dixon_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
Comment #17
kenorb CreditAttribution: kenorb commentedPasting code for easier understanding:
upload_deploy module:
upload_service module:
Comment #18
kenorb CreditAttribution: kenorb commentedCreated sandbox module for the fixes:
https://drupal.org/sandbox/kenorb/2108059
Comment #19
kenorb CreditAttribution: kenorb commented