The last issue related to this was a mess of different theories and situations. Here is a straight bug report on the issue I ended up hitting.
Situation:
I have a node type "Bug report" with a flag (module) "confirm" and a cck field "Status" which can be "Open" or "Closed".
When a bug report is set to closed, you can no longer add or remove a flag (via trapping and undoing the flag operation with rules).
When a bug report is set to open, all flags are cleared (via custom php)
Here is the output on editing a flagged Bug report from "closed" to "open"
0 ms Content is going to be saved has been invoked.
18.114 ms Included MODULE.rules.inc files.
19.536 ms Executing the rule Bug report submitted on rule set Content is going to be saved
19.828 ms Condition Saved content is Bug report evaluated to TRUE.
20.086 ms Loaded variable unchanged content
20.15 ms Action execution: Bug report submitted
21.15 ms Bug report submitted has been invoked.
21.422 ms Executing the rule Status changed to Open on rule set Bug report submitted
21.738 ms Condition Status is Changed evaluated to TRUE.
22.153 ms Condition Status is Open evaluated to TRUE.
22.377 ms Action execution: Enable comments
24.064 ms Comments: Set enabled has been invoked.
24.32 ms Executing the rule Comments: Set enabled on rule set Comments: Set enabled
24.504 ms Action execution: Execute custom PHP code
24.737 ms Evaluation of Comments: Set enabled has been finished.
24.891 ms Executing the rule Status changed to Fixed on rule set Bug report submitted
25.104 ms Condition Status was changed evaluated to TRUE.
25.288 ms Condition Status is Fixed evaluated to FALSE.
25.366 ms Evaluation of Bug report submitted has been finished.
25.513 ms Evaluation of Content is going to be saved has been finished.
0 ms After updating existing content has been invoked.
0.303 ms Executing the rule Bug report saved (existing) on rule set After updating existing content
0.527 ms Condition Updated content is Bug report evaluated to TRUE.
0.77 ms Loaded variable unchanged content
0.834 ms Action execution: Bug report saved
1.33 ms Bug report saved has been invoked.
1.543 ms Executing the rule Status changed to Open on rule set Bug report saved
1.773 ms Condition Status has changed evaluated to TRUE.
1.959 ms Condition Status is Open evaluated to TRUE.
2.139 ms Action execution: Flags: Clear all flags
2.864 ms Flags: Clear all flags has been invoked.
3.077 ms Executing the rule Flags: Clear all flags on rule set Flags: Clear all flags
3.231 ms Action execution: Execute custom PHP code
12.466 ms A node has been unflagged, under "Bug confirmation" has been invoked.
12.796 ms Executing the rule Bug report confirm removed on rule set A node has been unflagged, under "Bug confirmation"
13.031 ms Loaded variable flagged content
13.133 ms Action execution: Bug report confirm changed
13.834 ms Bug report confirm changed has been invoked.
14.088 ms Executing the rule Confirm changed and Status is not Open on rule set Bug report confirm changed
14.326 ms Condition Status is Open evaluated to FALSE.
14.643 ms Action execution: Flags: Set flag state
15.354 ms Flags: Set flag state has been invoked.
15.638 ms Executing the rule Flags: Set flag state on rule set Flags: Set flag state
15.797 ms Action execution: Set flag state
20.361 ms A node has been flagged, under "Bug confirmation" has been invoked.
20.657 ms Executing the rule Bug report confirm added on rule set A node has been flagged, under "Bug confirmation"
20.896 ms Loaded variable flagged content
20.993 ms Action execution: Bug report confirm changed
21.106 ms Bug report confirm changed has been invoked.
21.358 ms Not executing the rule Confirm changed and Status is not Open on rule set Bug report confirm changed to prevent recursion.
21.424 ms Evaluation of Bug report confirm changed has been finished.
21.515 ms Evaluation of A node has been flagged, under "Bug confirmation" has been finished.
21.658 ms Evaluation of Flags: Set flag state has been finished.
21.824 ms Action execution: Show a configurable message on the site
21.94 ms Evaluation of Bug report confirm changed has been finished.
22.067 ms Evaluation of A node has been unflagged, under "Bug confirmation" has been finished.
22.226 ms Evaluation of Flags: Clear all flags has been finished.
22.359 ms Evaluation of Bug report saved has been finished.
22.505 ms Evaluation of After updating existing content has been finished.
Unfortunately, it looks like the tabs were lost there...
Still, this is essentially what is happening:
After updating existing content has been invoked.
Executing the rule Bug report saved (existing) on rule set After updating existing content
...
Action execution: Bug report saved
Condition Status is Open evaluated to TRUE. //We are true here...
Action execution: Flags: Clear all flags
Action execution: Execute custom PHP code //This clears all flags. It is tested and works.
Executing the rule Bug report confirm removed on rule set A node has been unflagged, under "Bug confirmation"
Condition Status is Open evaluated to FALSE. //BUG: Status is NOT open here! The node wasnt saved before "After updating existing content" was ran!
...Here the flag is undone, countering out my "On bug report opened" action...
Fix: Make the node save before "After created" and "After modified" is ran.
Comment | File | Size | Author |
---|---|---|---|
#27 | rules-force_cache_reset_on_fetch_entity-430274-27-7x.patch | 1.69 KB | nerdcore |
|
Comments
Comment #1
fago>Fix: Make the node save before "After created" and "After modified" is ran.
That's not possible. We just rely on the hooks drupal provides us here.
Comment #2
drupov CreditAttribution: drupov commentedThis is great news... :(
Has anyone found any way around that? I need my action to be run after saving, otherwise it makes no sense... Help is really appreciated! Thanks
Comment #3
harking CreditAttribution: harking commentedJust ran into the same issue with a Computed CCK field that is not updating correctly due to the node not being saved yet.
Comment #4
harking CreditAttribution: harking commentedFrom reading through the node module, it looks like the core of the node (node and node revision) is saved before this runs.
In my case i think the CCK fields are being updated _after_ the rules module runs. I'm going to see if playing with the module weights has any effect.
Comment #5
harking CreditAttribution: harking commentedPlaying with module weight isn't working. going to cheesy hack this by redirecting to a page that will then run the node save on the associated node thus making sure my original content has been saved to the database.
Comment #6
bfr CreditAttribution: bfr commentedPut node_save in computed field.
Comment #7
geerlingguy CreditAttribution: geerlingguy commentedSubscribe - just butted heads with this bug... in my case, when a user enters something into a field, I want to send an email containing the contents of that field. But that field shows as empty in the email until the second time someone saves a node. This is happening with both "After updating existing content" and "Content is going to be saved."
Is there a way to hack around this and make sure the node is saved prior to a certain action? Maybe run a node_save() as one of the actions?
Comment #8
.kuma CreditAttribution: .kuma commentedYou can access the lastest values of the node as follows (only tested with Execute Custom PHP code action and CCK Field):
In Execute custom PHP code:
$node->field_some_cck_field['ex']...;
Instead of using node_load in a function in my module that was called with Rules, I had to pass the updated values to the module this way:
my_custom_module($node->field_some_cck_field['ex']...);
Comment #9
kevin.mcnamee@mailbox.org CreditAttribution: kevin.mcnamee@mailbox.org commentedsubscribing
Comment #10
mrdan1965 CreditAttribution: mrdan1965 commentedsubscribing
Comment #11
kbk CreditAttribution: kbk commentedFYI, this is the originating issue #402102: "After updating existing content" occures before content is saved
Comment #12
anrikun CreditAttribution: anrikun commentedThis applies to D7 as well.
Comment #13
HnLn CreditAttribution: HnLn commentedA workaround (in d7, don't know about d6) is to do an entity save (force) action as first action, then I get the saved node.
Comment #14
charlie-s CreditAttribution: charlie-s commentedYou can throw this in your code to force other things (like token, pathauto, etc) to see the new $node:
entity_get_controller('node')->resetCache(array($node->nid));
Example:
Comment #15
wickedpixel CreditAttribution: wickedpixel commentedsubscribing. same issue as #7. #13 doesn't work for me.
Comment #16
AldenC CreditAttribution: AldenC commentedThis may seem ridiculous, but I made a work-around with this issue. I have a rule that calculates page numbers for pages in a book. But when I save a page, it will not save the page number on the new page. Similar to the problems encountered above. It works fine with edit or deleting a page though.
So what I did is use the Rules Bonus Pack Misc feature to provide a reaction on a page variant. I put a redirect to this page at the end of my main rule. This page variant is simply a redirect back to the original node, but it also triggers my additional rule which determines if the field_page_number is empty, if it is empty, I call the action Save the Entity, and walah, the page numbers are recalculated and saved properly.
So the bottom line here is to have some field that is null until the desired action is complete, use the Rules Bonus Pack to trigger a reaction to a rule that resaves the entity. Works good, probably a performance hit to run my rule twice, but it works.
Comment #17
RainbowArrayThe solution that worked for me was to add as my first action, "Execute custom PHP code," with the following:
entity_get_controller('node')->resetCache(array($node->nid));
Your mileage may vary based on what you are updating. What I found when I dug into things is that the cache for the node isn't cleared yet when this event fires. In my case, I was doing some things with revisions, so while the node was expecting to see the most recent revision number, what was getting pulled up was the previous revision in cache. So all the subsequent actions were based on the previous revision AND the entity API was checking the "view content revisions" permission, which I didn't want the authenticated role to have.
So anyhow, that line of code above solved things. Maybe that's something rules should do by default for this type of event?
Comment #18
benjaminbradley CreditAttribution: benjaminbradley commentedthe workaround in #13 worked for me
Comment #19
R3m CreditAttribution: R3m commentedJust an example :
Custom module with function hook_user_update.
This function redirect to "url-page" but the data has not been saved.
If you have a solution...
Comment #20
joco_sp CreditAttribution: joco_sp commentedI have two rules. The first fires after the node is created and the second when this node is updated.
#13 didn't work for me.
#17 worked. I put the action in the first rule.
Comment #21
Chris Burge CreditAttribution: Chris Burge commentedTake a look at http://www.drupal.org/project/hook_post_action. It should be fairly straightforward to write a custom event using hook_entity_postupdate.
Comment #22
joco_sp CreditAttribution: joco_sp commentedAfter the last update of Rules I don't have this problem anymore.
Comment #23
crutch CreditAttribution: crutch commentedSorry for the long reaction log below but the bold lines show that it is running processes twice and it seems that the first time it is run, then node is then saved, and then it reacts again to that saving of the node. In my case the end user gets duplicate emails. Is this the same issue this drupal-rules issue is discussing and solving?
Reacting on event After updating existing content.
0 ms Reacting on event After updating existing content.
14.13 ms Evaluating conditions of rule Change State from Confirmed to Other. [edit]
...
97.244 ms Evaluating conditions of rule Remove Agreement Reminder Archived. [edit]
97.512 ms The condition data_is evaluated to FALSE [edit]
97.518 ms AND evaluated to FALSE.
97.56 ms Saved node of type node.
" Reacting on event After updating existing content. [edit] <<<<<<<< For some reason it is duplicating a portion of the process here down as it has already done the whole process once above.
0 ms Reacting on event After updating existing content.
0.226 ms Evaluating conditions of rule Change State from Confirmed to Other. [edit]
0.537 ms The condition user_has_role evaluated to TRUE [edit]
...
50.423 ms AND evaluated to FALSE.
50.442 ms Finished reacting on event After updating existing content.
287.593 ms Finished reacting on event After updating existing content.
Comment #24
Pierre.Vriens CreditAttribution: Pierre.Vriens at In Petto commented@crutch IMO your issue (in the previous comment) is NOT what this issue is about. I suggest you have a look at this link to better understand what is shown in your rules logging (which also includes a possible work around for your issue).
Comment #25
nerdcore CreditAttribution: nerdcore at OpenConcept Consulting Inc. commented#13 works for me but I also made absolutely sure to select the option
and to push this Action to the very very top of the list of Actions.
Would it make sense to rename the Event from "After saving ..." to something like "While saving ..." to perhaps alleviate some of the confusion about this issue?
Comment #26
nerdcore CreditAttribution: nerdcore at OpenConcept Consulting Inc. commentedAfter discussing this with my team it is agreed that having an Action to save an entity on the Event of Updating that entity is likely to cause recursion and probably not the most desirable solution.
In our specific case it does appear that the Actions to act on the entity being saved are retrieving a cached copy of that entity, and I am now looking to use the solution provided by @mdrummond in #17 instead. I'll likely do this through some custom module code as opposed to executing PHP editable via the UI but clearing the cache of the node in question does appear to be the better solution at this time.
Comment #27
nerdcore CreditAttribution: nerdcore at OpenConcept Consulting Inc. commentedHere is a patch which adds an optional parameter to the Action "Fetch entity by id" which if selected will pass TRUE as the last parameter to the call to entity_load(), forcing cache reset and returning the entity from permanent storage rather than from the cache.
This does not fix the problem which is leading to some confusing functionality, but it would allow a Rule maker to add a new Fetch Action which will obtain the stored entity instead of the cached one.
Comment #28
crutch CreditAttribution: crutch commentedI think #23,#24 and https://www.drupal.org/node/1704290 are symptoms of what this issue is trying to resolve. I'm using this https://www.drupal.org/node/1704290#comment-8840959 which works for our case which seems to point back to this thread issue, which means that #24 could also point back here.
#27 nerdcore solution seems best but haven't tried yet
Comment #29
BYUStudies CreditAttribution: BYUStudies as a volunteer commentedPatch in #27 works for me--it (along with forcing an entity save at key points) solves an issue I've been having for months with updating users on checkout completion. Thank you @nerdcore!
Comment #30
BYUStudies CreditAttribution: BYUStudies as a volunteer commentedComment #31
fago>"After updating existing content" runs before content is saved.
This is not a problem of rules, but a consequence of something else trigger this. I'd be happy to discuss a patch like #28 as feature addition that helps to workaround this, but this should 1. get its own issue 2. must go thoroughly tested to avoid any regressions as 7.x is in maintenance mode.