Related Content
Drupal 10: Using A Lazy Builder To Create A Dynamic Button
Adding dynamic and interactive elements to a web page can be a challenge, and there are a few techniques available in Drupal to allow for this.
Drupal 10: Using Parameter Converters To Create Paths For Custom Entities
Drupal's path system gives authors the ability to override the path of an item of content. Whilst the internal path of a page might be "/node/1" the external path can be anything you want, and can be set when editing the item of content.
Drupal 10: Creating Context Aware Plugins
In previous articles I have written about injecting context into context aware plugins and creating custom context providers and wanted to complet
Drupal 10: Migrating Flags With The Migrate Module
I've been doing a bit of Drupal migration recently, and one of the tasks I have undertaken is to migrate "likes" from a Drupal 7 site to a Drupal 10 site.
Drupal 10: Programmatically Injecting Context Into Blocks
Context definitions in Drupal are really useful when you want to inject context into your plugins and I have been using them for a little while now. It has made building custom blocks to add content to pages much easier as I don't need to copy the same block of code to find an entity of a particular sort into the block plugin.
Drupal 10: Creating Custom Context Providers
I previously looked at injecting context providers into context aware plugins. This time I will explore more about creating our own context providers to plug into this system.
Comments
I'm stumped because, theoretically, the $nid isn't created nor available at the time when the page loads.
I'd like to use it to db_insert into a field belonging to a table different than {node} - - - - so that I can perform joins in future queries
Many thnx for your time and consideration
-Ben
Submitted by mcferren on Mon, 12/05/2011 - 02:24
PermalinkYou are correct. The nid isn't available in the form until the node has been saved, which would mean that the form is in the edit state. In this case the node object is kept in the $form['node']->nid parameter.
What you need is to create a hook that will intercept the information after it is saved. This would probably be hook_insert($node), which gets passed the node information after it has been saved and so contains the nid you want.
Of course, you'll probably want to create another hook (something like hook_load()) that will load the information into the node object that you saved in the previous hook.
I hope that helps :)
Submitted by philipnorton42 on Mon, 12/05/2011 - 09:16
PermalinkHi Philip,
Many thnx for your guidance! It definitely opened up doors for me to further research. I took your advice and understand how hook_node_insert will perform what I am looking for. I noticed that hook_insert works so long that I use it in the same module that defines the the node type. However, I am planning on using module [B] to add fields to a form that has been created in module [A] - - module[A].install being where the node type is created & module[B] is where I plan to put the hook_node_insert.
I've been reading about creating node types programatically. In my readings, they recommend creating instances (and the fields they align with) inside the install file.
// Create all the fields we are adding to our content type.
foreach (_node_example_installed_fields() as $field) {
field_create_field($field);
}
// Create all the instances for our fields.
foreach (_node_example_installed_instances() as $instance) {
$instance['entity_type'] = 'node';
$instance['bundle'] = $avatard['type'];
field_create_instance($instance);
}
My question is this:
If I have one module[A] where I create the node type and another module[B] that has a hook_form_alter that adds field(s) to the form_id of the node creation form in module[A] ,,,,
,,,to define the table structure that I need to hook_node_insert into, would I create an additional instance in module[B].install or should I have preplanned (when creating module[A].install) and added those extra instances in module[A].install - - - even though the instances would be orphaned until the hook_form_alter in module[B] comes into play?
Or should I bypass this complexity and just use hook_schema in the .install file of module[B]?
Many thnx for taking the time to help.
-Ben
Submitted by mcferren on Thu, 12/08/2011 - 03:02
PermalinkThank you
Submitted by Anonymous on Sat, 03/31/2012 - 13:10
PermalinkAdd new comment