I have created two new servers: a source server and a destination server. If I deploy a node (page) that is authored by a user that is not user 1, the user is deployed to the destination server and then the node is deployed to the destination server.
The error occurs when I go to redeploy the same node or another node that was authored by a user that now exists on the destination server (except for user 1). On the destination server error log all there is:
- cache cleared, and
- session opened for user 1.
On the source server deployment log, the details show:
- Module: user,
- Description: User: username,
- Result: Error,
- Message: The name username is already taken. The e-mail address username@mydomain.com is already registered.
- Module: node,
- Description: page: Boats,
- Result: Not Sent,
- Message: Item not sent due to prior fatal error.
Any ideas what I am doing incorrectly?
Comments
Comment #1
timidri commentedI have the same issue. Is it an idea to map users by username and email address? It would make deploy much more usable, IMHO, since we would then be able to migrate content between sites with non-identical user sets.
Comment #2
rlangille commentedI am encountering the same exact issue and I have verified it on two separate clean installs of drupal 6.16, after following the documentation precisely. Also, following the instructions for installing on existing servers I found that the same problem occurs.
Comment #3
gddI committed a patch on March 9 which I believe addresses this issue. Can you download the newest dev version and test?
Comment #4
gddNote that this will have to be applied to the destination AND source servers.
Comment #5
drupalxykon commentedhttp://ftp.drupal.org/files/projects/deploy-6.x-1.x-dev.tar.gz still returns the same error (as described in this ticket).
Is there a newer version?
Comment #6
gddNo that is the newest
Comment #7
drupalxykon commentedIf you can suggest a workaround, that would be great. The issue still exists.
Comment #8
petrocket commentedI too have just been debugging this issue and it appears to me that what is happening is the source server calls user_load() to get information about the author of a node. user_load() gets the uuid from the hook in deploy_uuid.module and also from uuid.module. I think that uuid.module is overwriting the uuid that is set in deploy_uuid.module. Please note that I'm using uuid module version 6.x-1.0-beta1 (which is what drush gives you by default now) It appears that this version adds the uuid_users table.
Why does this matter? The uuid in the users_uuid (the table deploy uses) is NOT the same uuid as in uuid_users (the table uuid uses). So the source server sends the uuid from uuid_users to the destination server and it tries to compare it to the uuid in users_uuid, which will always fail. This results in deploy always trying to create the user on the remote server even though that user already exists and then we get the error because that user actually does exist and the names and emails collide.
Comment #9
petrocket commentedMy initial suggestion is to add:
$account->uuid = deploy_uuid_get_user_uuid($uid);
immediately after the line:
$account = user_load(array('uid' => $uid));
in user_deploy_check_user($uid) in user_deploy.module
In my testing so far this has fixed the user collision issue, however, now I'm getting another issue with an invalid value for 'robots' and I'm not sure if it has something to do with this change or not.
Comment #10
gddThe most common reason for duplicate errors is that you installed deploy on a source server in a situation where the source server and destination server already had data. In this situation you need to install deploy on source, do a full dump to destination, and proceed from there. Otherwise your uuids won't match, and you'll get dupes. This is clearly outlined in the installation guide.
Deploy is completely incompatible with the UUID module, and I have absolultely no idea what the implications are of using both. I would love to see us move into a scenario where we use it instead of our own implementation and I know dixon feels the same way. Hopefully this can happen.
I believe that the 'robots' problem is caused by the Nodewords module. Please see this issue for more on that.
#808142: NodeWords Module Causes deploy to fail
If someone has a problem that is NOT related to any of the above, please let us know.
Comment #11
petrocket commentedAh, I see what you mean about the UUID for deploy not being the same thing as the UUID module. I was confused by some of the references to UUID on the installation page here: http://drupal.org/node/408774
So, just an FYI about those collisions if you have both installed.
Comment #12
gdd