Community Documentation

hook_init

5 core.php hook_init()
6 core.php hook_init()
7 system.api.php hook_init()
8 system.api.php hook_init()

Perform setup tasks for non-cached page requests.

This hook is run at the beginning of the page request. It is typically used to set up global parameters that are needed later in the request. When this hook is called, all modules are already loaded in memory.

This hook is not run on cached pages.

To add CSS or JS that should be present on all pages, modules should not implement this hook, but declare these files in their .info file.

See also

hook_boot()

Related topics

▾ 16 functions implement hook_init()

actions_loop_test_init in modules/simpletest/tests/actions_loop_test.module
Implements hook_init().
dblog_init in modules/dblog/dblog.module
Implements hook_init().
hook_language_init in modules/locale/locale.api.php
Allows modules to act after language initialization has been performed.
locale_init in modules/locale/locale.module
Implements hook_init().
locale_test_init in modules/locale/tests/locale_test.module
Implements hook_init().
overlay_init in modules/overlay/overlay.module
Implements hook_init().
phptemplate_init in themes/engines/phptemplate/phptemplate.engine
Implements hook_init().
system_authorized_init in modules/system/system.module
Setup a given callback to run via authorize.php with elevated privileges.
system_init in modules/system/system.module
Implements hook_init().
system_test_init in modules/simpletest/tests/system_test.module
Implements hook_init().
TableSort::init in includes/tablesort.inc
Initialize the table sort context.
TableSortTest::testTableSortInit in modules/simpletest/tests/tablesort.test
Test tablesort_init().
tablesort_init in includes/tablesort.inc
Initialize the table sort context.
ThemeHookInitUnitTest::testThemeInitializationHookInit in modules/simpletest/tests/theme.test
Test that the theme system can generate output when called by hook_init().
theme_test_init in modules/simpletest/tests/theme_test.module
Implements hook_init().
update_init in modules/update/update.module
Implements hook_init().

File

modules/system/system.api.php, line 1825
Hooks provided by Drupal core and the System module.

Code

<?php
function hook_init() {
  // Since this file should only be loaded on the front page, it cannot be
  // declared in the info file.
  if (drupal_is_front_page()) {
    drupal_add_css(drupal_get_path('module', 'foo') . '/foo.css');
  }
}
?>

Comments

Adding CSS from a .info file

To follow the above suggestion :

To add CSS or JS that should be present on all pages, modules should not implement this hook, but declare these files in their .info file.

CSS files can be added to a .info file using the following format:

stylesheets[all][] = node.css
(taken from node.info in node module)

See the developer's guide: "Writing .info files (Drupal 7.x)" for specifications on the .info file.
Also see the D6 theming guide: "Adding style sheets".

Or subtheme

Even core themes may be subthemed: Creating a Subtheme. I used this technique to add a CSS file for admin functions on a site with the Seven admin theme.

D6 heads up

In D6 you cannot add stylesheets in the .info file. So contrary to the documentation recommendation, you may have to use hook_init.

This documentation is for D7

This documentation is for D7 only. Here you can found D6 documentation about hook_init.

Although you are right with

Although you are right with that (there is a different page for D6), this is not really obvious unless checking the URL:

Versions:
4.6 – 8 hook_init()

This should be fixed, btw, and either split properly or merged to just one page, eventually with aliases.

D6, adding js with hook_init()

Yes, that is basically right. And somehow, again, not.

hook_init() will be invoked on every full bootstrap. Even if your module does not have anything of worth to add to the actual page request. This results in unnecessary processing time unless your module is involved in literally *every* page request. I could tell of few modules that really do so, block maybe one of these rare.

So in most cases, it is a good idea to add javascript exactly when it is needed. Assume your module implements a block that will only appear on user profile pages (even more, only for users with the role "foo") and contents some fancy jQuery effect based random tips. That said, why would you want to have not just all jQuery stuff added, but also an additional function call and, in the worst case, even unnecessary database queries or other stuff on literally every request, be it even just an AHAH callback for other modules?

Just imagine an average community site with, say, an average of 50 parallel visitors and 20 contrib modules enabled each of which just adds a few JS variables and calls for one or two string translations. Things sum up really quick.

And this is why there are many warnings to not use hook_init unless really inevitable.

As for the example above, the best place for dispatching all effect related javascript files and setting related to this block, will likely be in hook_block and only when $op is set to 'view'.

This is just an example, but hopefully it helps figuring out a bit.

external js

External Javascript can not seem to be added through the info file using the line 'scripts[] = http://yada.com/stuff'

Login or register to post comments