After upgrading Rules from 2.6 to 2.9 on a site with both Rules and Scheduler enabled, I am getting the error with stacktrace below when drush attempts to clear the cache after running another module's update hooks. The update went fine, and the steps to reproduce are: "drush cc; drush updb;" after the updb completes it tries to clear the cache then throws this error. I wonder if the issue may be that the plugins are not loaded when rules is invoked via this route, so it is failing, but I don't know enough about this module's organization.
Apologies for the long paste, it doesn't feel quite long enough to warrant a text file upload.
exception 'ReflectionException' with message 'Function rules_data_list_info_alter() does not exist' in [error]
/var/www/site.drupal.dev/docroot/sites/all/modules/contrib/rules/includes/rules.core.inc:1808
Stack trace:
#0 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/rules/includes/rules.core.inc(1808):
ReflectionFunction->__construct('rules_data_list...')
#1 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/rules/includes/rules.core.inc(1726):
RulesAbstractPlugin->getFileName('rules_data_list...', Array)
#2 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/rules/rules.module(424): RulesAbstractPlugin->rebuildCache(Array,
Array)
#3 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/rules/rules.module(383): _rules_rebuild_cache(Array)
#4 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/rules/rules.module(664): rules_get_cache()
#5 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/rules/rules.module(128): rules_plugin_factory('reaction rule')
#6 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/scheduler/scheduler.rules_defaults.inc(20): rules_reaction_rule()
#7 [internal function]: scheduler_default_rules_configuration()
#8 /var/www/site.drupal.dev/docroot/includes/module.inc(866): call_user_func_array('scheduler_defau...', Array)
#9 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/entity/entity.module(875): module_invoke('scheduler',
'default_rules_c...')
#10 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/entity/entity.module(853): _entity_defaults_rebuild('rules_config')
#11 /var/www/site.drupal.dev/docroot/sites/all/modules/contrib/entity/entity.module(1080): entity_defaults_rebuild()
#12 [internal function]: entity_flush_caches()
#13 /var/www/site.drupal.dev/docroot/includes/module.inc(895): call_user_func_array('entity_flush_ca...', Array)
#14 /var/www/site.drupal.dev/docroot/includes/common.inc(7545): module_invoke_all('flush_caches')
#15 /usr/local/share/drush/commands/core/drupal/cache.inc(90): drupal_flush_all_caches()
#16 /usr/local/share/drush/includes/drush.inc(700): drush_cache_clear_both()
#17 /usr/local/share/drush/includes/drush.inc(687): drush_call_user_func_array('drush_cache_cle...', Array)
#18 /usr/local/share/drush/commands/core/cache.drush.inc(143): drush_op('drush_cache_cle...')
#19 [internal function]: drush_cache_command_clear('all')
#20 /usr/local/share/drush/includes/command.inc(359): call_user_func_array('drush_cache_com...', Array)
#21 /usr/local/share/drush/includes/command.inc(210): _drush_invoke_hooks(Array, Array)
#22 [internal function]: drush_command('all')
#23 /usr/local/share/drush/includes/command.inc(178): call_user_func_array('drush_command', Array)
#24 /usr/local/share/drush/lib/Drush/Boot/DrupalBoot.php(46): drush_dispatch(Array)
#25 /usr/local/share/drush/drush.php(74): Drush\Boot\DrupalBoot->bootstrap_and_dispatch()
#26 /usr/local/share/drush/drush.php(11): drush_main()
#27 {main}
Comments
Comment #1
duntuk commentedIf possible, disable and uninstall rules module... Doing so will fix this.
Comment #2
martinpe commentedHaving the same problem.
Man the rules module sure has bugs.
And no, disable + uninstall is no option when so many other modules are depending on it.
Find a solution.
Comment #3
sheldon rampton commentedHere's a patch that fixed the issue for me.
Comment #4
kenorb commentedComment #5
geek-merlinRaising prio as this causes a wsod on cache clears.
Setting RTBC as this looks reasonable and fixes the issue for me.
Here's a trace for further analysis.
Comment #6
casaran commentedThe patch from #3 worked for me.
Comment #7
br0kenNumber of
dirname()with the same argument start increasing.Comment #8
joelpittetI guess it could be
dirname(__DIR__)and save one if that helps @BR0kEN?Comment #9
br0ken@joelpittet it's not critical - that's why I haven't changed issue status. Of course it will not give us tangible performance boost, but it's just a good practice to not execute functions more than once with a single set of arguments.
I think
__DIR__cannot be used since Drupal 7 has declared 5.2 as minimum version of PHP and therulesmodule has no definition ofphpinside its*.infofile which means it's operability works within 5.2 as well. The constant exists starting from 5.3.For instance, we can create a variable, use it and unset it afterward.
Besides of that, I don't like increasing number of includes. There's a
@todowhich assumes module's contributors are going to remove them at all relying on Drupal registry but I can assure that this will lead to errors on existing sites and this issue is a confirmation of what I'm saying.Probably we need to consider the usage of https://www.drupal.org/project/autoload or https://www.drupal.org/project/registry_autoload.
Comment #10
joelpittetOh yeah I forgot
__DIR__was5.3and we expect>= 5.2.5Comment #11
fagoThis issue has not got much comments, what makes me think that not many people have that problem. Thus, I don't think it warants adding a hacky workaround like that.