Mohammed Sameer wrote:
hook_variables() { $items = array(); $items['mymod_num_things'] = array( '#default_value' => 2, // Same syntax as FAPI uses '#realm' => 'mymod', // optional '#translatable' => FALSE, // probably default false '#cacheable' => TRUE, // default to TRUE if under X chars when serialized '#serialize' => FALSE, // default to true for object/array, else false ); foreach (node_get_types('name') as $type) { $items['mymod_things_for_' . $type] = array( '#default_value' => array(), ); }
return $items; }
I'd actually declare it as hook_variables($type, $arg2)
The module will not always know about the available node types as we can add a bunch after enabling the module. So I'd say that whenever we have a new content type (No idea how to detect that) we call this hook to update our defaults. The problem is that hook_variables() returns the default related to the node types we have as well as the defaults not related to the node types. That's why $type can either by 'node' for node types related defaults, 'comment' for comments related settings, 'term' for term related, 'vocabulary' for vocabulary related and 'default' for anything else ? Or would this be an over kill ?
Erm, this is completely unrealistic. We don't have concepts such as "node related variables", "term related variables" and so on. We have variables, which are any kind of key => value pairs, what is what we know (at least what we need here). Gabor