Illegal string offset 'field' in RulesEntityController->buildQuery() on php 5.4

Try this:

  /**
   * Overridden to support tags and events in $conditions.
   * @see EntityAPIControllerExportable::buildQuery()
   */
  protected function buildQuery($ids, $conditions = array(), $revision_id = FALSE) {
    $query = parent::buildQuery($ids, $conditions, $revision_id);
    $query_conditions =& $query->conditions();
    foreach ($query_conditions as &$condition) {
      // Support using 'tags' => array('tag1', 'tag2') as condition.
if(isset($condition['field']) && $condition['field'] == 'base.tags') { // <-- changed
//      if ($condition['field'] == 'base.tags') {  <--old
        $query->join('rules_tags', 'rt', 'base.id = rt.id');
        $condition['field'] = 'rt.tag';
      }
      // Support using 'event' => $name as condition.
if(isset($condition['field']) && $condition['field'] == 'base.event') { // <-- changed
//      if ($condition['field'] == 'base.event') { <- old
        $query->join('rules_trigger', 'tr', "base.id = tr.id");
        $condition['field'] = 'tr.event';
      }
    }
    return $query;
  }

There is a similar issue against core #1414412: Skip #conjunction key in __clone() method of core/includes/database/query.inc, which may be interesting to read.

this patch worked for me when experiencing the same errors as above. good one PedroMiguel

PHP 5.4 hits again
patch against latest dev

Lets run the tests first, before RTBC

hmm rerolling

any news?

@mva.name Please refrain from asking "any news?". This issue _is_ the news, and you can clearly derive from it what has and has not happened. Posts like yours only serves to waste time from the developers that now need to check the issue once extra.

Please test that patch instead, and _provide_ news, instead of asking for it.

@Letharion, okay, sorry for annoying.
I've just saw that it is no activity for two weeks, when last patch is worked. An think that all participiants of issue have forgetten about it. And that's why I asked metaquestion.

Also, as I said, last patch seems to works fine on 7.x-2.x-dev.
--
Best regards,
mva

I very much doubt people have "forgotten" about the issue, however, there are a great many issues, and others take priority, when mostly voluntary the developers with their very limited time can contribute at all.

The patch has not passed tests yet. There are other failing tests currently blocking this one, so the test suite hasn't even executed yet. It should remain in "needs review" until it gets green light from the test bots.

If you want to move this issue forward, find or file an issue about the failing i18n tests, and help getting that working.

Georgique's patch is trivial and fixes the issue. Not checking whether an array offset exists is a almost a typo in PHP programming.

I hope the bot issue is fixed soon.

The above patch misses what is really happening here.

QueryConditionInterface::conditions() returns an array that contains a string as well as the arrays that we are looking for. That's where the illegal offset is coming from.

Thanks! That patch worked for me. I accidentally updated to php 5.4 dev and got this error on my debian box. For now it works till I figure out how to go back to php 5.3

UPDATE** I restored a copy of my site before applying this patch and the issue appeared as expected. I copied my site to my dev host running php 5.3.1 and the issue went away. A similar issue is happening with the Entity module: http://drupal.org/node/1514764#comment-6070950

Added to RTBC list, since that was what klausi was reviewing. This is a better approach. Still, more confirmations would be helpful.

Patch from #14 works for me with Rules 7.x-2.1 on PHP 5.4

Patch from #14 works for me running PHP 5.4.3 and Rules 7.x-2.1

Works for me too running PHP 5.4 and Rules 7.x-2.1

Works for me too running PHP 5.4 and Rules 7.x-2.1

everybody says it works, yet no one changes the issue status :/

Committed patch from #14. Thanks!

Updating to the 7.x-dev version after the commit immediately fixed the issue for me. Thank you!

Tested on 7-17-2012 with a fresh D7.14 install.

Thanks for testing, rmalcome. There's still lots more patches that need testing so that they can be fixed too! :)

#14 worked for me.