Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Notice: Use of undefined constant RULES_ADMIN_SET_PATH - assumed 'RULES_ADMIN_SET_PATH' in include_once() (line 11 of
/sites/all/modules/rules/rules_scheduler/rules_scheduler.module).
Notice: Use of undefined constant RULES_ADMIN_PATH - assumed 'RULES_ADMIN_PATH' in include_once() (line 11 of
/sites/all/modules/rules/rules_forms/rules_forms.module).
This seems to be about both rules_forms and rules_scheduler so I started with the scheduler.
Comment | File | Size | Author |
---|---|---|---|
#10 | 1103076_reduce_notices_different_weights.patch | 949 bytes | jhedstrom |
#7 | 1103076_reduce_notices_different_weights.patch | 1.24 KB | jhedstrom |
#3 | 1103076_reduce_notices_different_weights.patch | 993 bytes | greggles |
Comments
Comment #1
klausiLooks like the Rules module is not enabled or the scheduler has a lower weight and gets included before Rules itself.
Comment #2
gregglesGood idea!
So, I can see now why rules_scheduler is throwing this notice, but not rules_forms. Any ideas?
Comment #3
gregglesThe attached patch helps handle these scenarios.
Comment #4
klausiThis rather solves the symptom, not the underlying problem. The info-files of rules_scheduler and rules_forms clearly state that they depend on rules, so the module system needs to load them first. Either we are dealing with a core bug here or something in your Drupal installation is messed up.
Comment #5
gregglesPerhaps so, but that's not how core works and it still doesn't work like that in Drupal 7 and maybe not Drupal 8.
Pushing this off onto core feels like a cop-out to me, though I don't know enough about why the weights are this way on this site to say that it is "doing it properly."
Comment #6
klausiAh, facepalm. The path constants are defined in rules_admin, which is not activated on your site. Using the scheduler without the Rules user interface has obviously not been a use case for many people.
I suggest that we check in rules_scheduler.module for RULES_ADMIN_SET_PATH and hard code the path if it does not exist.
Comment #7
jhedstromRe-rolling the patch for p1. Also, bumping to major since this, in combination with drush, syslog, and NOTICE level error reporting, can result in corrupted and partially built theme registries, since the theme registry is built and cached in the middle of module_load_all().
Comment #9
apadernoComment #10
jhedstromOops, here's a patch that actually applies.
Comment #11
fagohm, we should not expose any UI in the other modules too if rules_admin is disabled, i.e. let's wrap hook_menu implementations in a module_exists('rules_admin') check. That way the constants shouldn't be needed any more either.
Comment #12
kenorb CreditAttribution: kenorb commented(removed)
Comment #13
Dane Powell CreditAttribution: Dane Powell commentedI do believe, like jhedstrom, that this is quite a bit more serious than it seems- I was getting a ton of unexplained WSODs, and bizarre theme-related errors (like update.php trying to use the site theme instead of maintenance theme) until I simply enabled the Rules Admin UI.
Comment #14
ShaneOnABike CreditAttribution: ShaneOnABike commentedThe patch above actually worked for D6.. would it be possible to at least release that patch for D6 users and then find a more appropriate solution for D7/8?
Comment #15
TR CreditAttribution: TR commentedD6 is obsolete and no longer supported, so this will not be fixed in Rules 6.x-1.x at this point.
The RULES_ADMIN_SET_PATH and RULES_ADMIN_PATH constants are not defined or used in the D7 or D8 version of Rules.