Note: I have not turned off all contrib modules to find a conflict, as I believe it's generic to menus/users on the init event (system.rules.inc from line 17).
How to duplicate error:
- Create an active triggered rule on the event Path>"User is going to view a page"
- Apply any harmless action, like "Show a configurable message on the site"
- Add a condition, like "Check a truth value" and set it to return false
- Go to a 404 path
For me (and confirmation of this behavior would be appreciated) this results in a "Fatal error: Unsupported operand types in /var/www/includes/common.inc on line 1592" white page, instead of triggering drupal_not_found(). Based on a test in IE8, though, I believe a 404 HTTP status is returned. Line 1592 in common.inc operand errors occur when the $options argument is not an array. I backtraced it to menu.inc line 1614, which is within menu_get_active_breadcrumb().
One weird quirk that I can't explain is that combinations of user conditions and user actions will sometimes allow a normal 404 to occur, regardless of how the conditions evaluate. Could rules_init() require a delay of some sort?
Thank you for your time and consideration.
Comments
Comment #1
ao5357 CreditAttribution: ao5357 commentedWith further testing on my staging site, mainly activating and de-activating modules, I was able to reliably create the error condition and remove it by activating and de-activating the token module. I will test this on my vanilla MAMP install over my lunch break to confirm.
Comment #2
ao5357 CreditAttribution: ao5357 commentedDuplicate of http://drupal.org/node/1184782
Comment #3
ao5357 CreditAttribution: ao5357 commentedWait, no it isn't. That's a different module.
Comment #4
mrogers CreditAttribution: mrogers commentedWere you able to make any progress on this? I'm having the same issue.
Comment #5
ao5357 CreditAttribution: ao5357 commentedI haven't made progress, unfortunately. It seems to be consistent to trigger on my live and staging sites, which are ubuntu boxes with apache and using a modified Zen theme.
The same combination of modules on MAMP with Garland don't trigger the same issues. I will try to isolate theme and server differences to try and find a culprit. Until then, I'm using user conditions to minimize the bug's effects in production.
@mrogers — could you elaborate on your experience with the issue?
Comment #6
mrogers CreditAttribution: mrogers commentedThanks. I have posted this issue here as well: http://drupal.org/node/1184782 but reading your experience above, I'm not so convinced that it's an issue with Check Path anymore. I'm running a Zen sub-theme as well, but changing to Garland doesn't resolve the issue for me. The server is IIS 6.
I have a rule set up like so:
This works perfectly when the user visits "my-target-path".
However, if the user tries to access a url that results in a 404 or 403 error (which I have set to display different nodes via 'admin/settings/error-reporting') the following error occurs:
This doesn't happen if 404 and 403 are left as their default pages. It also doesn't happen if the Token module is disabled.
Let me know if I've left out any useful info!
Comment #7
mrogers CreditAttribution: mrogers commentedAn update. As I stated above, the error only occurred when a custom 404 error page is defined, via /admin/settings/error-reporting.
On the default 404 error page, primary links and blocks are always disabled. However, I just used the module 404 Blocks to add primary links to the default error page, and now the "Unsupported operand types" whitescreen error is triggered with the default error page as well. If I disable the "404 Blocks" module, the error goes away.
So it looks like this must be related to the menu system or blocks..?
Comment #8
axroth CreditAttribution: axroth commentedI also ran into this. Can confirm #7 post.
I first tried this: http://drupal.org/node/739158#comment-4028274 it worked for me, but hacking core I don't like.
Trying to solve this with a rewriteRule in htaccess.
Comment #9
ao5357 CreditAttribution: ao5357 commentedI also have blocks appearing on my 404 pages, via a theme function rather than the 404 Blocks module, but it's a custom 404 page nonetheless.
Nice catch @mrogers!
Comment #10
chey CreditAttribution: chey commentedI have confirmed this issue as well.
If I disable the token module I get the following:
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'token_rules_input_evaluator_apply' was given in /srv/web/drupal/sites/all/modules/rules/rules/rules.input_evaluators.inc on line 55.
If I re-enable to token module the warning goes away but the original problem still exists "Fatal error: Unsupported operand types in /srv/web/drupal/includes/common.inc on line 1592"
Comment #11
Kcannick CreditAttribution: Kcannick commentedThis issue has just wreaked havoc on the last two months of my life. Has there been any progress on this aside from hacking core.
Comment #12
phantomvish CreditAttribution: phantomvish commentedany updates on this ? I faced the same issue.
Comment #13
TR CreditAttribution: TR commentedDrupal 6 end of life was 24 Feb 2016. Drupal 6 and Rules 6.x-1.x are no longer supported as of that date, and no bugs with those versions will be investigated or fixed.
If this issue is still a problem in the Drupal 7 or Drupal 8 version of Rules, please open a new issue with complete details of how to reproduce the bug.