I'd like to invoke a specified feed importer after a node of a particular content type is deleted (this is all within the same site).
I started with Rules and found that the so called 'after' events don't actually occur after the operation has been written to database. Discussing in this issue in the rules issue queue the idea was floated of using hook_post_action.
I did have a look but couldn't work out how to integrate this to rules. I looked for examples but didn't find anything comparable that I could use as a template.
I actually found an acceptable and reliable workaround to doing this for creation and updating. However, I haven't found a workaround for invoking the feed importer after a node has been deleted.
hook_post_action has hooks so you can write your own functions that invoke the functions in that module. So, in theory I should be able to do something like:
function mymodule_node_postdelete($node) { feeds_import('myfeedimporter',0); }
However, I'm not sure what command to use to invoke the feed. I've hunted through the feeds module and it looks like feeds_action_import_feed
may be the function that is invoked by Rules, but I'm not sure that it works or that I've specified it properly:
$params_array = array( "importer" => "myfeedimporter", "feed_nid" => "0" ); feeds_action_import_feed('myfeedimporter',0, $params_array);
While I think, if it works, a simple invocation of the feed importer would suffice for my needs, there would be much greater value to the wider Backdrop community if we could use these post action hooks as events in Rules (I note the D8/9 module 'Business Rules' has an issue for adding this in).
I would appreciate some pointers as to how I can invoke the feeds importer, either in my custom implementation of hook_node_postdelete, or in Rules.
Recent comments
Thanks so much! It's working now: I was able to transfer the docroot files to the containing directory without the need for a second database or any manual configuration export/import/sync...
Backup & Migrate Config: There was a problem creating field...database table with the name already exists.
Ah, I see. Sorry, I hadn't clicked the link and assumed it was the instructions for upgrading from Drupal 7. If you are simply copying a site from one location on a server to another, the...
Backup & Migrate Config: There was a problem creating field...database table with the name already exists.
Thanks for the quick reply, laryn. No features, no Drupal: I built the source site in Backdrop in a subdirectory of the target directory under the same user home directory on the same...
Backup & Migrate Config: There was a problem creating field...database table with the name already exists.
This doesn't sound right -- when the upgrade completed, did you export the post-upgrade configuration into the staging folder (and commit that to the repo if you are using a git-based workflow...
Backup & Migrate Config: There was a problem creating field...database table with the name already exists.
The new question is; how do i prevent a custom block to be cached?
How to get the current page language?