When building a view to display some recurly data I created a relationship to 'Recurly Account from User' and when I did suddenly my view broke and I was receiving the following errors:
Warning: Invalid argument supplied for foreach() in views_join->build_join() (line 1551 of /var/www/html/docroot/sites/all/modules/contrib/views/includes/handlers.inc).
Warning: Invalid argument supplied for foreach() in views_join->build_join() (line 1551 of /var/www/html/docroot/sites/all/modules/contrib/views/includes/handlers.inc).
When looking into this in handlers.inc I can see that $this->extra is expected to be an array. Using dpm() to inspect some of the data structures used by other views integrations I confirmed this to be the case. Other modules are presenting $extra as an array like so:
$this->extra = array(
array(
'field' => 'entity_type',
'value' => 'users',
),
);
I noticed that in recurly/views/recurly_entity_owner_handler.inc and recurly/views/recurly_entity_owner_reverse_handler.inc that $extra was being defined as a string as below:
$def['extra'] = sprintf("%s.entity_type = '%s'", $alias, $def['base type']);
This causes the relationship to fail. This needs to be converted to use the array structure as mentioned above.
Comment | File | Size | Author |
---|---|---|---|
#10 | recurly-views_relationships-2895500-10.patch | 1.5 KB | apotek |
#6 | Screen Shot 2017-07-18 at 4.48.00 PM.png | 78.87 KB | owenbush |
#2 | recurly-views_relationships-2895500-2.patch | 1.44 KB | owenbush |
Comments
Comment #2
owenbush CreditAttribution: owenbush commentedAttached is a patch to address this issue for both of the custom field handlers.
Comment #3
markdorisonComment #4
markdorison@owenbush These changes look good, and seem to work when in place, but I was unable to reproduce the error you describe. Could you provide an export of a test view so that I can see this issue?
Comment #5
markdorisonComment #6
owenbush CreditAttribution: owenbush commentedSure no problem. I set this up and when I visit the URL /test-recurly-view I see a couple of errors. They are also in watchdog:
And just in case it is of any relevance I am using the following versions:
Views: 7.x-3.16
Recurly: 7.x-3.0
Comment #7
markdorisonI tested with Views 7.x-3.16 and Recurly on both 7.x-3.0 and 7.x-3.x-dev; still unable to reproduce. I am going to leave this open for a bit and see if someone else can reproduce the issue.
Comment #8
apotek CreditAttribution: apotek commented@markdorison This thread relates to this issue: https://www.drupal.org/node/2866370
I just noticed it myself. Two symptoms:
The views api now requires the "extra" parameter to be an array rather than a string. However, they don't seem to specify that it has to be an associative array.
In any case, I am going to try to apply this patch to our codebase to see if it will remove some 504 and 502 errors we are getting since updating views.
Comment #9
markdorison@apotek Great. Let us know if this works for you and we will get it committed. Appreciate the help.
Comment #10
apotek CreditAttribution: apotek commentedI found that the previous patch created some PDO exceptions. The recurly module does some very specific things with regard to the the table aliases here, so I decided a possible fix would be to explicitly set the 'table' property of the array, based on what the old version of recurly was doing in the string.
The old recurly code explicitly sets the table in one case (reverse handler) to an *alias* rather than a table name.
And in the other case (the non-reverse handler), the old code sets the table to the value of $def['left_table'] (which is probably what the views module defaults to anyway).
In any case, the patch I have attached sets the table property explicitly based on what this module was defining the relationship to be rather than leaving it up to views.
I might note that it appears, based on latest views code, that one can also send the old string as before, as long as it is wrapped in an array (which falls into the
else if is_string()
part of the views module code. ... But I did not test this approach.In any case, patch 10 here is giving us decent results so far. We'll send this through QA and see if anything else breaks horribly, but would be interested in others' results as well.
Comment #11
apotek CreditAttribution: apotek commented@markdorison I wasn't sure whether the latest patch has passed review, so I was hesitant to put this into status RTBC. I can say that we have been using this on one application in production for two weeks. Does that prove anything? No. Just that our use case is certainly fine with it. Would be nice if this could at least pass review, and then see if anyone else has any issues here.
Comment #12
markdorison@apotek This looks good in my testing. Thanks for your feedback from production.
Comment #14
markdorisonComment #16
apotek CreditAttribution: apotek commentedThis seems to have been committed to 7.x-3.x-dev, and there is no upcoming release on 7.x correct?
Comment #17
markdorison> and there is no upcoming release on 7.x correct?
@apotek Do you mean 7.x-3.x or a different 7.x branch? We can definitely cut a 7.x-3.x release. As for other 7.x branches, it has been over 2 years since either of them have been touched and they have been marked as "unsupported" but I suppose if there is a desire/need to get certain commits on those branches we could.