Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
I experienced the same problem but with the imagecache_customactions module install.
Fatal error: Call to undefined function imagecache_action_definitions() in /home/tguide6/public_html/sites/all/modules/contrib/imagecache_actions/imagecache_customactions.install on line 8
The problem only occurs on the first attempt at installing the module ONLY IF it's installed at the same time as imagecache; installations always works fine--once imagecache has already been installed.
The problematic install module code is as follows:
<?php
// $Id: imagecache_customactions.install,v 1.1.2.1 2008/11/09 15:33:54 dman Exp $
/**
* Need to flush the cache when this module is enabled
*/
function imagecache_customactions_install() {
imagecache_action_definitions(TRUE);
cache_clear_all('imagecache_actions', 'cache');
drupal_set_message(t('Additional imagecache actions should now be available in the presets !settings_link', array('!settings_link' => l(t('settings'), 'admin/build/imagecache'))));
}
function imagecache_customactions_uninstall() {
imagecache_action_definitions(TRUE);
cache_clear_all('imagecache_actions', 'cache');
}
Line #8
imagecache_action_definitions(TRUE);
refers to a function in imagecache.module (Line #222) that, I am guessing, is not registered because the module is not installed yet, even though it is properly specified as a dependent module in the imagecache_customactions.info file.
It seems to be related to this system.module bug (http://drupal.org/node/151452) where installation of dependent modules are not executed in the proper order.
I have noted this issue and reffered to this bug in that bug report.
Looks like a simple function_exists() check should fix that.
If imagecache DOES boot afterwards, it will do its own scanning like this, so the job will get done. The code is only there to force imagecache to recognize it if it was installed subsequently.
Occupied Kumeyaay Land; San Diego, CA, US–Tijuana, BC, MX
commented
Trying to use 5.x-2.3 and get the same error for imagecache_canvasactions:
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Call to undefined function imagecache_action_definitions() in
/.../sites/all/modules/imagecache_actions/imagecache_canvasactions.install, line 5
In imagecache_canvasactions.install I changed
function imagecache_canvasactions_install() {
imagecache_action_definitions(TRUE);
cache_clear_all('imagecache_actions', 'cache');
}
to
function imagecache_canvasactions_install() {
if (function_exists('imagecache_action_definitions')) {
imagecache_action_definitions(TRUE);
}
cache_clear_all('imagecache_actions', 'cache');
}
That function call triggers a cache refresh that alerts the UI to the fact that there are new presets available...
If the function is disabled, the cache still needs to be flushed.
Often disabling and re-enabling things makes that works.
... but normally ... tht function call in the hook_enable was expected to do it for you :-/
Comments
Comment #1
pasqualleComment #2
jfxberns commentedI experienced the same problem but with the imagecache_customactions module install.
Fatal error: Call to undefined function imagecache_action_definitions() in /home/tguide6/public_html/sites/all/modules/contrib/imagecache_actions/imagecache_customactions.install on line 8
The problem only occurs on the first attempt at installing the module ONLY IF it's installed at the same time as imagecache; installations always works fine--once imagecache has already been installed.
The problematic install module code is as follows:
Line #8
refers to a function in imagecache.module (Line #222) that, I am guessing, is not registered because the module is not installed yet, even though it is properly specified as a dependent module in the imagecache_customactions.info file.
It seems to be related to this system.module bug (http://drupal.org/node/151452) where installation of dependent modules are not executed in the proper order.
I have noted this issue and reffered to this bug in that bug report.
Comment #3
dman commentedLooks like a simple function_exists() check should fix that.
If imagecache DOES boot afterwards, it will do its own scanning like this, so the job will get done. The code is only there to force imagecache to recognize it if it was installed subsequently.
Comment #4
dman commentedFixed in -dev
Comment #6
baisongTrying to use 5.x-2.3 and get the same error for imagecache_canvasactions:
In imagecache_canvasactions.install I changed
to
...and then it installed!
Comment #7
baisong...but actually... it doesn't seem to have successfully installed. all i have in my imagecache preset dropdown is the normal scale, resize & crop...
Comment #8
dman commentedThat function call triggers a cache refresh that alerts the UI to the fact that there are new presets available...
If the function is disabled, the cache still needs to be flushed.
Often disabling and re-enabling things makes that works.
... but normally ... tht function call in the hook_enable was expected to do it for you :-/