If both the referenced node and the referer node are added to a deployment plan by the user, how does the system know to deploy the referenced node first?
More explicitly how does a) happen in the commented code below?
// For each of these nodes, if they're not already in the plan,
// add them and dependency check them.
foreach ($nids as $nid) {
// If this node is already in the deployment plan then either
// a) it was added by the user and will get checked down the line or
// b) it was added through dependency checks and its already been
// dealt with. So we just move on in this case.
if (!deploy_item_is_in_plan($pid, 'node', $nid)) {
Comments
Comment #1
gddCircular references are not supported. I have a patch to manage this for a client but it is really rough. It will take some time to turn into something committable.
Comment #2
pokadan commentedHi, I understand circular references are tough to implement(I wouldn't want to do have to do it..) but I'm not sure this issue fits in this category.
I was just poking about how you make sure node B gets deployed before A if A has a nodereference to B (A->B) and both A and B are added to the deployment plan by the user, and not by node_deploy_check callbacks.
Is there something I've not understood about the module, perhaps.
Comment #3
gddOh I see what you're saying. Yeah that won't work, that's a bug :/
Of course the user could just add A and B would get pulled in automatically.
Comment #4
pokadan commentedWhat's the best way to this? I would create a remove from plan procedure, use that to remove the item from plan and then add it back with the appropriate weight.
Is that how you would do it? Is there a better way?
Comment #5
pokadan commentedI'm doing this right now:
Two things have changed in the code:
1)If the node is there in the deployment plan I remove it and then re-add it with proper weighting.
2)If the $node loads(it usually does, so I guess always..) run a dependency check on it. This is to prevent the situation where
A->B->C where info in C has changed but because B is unchanged, dependency check ends there.
awaiting any feedback..
Comment #6
johannesdr commentedHi, I am trying to solve the same problem.
I was thinking about making a function that would compare the weights of the current node and the referenced node and that moves the referenced node before the node when needed.
Something like deploy_get_item_weight_in_plan($pid, $nid) and deploy_set_item_weight_in_plan($pid, $nid, $newweight).
But I guess that it is a lot easier to remove the referenced node and add it again. I will test it and let you know what I find.
Note that the same problem occurs with translations. When the translation is added before the original node, the translations are not linked.
Comment #7
johannesdr commentedIt looks like poka_dan's solution works.
I have made a patch with the changes and will do some more testing.
Comment #8
johannesdr commentedI added the same check for translations.
Comment #9
johannesdr commentedFYI, I noticed the same problem with taxonomy terms.The terms are not added in the right order, and as a result the hyerarchy will be lost.
Because the parents do not yet exist.
You can use the same solution to fix it in taxonomy_deploy_check_taxonomy.
Never mind, this sould be solved by taxonomy_deploy_deploy_check_cleanup. But for some reason it doesn't work anymore. Probbably a local problem in my setup.
Comment #10
dixon_We have a general problem in the Deploy module here, not checking for this. It concerns not only nodereferences, but all items with dependencies added manually, basically.
I would like to solve this for all items and dependencies currently in Deploy. But also, trying to get the 6.x-1.x branch out the door, I would like to solve it the easiest way possible and oversee this properly in 7.x-2.x.
It's definitely a beta blocker, since many deployment errors probably could lead back to this. Here is one marked as duplicate: #642834: Translated node lose their relationships when deployed
Comment #11
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