"After updating existing content" runs before content is saved.

>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.

This 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

Just ran into the same issue with a Computed CCK field that is not updating correctly due to the node not being saved yet.

From 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.

Playing 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.

Put node_save in computed field.

Subscribe - 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?

You 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']...);

subscribing

subscribing

FYI, this is the originating issue #402102: "After updating existing content" occures before content is saved

This applies to D7 as well.

A 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.

You 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:

<?php
// Reset the cached $node.
entity_get_controller('node')->resetCache(array($node->nid));

// Get all nids that reference this node. This is just an example.
$nids = db_query("SELECT entity_id FROM field_data_field_reference WHERE field_reference_target_id = {$node->nid}")->fetchCol();

// Include necessary Pathauto files.
module_load_include('inc', 'pathauto');
module_load_include('inc', 'pathauto.pathauto');

// Save current action for new aliases and change it to delete old one.
$alias_action = variable_get('pathauto_update_action', 0);
variable_set('pathauto_update_action', PATHAUTO_UPDATE_ACTION_DELETE);

// Update aliases for nodes that reference the updated node in their pathauto pattern.
pathauto_node_update_alias_multiple($nids, 'bulkupdate');

// Restore original action for new aliases.
variable_set('pathauto_update_action', $alias_action);

// Clear path cache. 
cache_clear_all('*', 'cache_path', TRUE);

?>

subscribing. same issue as #7. #13 doesn't work for me.

This 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.

The 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?

the workaround in #13 worked for me

Just an example :

Custom module with function hook_user_update.

function MYMODULE_user_update(&$edit, $account, $category) {

	drupal_goto("url-page");
	
}

This function redirect to "url-page" but the data has not been saved.
If you have a solution...

I 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.

Take 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.

After the last update of Rules I don't have this problem anymore.

Sorry 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.

@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).

#13 works for me but I also made absolutely sure to select the option

Force saving immediately: True.

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?

After 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.

Here 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.

I 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

Patch 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!

>"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.