Posted by bamirzada on July 22, 2009 at 1:16am
Jump to:
| Project: | Deployment |
| Version: | 6.x-1.x-dev |
| Component: | deploy.module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
When deploying an existing or new node, my source server states the result = success. Everything seems to go fine.
However, when I go to the destination server, the changes do not exist.
If I look at the dblog of the destination server, I see:
cache clear service 07/21/2009 - 18:09 caches cleared admin
user 07/21/2009 - 18:09 Session opened for admin. admin
There is no indication of a deploy and no sign of the deployed nodes on the destination server.
Comments
#1
I can report the same issue, using the latest dev versions of deploy and services. Setup as per the docs.
I also get the same messages in dblog on the receiving end.
#2
I am experiencing the same, using the latest dev versions of deploy and services. I had some differenced between the content types and filters available on the two Drupal servers that may have caused the problem. It's happening intermittently so it's hard to describe exactly how to replicate the issue, sorry I can't give more detailed information.
#3
Did anyone figure out the problem or get help? It would be nice to have a solution posted for future reference.
#4
In my case, this was solved by checking the path of the destination server that is setup on the source server (http://drupal.org/node/408774 Source Server Step 5). I only had http://www.mydomain.com. It needed to be http://www.mydomain.com/services/xmlrpc as indicated in the link and INSTALL.TXT.
What I am surprised is that there was no error message and the Deployment Log indicated success.
#5
i have the same issue:
originally the node i was trying to deploy had an author with uid != 1 and i would get the send failing (with debugger it is because it does not get uuid key successfully so thinks it needs to create a new user; which it can't do since that user does already exist so it fails).
when i change author to uid = 1, i now get what is described here - i now see success msg; but nothing is created on the remote site.
#6
a bit more debugging and i see that i successfully hit the line in node_service.inc:
$ret = drupal_execute($edit['type'] .'_node_form', $form_state, (object)$edit);but $ret is null.
also, there are no form_get_errors() from this and nothing in watchdog (remote)
will debug into drupal_execute to try to see where this has failed.
#7
You may want to look here to see if you are encountering a common problem
http://drupal.org/node/679604
#8
at the end of drupal_execute() (i.e. the end of node.save method that should be creating the new node on the remote site) is this code:
// If no submit handlers have populated the $form_state['storage']// bundle, and the $form_state['rebuild'] flag has not been set,
// we're finished and should redirect to a new destination page
// if one has been set (and a fresh, unpopulated copy of the form
// if one hasn't). If the form was called by drupal_execute(),
// however, we'll skip this and let the calling function examine
// the resulting $form_state bundle itself.
if (!$form['#programmed'] && empty($form_state['rebuild']) && empty($form_state['storage'])) {
drupal_redirect_form($form, $form_state['redirect']);
}
and the redirect is skipped - so drupal_execute effectively doesn't do anything.
#9
hey heyrocker, re: #7, took a look - nope; none of those issues
also, forget comment #8... failure occurs a few lines before that
not sure exactly what the issue is but i can do deploy on a vanilla site so comparing the differences as both run through the code.
in drupal_process_form() when the code:
form_execute_handlers('submit', $form, $form_state);
is hit and the handlers are run; the working site handler is node_form_submit whereas the busted site has its handler as node_form_submit_build_node
i'll continue debugging but i can see that path with node_form_submit ends up hitting node_save whereas that doesn't get hit with the _build_node handler.
but... not sure where/what sets the handler
#10
Having the same issue, subscribing.
I also noticed that if a push a newly created node, then it will get deployed to the remote site fine. But if I edit that node and push it again, I will receive a 'Success' from the deployment log but no changes on the remote site.
Maybe the services module is having problems with updating a node?
#11
I think I found the problem, in node_deploy.module line 94:
<?phpif ($node->changed <= $remote_key['changed']) {
return $remote_key['nid'];
}
?>
This code always fails (when updating) and returns, hence making the update of that node successful. The problem is the that the 'changed' timestamp is not being saved properly to the remote server.
Temporary fix:
<?php/*
if ($node->changed <= $remote_key['changed']) {
return $remote_key['nid'];
}
*/
$node->changed = 9999999999;
?>
This works for now, obviously not a very good fix, but I need something asap.
Cheers,
JPL
#12
I am having the same problems in Drupal 6.14. I cannot remember I have ever deployed a node in the last few months when I of and on tried different aspects of Drupal, including deploy. But all of the time, after a push everything lists as success (even when posting to /xmlrpc.php instead of /services/xmlrpc). The only correct error message I have seen is when having incorrect credentials and then only at /services/xmlrpc.
This occurs while deploying nodes from the content-overview, and when using a deployment plan.
Taxonomies I have been able to deploy correctly. But when trying to deploy a Forum, the target server gets a duplicate Forum vocabulary, the local vocabulary remains unchanged and the Forum configuration is not deployed.
Subscribing here, this could be a great feature but it hasn't taken me anywhere yet. I will need to reconsider other *unix/web distribution schemes for content again (ie. hope Atom gets somewhere, XMLRPC blog-apis are fine for any content-type too, etc. But its the CMS settings that get tedious..).
#13
Similar issue here: http://drupal.org/node/709732
I resolved by enabling clean urls on the receiving server.
Is anyone having any recent problems (with latest versions of services and deploy) even when clean-url enabled? I'd like to isolate whether that is a factor, of if that just applied to my solitary case.
#14
I am experiencing the same as the initial issue report above, and I have clean URL's enabled in both ends.
I'm having a replicate environment with exactly same content types, but added a couple of cck text fields and image fields on the source server. Later I updated the title and body content and added new content through the newly added cck fields.
The title and body was updated on the destination server but nothing of the new content was deployed through the newly added cck fields. A success was reported on the source server and on the destination dblog:
system service 04/29/2010 - 13:49 caches cleared Admin
Details
Type system service
Date Thursday, April 29, 2010 - 14:26
User Admin
Location http://www.examplel.com/services/xmlrpc
Referrer
Message caches cleared
Severity notice
#15
Is there any new news on a fix? Because its a few days later from the last post and i have the same problems as you guys.
Bytheway awesome module this deployment and services to.
#16
do you have the same content types on de destination server as are on the source server?
I had the same problem (deploy ok, but no content appeared), but when I manually added the content types to the destination server it all went fine.
note on the content types:
I thought Deploy was able to deploy content types automatically.
Maybe I'm doing something wrong.
I have 'Deploy Content Type' enabled on both servers, and enabled all services on the destination server, accept for the Search, Menu and System Settings Services.
using 6.x-1.x-dev 2010-May-24
#17
I have the same content types, but in my case that is not enough, each field have to have a value, entered manually by me, before it respond to any changes from the destination server.
#18
liquidcms: any updates on this? I'm currently running into the same problem as you mention here. Any help would be much appreciated.
#19
Hi there - I'm facing this issue as well. The source server states success, but the destination server doesn't have the (new) content in the content list. I'm trying to deploy a Webform-type node, so not sure if that is causing issues.
When I try the workaround in #11...it does not work. One notable part about my configuration is that there is a basic auth password on the site. I have tried to get around this by writing the URL as http://user:pass@www.example.com/services/xmlrpc - but I wonder if this is only effective for the first action (authentication) and then it reverts to the site as usual for the second one (node creation), but since it got to the site it reports success?
Maybe I need to somehow make /services/xmlrpc "Satisfy All" ... but it's not a real path, so I'm not really sure how to go about that. If I put it in the root directory, well, then it's going to defeat the purpose of having a password on the site in the first place! But maybe I can specify directives by way of request URIs...I'll have to look into that on the Apache help site.
Has anybody else managed to deploy to password-protected sites? I suppose I could temporarily satisfy the password to see if that fixed it...to isolate the issue. Yeah, I guess I'll do that and report back, probably not today though.
Kevin
#20
Same behavior when I remove the authentication requirement on the remote site.
I noticed this message gets added to the local recent log entries whenever I try to do it:
stdClass Object ( [nid] => [vid] => 10 [uid] => 1 [created] => 1279781636 [type] => page [language] => en [changed] => 1279781636 [title] => Deploy Test [teaser_include] => 1 [body] =>
testing deploy
[format] => 1 [revision] => [log] => [name] => admin [date] => 2010-07-21 23:53:56 -0700 [status] => 1 [promote] => 0 [sticky] => 0 [submit] => Save [preview] => Preview [delete] => Delete [preview_changes] => Preview changes [form_token] => 8a104f807df15396890ff7ff88bfdcb5 [form_id] => page_node_form [uuid] => 15649396144c47eb049c6357.9029878 [print_display] => 1 [print_display_comment] => 0 [print_display_urllist] => 1 [print_mail_display] => 1 [print_mail_display_comment] => 0 [print_mail_display_urllist] => 1 [print_pdf_display] => 1 [print_pdf_display_comment] => 0 [print_pdf_display_urllist] => 1 [comment] => 0 [menu] => Array ( [mlid] => 0 [module] => menu [hidden] => 0 [has_children] => 0 [customized] => 0 [options] => Array ( ) [expanded] => 0 [parent_depth_limit] => 8 [link_title] => [parent] => primary-links:0 [weight] => 0 ) [path] => deploy-test [pid] => 34 [pathauto_perform_alias] => 1 [old_alias] => deploy-test [upload] => [attach] => Attach [old_parent] => 0 [parent] => 0 [nodehierarchy_create_menu] => [nh_children_view] => 0 [deploy] => 1 )
Not sure if there is perhaps something malformed in there...but it's certainly hard to track down.
I'll just stick to Node Export for now and monitor this issue.
Thanks,
Kevin
#21
Is the node_uuid field used when deploying nodes? So like if it doesn't exist on the destination server, does it try to create it or does it just fail? I was having some issues, and I think lots of my LOCAL nodes don't have UUIDs. Does that mean that they are un-deployable, or would Deploy give me an error (or try to fix the problem) prior to sending them?
#22
When Deploy is installed it should create UUIDs for any existing nodes, and when a new node is inserted it should also add a UUID for that node. It is possible you may have some messed up UUIDs owing to the node_clone issues you're having in the other issue. If a node has no UUID I am unsure what exactly happens. Ideally it wouldn't even try to deploy them, but regardless its not cool.
#23
Makes sense. Do you think there is value in a maintenance routine for this? Maybe something on the settings page that can go through and basically do what the install process does but leaving alone those that already have one. Or do you think it's such a rare issue that I should just write one for my own needs and not bother contributing back?
#24
Subscribing ... I'm having some of the same issues as others have listed here.
I followed the install directions, "Instructions for Installing Using an Existing Drupal Site." However, I did not make a copy of my staging DB and move to production, as the two sites already have a number of minor differences between them (my goal before starting this was to move down the production DB to staging, but there are too many things waiting approval on staging to do this).
When I run a deploy for a single new node (content type = page), the staging log says it works, and on the production log, I see the login and the cache clear. However, nothing actually happens.
I'm looking in both DBs, and I see the node_uuid tables exist and have values. Due to a number of nodes that have been added only in production, the only interesting piece of information is that the auto-increment on staging is much lower than production. I checked the actual nid that was created, and it doesn't exist on production, so I would assume that Deploy would just create the rows needed in node, node_revisions and node_uuid.
Originally, I thought the issue had to do with the fact that I'm using a different path to admin (using config instead), after reading this post: http://drupal.org/node/433102 . I switched back to "admin," and I still see the same results.
I somewhat understand if the issue relates to the fact that I didn't make an exact copy, but since people would potentially want to deploy some things and not others, this doesn't seem like it would be a continual issue.
#25
I am also having this issue. I installed Deploy on two new installs of Drupal (Aquia) and followed the directions for setting them up. I did a test of entering a story on one and then deploying to the other. This worked fine. I then went to a dev install that we have been working on for some time now and installed Deploy according to the 'sending' side instructions. Then I read the advanced section and enabled more parts of both Deploy and Services to allow deploying of content types and CCK stuff and such. I think that just about every thing under Deploy is activated and the same for Services ( a few depended on other modules that did not seem relevant so I did not activate them). I then tried to find a way of deploying content types and can not seem to locate the way to do this. So, noticing that the deploy option was there for the nodes that were my new content type, I tried to deploy them and it said that they deployed successfully. They are not on the destination server. I look at the DB and none of them are there. The images attached to the node have been deployed, but not the node. I read earlier about the UUID and checked, on the sending side there is a UUID for all of them. (I noticed that there is also one for a node that was deleted so there may be an issue with delete not cleaning up node_uuid table).
Anyway, I noticed that the last post here was 5 months ago and I am wondering if any progress has been made. I am evaluating this as a possible solution to being able to have most content developed in a staging environment and then deployed to a production site. There will also be some content that is entered directly into production so I am trying to also make sure that this will handle that. And, we will have all sorts of content that needs to be deployed, including panels and views and CCK based content type as well as node extension modules that create other content types.
What is the status of this issue? I see it is 'active' and 'critical' but that does not tell me much since it has been 5 months since an update. I see it is 'Unassigned' so I am asking if it is something that is on the back burner or is it that there is not enough information OR did I just miss something...
#26
I can confirm the above issue. When Deploying a node to a server on which the content type isn't available yet, 'Success' is returned, but nor the content type nor the node is actually deployed. Deploying Content Types currently does not work.
On the receivers end, Watchdog shows the following (new_content_type is the name of the content type I wanted to deploy):
call_user_func_array() [<a href='function.call-user-func-array'>function.call-user-func-array</a>]: First argument is expected to be a valid callback, 'new_content_type_node_form' was given in C:\xampp\htdocs\client_1\includes\form.inc on line 378.Using PHP 5.2.9 + Drupal 6.20 + Services 2.x-dev + Deployment 1.x-dev.
#27
I was experiencing the same issue as the title. My problem was a permissions issue and solved it by by granting the proper permissions to the roles in Drupal on the destination server (I ended up checking all the permissions about any services in the permissions page).
after debugging I found out that there are some cases in the services module that the number 1 is returned when an authentication fails and the deploy module is not caching this fail but instead taking it as a success (it only evaluates against NULL). Perhaps this is something that needs to be fixed in deploy.
#28
I also am having this issue. Source server says success, destination server gives logs for clear cache generated by xmlrpc page. I have enabled all relevant permissions and followed the instructions at http://drupal.org/node/408774 . I am attempting to push a node using the method described in the first part of the "basic usage" instructions. In my case, I am applying this to an existing Drupal site.
I am running:
I also tried this with Services 6x.2x-dev (2011-Jun-19) with the same result.
#29
I'm having this issue as well, but I've narrowed it down to only content types that I've created. The default Page content type deploys without a problem, but types I've created for a newsletter or multimedia state success, but never propagate. It shouldn't matter, since they're all just nodes, but maybe there's a clue in there somewhere. Succeeds with new Page content or updating existing Page content. Fails with new Newsletter content or updating existing Newsletter content.
#30
Ah, good point. I am also using custom content types. I think I also did try it on a standard Page content type and it still didn't work, but not 100% sure...
#31
@barckhoff and @bmartinP4
Be sure the custom content type is available on BOTH servers.
Have a look at #16.
#32
@bmartinP4's custom content types are available on both the source and destination servers.
I've done more experimentation. What I'm seeing is that a node propagates if the custom content type has attachments disabled (under Workflow Settings), and does *not* propagate if the custom content type has attachments enabled. Even if there's no actual attachment for the given node, just the fact that attachments are enabled appears to disable propagation, even though the deployment log indicates a successful transfer.
#33
See #459192: Deploy module doesn't work with upload module for a patch that allows file attachments to be deployed.
#34
Nope. That is not it. At least not the whole of the problem. I am having the same issue and my custom content type doesn't have attached images enabled. And, I have the upload module disabled. (Since the module fails with upload module on, you do need to have attached images -- which uses upload -- disabled.)
Moreover, I exported destination content type and imported to receiving just before deploying, and it still failed.
This could be a great and important module if it was supported.
#35
Seems it seems the Deploy module cannot handle checkbox CCK widgets, either.
#36
Everyone that still has some interest in working with the 6.x-1.x version of Deploy, needs to read through my comment here, and to pitch in with their opinion.
Unfortunately this issue is going nowhere. The problem could actually be anything. So I'm going to take over this issue and make it into a meta issue where we together should try to find the best way to solve the underlying problem that we are dealing with.
But first I want to state something that you have to have in mind while working with Deploy 6.x-1.x:
We need to understand that Deploy 6.x-1.x was written with a very specific use case in mind and that it had very valid reasons for some of the decisions taken (i.e. using
drupal_execute()instead of other equally broken functions likenode_save()). In other use cases though, this has proven to not work very well as we see in this issue.But motivating the current architecture won't help any of you in this thread. So, we have an underlying problem that we are dealing with here. Basically the same problem that we are facing in most other issues too -- forms and widgets are way to fragile to depend on for saving content. To change this for Deploy 6.x-1.x means a lot of work. A lot of work.
The easy answer, for me as a maintainer, is to say -- upgrade to Drupal 7. The Deploy API for D7 have a very different approach, which is much better suited for more use cases. So, if at all possible, upgrade to Drupal 7 now. It's not fully ready, but we are coming closer quite fast.
The tougher answer though, is of course to say that we need to fix the Drupal 6 version. Although I have no personal interest in the old version, I of course feel responsibility as a maintainer and want to solve this. I see three ways of going forward:
1. Backport
We will backport the work made for Deploy 7.x-2.x
+ We will have a very stable architecture to stand on
- This is not easy. It will take much time and testing
- It will be hard to upgrade from the existing version
- We have to drop support for deploying configuration (content types, views etc)
2. Middle way
We will create a new branch from Deploy 6.x-1.x and start relying on Services 6.x-3.x and go away from using
drupal_execute()for saving content. We will try to break as little of the current API as possible.+ We will have a more stable architecture to stand on
+ It's not as time consuming as alt. 1
- It will be hard to upgrade from the existing version
- We have to drop support for deploying configuration (content types, views etc)
3. Continue patching what we have
We will identify the most outstanding issues and just fix them on the current architecture. We need people to come in with detailed bug reports to help track down these problems.
+ It's the least time consuming
+ It wont require much upgrade efforts
+ We probably don't have to drop support for any current functionality
- It will continue to be an API that is hard to extend
#37
So, personally I would strongly recommend the 3rd alternative. Mainly because my own time is very limited since I'm putting most of my effort into the new Drupal 7 version and other projects. But also because we won't need to do redo anything that still might introduce other problems. I simply don't have the time to develop and maintain yet another branch.
I think if we together highlight and focus on the most critical issues, and try to track them down by submitting more detailed bug reports, we can make the current version working. I probably need a group of people dedicated to help me with this. But there seems to be enough people in this thread to do so :)
I will think some more on this. What do you think?
#38
Well, first, thank you for the thoughtful, detailed reply.
I see potential uses for such a module:
1. Sync'ing development and production sites
2. Content sharing on multiple sites
Both are coveted modules. To me, sync'ing a dev site with live site can be done manually. But, content sharing among sites cannot be done reasonably (where there is a regular influx of new and changed content) without a module. And, multisite for clients who want to share only a few items and who want to DIY their own site is just out of the question.
So, for me, content sharing capability (or lack thereof) is holding up a 9-site network launch for sharing of a freakin' master calendar. (Although, I had hoped to share one other custom content type, as well.) Looks like I will have to go old school and use an IFRAME and Google Calendar. Pretty said resolution for a Drupal platform site, IMO. Much will have to be compromised using Google Calendar.
From my experience of trying all the content sharing modules, content sharing in Drupal is seriously lacking. None of the modules do it reliably. All have bugs and spotty support/progress at best.
DRAWBACKS to current Deploy:
-------------------------------------
For #1 use, you could more easily have identical sites. But, for #2, that isn't practical. But, it is easy enough to match certain applicable settings of the distributing and receiving site -- which is all that I thought was necessary. I have taken great care to be sure that the elements of what I was pushing from the source site (content type, taxonomies, views) match on both sites. I have been creating those elements on the distributing site and exporting them to the receiving site before doing Deploy. Ideally, you wouldn't change that stuff much after initial configuration.
FUNCTIONALITY I WANT:
-----------------------------
I'd be happy to simply push a node that assumes the content type settings on the recipient site. I can live without the settings push (in fact, I haven't been using it). Actually, I would prefer that. The main point is that it must be easy for non-tech client staff to use. Deploy definitely is easy to use.
I am happy to contribute however I can, as a non module developer. It seems to me that people have been pretty good about reporting what has and hasn't worked in their troubleshooting. More so than I have seen on other issue queues.
What now?
#39
Actually, I was trying to do this with the Content Push module, but I seemed to be the only one. Moreover, the developer didn't seem too interested in my trying to help progress that module along.
#40
@dixon - I would advocate #2 middle ground. Services 3 is much more robust and allows for configurable authentication mechanisms per endpoint. Services 2 only allows either login OR key auth. If someone wants to use this module with other modules that use services with keyauth, it's not going to work. It's important to note that services 3 doesn't come with key_auth anymore, but we've upgraded the old module and plan to contribute it back.
Like greta, I don't mind loosing setting pushing. I feel like deploy should be more for content than settings. Settings exports are handled pretty well in code or with features/strongarm. So you know what would make the upgrade path so hard?
We at sony can probably help with this effort.
#41
Deploy fills a very huge void of a good content staging process for drupal, whereas settings, views, cck deployment can be accomplished any number of ways (features, strongarm, autopilot). This is as true for drupal 7 as it is for 6.
To me, content staging means specifically:
Alternatives that I have used in the past include:
So... in response to comment #36, unless there are some serious show-stoppers between d6 and d7, it makes sense to me to leverage the same logic between the two (which usually keeps the maintainer more involved). I personally find it easier to switch between the apis than between different logic.
If you had a different maintainer for d6 branch, then #2 could certainly make sense. And if push came to shove, #3 would even be ok since I mostly would just like to see continued support for the 6.x version. I am actively using Deploy for my company and will of course be happy to help with whatever approach is decided on...
#42
First, my hat is off to dixon_, katbailey, and heyrocker; Deploy's method of pushing content using Rules, Views, and Services is a huge step forward.
As far as options 1, 2, or 3 go, I think we're still putting the cart before the horse. The D7 version is still in dev and there is no documentation to speak of. The problem with spending anything other than the minimum on D6 is that all the buttery goodness in D7 is only half baked at this point. And that's a pretty strange place to begin a backport, no?
Yes, I am in the 'can upgrade' camp and I would rather see maintainers and contributors get the D7 version working as D7 makes a lot of things possible and easy. And if a more generalized, and cleaner deployment API was possible in D7, that would certainly contribute to reasons to upgrade not to mention that backporting would at least no longer be illogical.
Until that point, I feel that unless a significant portion of the user base is in the 'can not upgrade AND needs full functionality' camp, we out to have maintainers spend their limited time on moving forward not backward. To me that means getting the D7 branch up to at least an Alpha stage with a little more documentation and doing the least effort to maintain the D6 branch. If some small group of users who need it want, they can pony up the money or developer time to a backport.
Else, if it's the majority that needs (comment 36's) option 1 or 2, speak up now and let's get a move on.
As far as functionality I would like: My take on what greta_drupal wrote is that it's better to have the ability to push content to arbitrarily configured sites than it is to support one assumption of what the pushing/pulling sites look like. And I whole heartedly agree: this makes Deploy more generic and apply to a large class of use cases.
D7 makes it possible to do more with fewer modules not because modules now use or provide an API but because the modules themselves have become more generic. The more generic Deploy can become, the more it can be used for. So, like greta_drupal, I would like to see the ability to push content / entities to an arbitrarily setup site with the (strong) assumption that the content / entity types are the same.
Eric
#43
Thanks for all the good feedback here. For now, my time has been limited so all work has gone into 7.x-1.x that now is slowly stabilizing and approaching a first alpha release. Once we reached a few alpha releases (or maybe a beta) I'll come back to this issue to see how we shall move forward.
But generally, I think I'm leaning towards alternative #3 in my comment above. I wanna put as much energy moving forward with as much new exciting stuff as possible. I hope you all understand.
#44
option 2 from comment #36 looks best to me, unless the time that it would take to do that in D6 is more than the time taken to get the first D7 beta out from now.
surely you want at least one working, stable version of the module in existence? it would be awful if both D6 and D7 ended up never happening, but if you got the D6 version working smoothly then a lot more people might start using it and helping out.