some modules separate their token related code (hook token_values & token_list) in a separated file named mymodule.token.inc (e.g. flag) and include that file on hook init

nevertheless, if a module asks for module_invoke_all('token_values', ...) on hook boot or hook init the remaining modules (with greater weight) won't have those files included yet, resulting in those modules being ingnored (not implementing tokens) due to the cached $implementations[$hook] inside function module_implements

what would be the best practice recommended?
to include those hooks directly into the .module file?
is there any core documentation suggesting to avoid calls to module_implements in early stages (i.e. boot/init)?

IMO, this should be documented in API.txt and even in the starter example module

Comments

arhak’s picture

the pattern of a *.token.inc file seems to be in core now
nevertheless, issues similar to #642782: hook_language_init is a bootstrap hook and needs bootstrap_invoke_all() (D7)
keep arising in D6 contrib (e.g. #543506-4: Problem with tokens when using a custom_bredcrumbs_paths)

dave reid’s picture

What'd I'd encourage is doing this:

/**
 * Implements hook_token_list().
 */
function mymodule_token_list($type = 'all') {
  module_load_include('inc', 'mymodule', 'mymodule.tokens');
  return _mymodule_token_list($type);
}

/**
 * Implements hook_token_values().
 */
function mymodule_token_values($type, $object = NULL) {
  module_load_include('inc', 'mymoduleo', 'mymodule.tokens');
  return _mymodule_token_values($type, $object);
}
arhak’s picture

#2 thanks, that provides a standard
would be possible to have it document it somewhere (API.txt, handbook, anything?)
wouldn't the starter module be ideal for it?
I know it is small, but it would be a nice recommended practice having D7 so close, right?

dave reid’s picture

Status: Active » Closed (duplicate)