Not working for Entity-Selection "Views"

subscribe

I've had this same issue and, after messing around in CER's code, I've discovered that Views *is* actually supported. The problem here is just that the admin screen doesn't show reference fields that are powered by Views, so you can't tell CER to watch those fields. I'm writing a patch for the admin screen to support this and will post it tomorrow.

Attached is the patch I've written to add basic support for Views-based entity reference fields. This patch doesn't validate the view in any way to make sure it's returning the right sort of entities; it just treats the view like a magic box and assumes everything will work fine.

Obviously, this won't suffice as a permanent solution, but as chertzog mentioned in this issue, this is a somewhat more complex problem than it appears at first blush. So, caveat emptor: this patch should be seen as a stopgap solution for the time being (I needed this functionality on a client site, and I needed it quickly).

There is a bug in my patch that can cause PHP timeouts. To fix, change line 50 of cer.admin.inc from this:

if ($field_is_views || $second_field_is_views || ($field['bundle'] == $second_field['reference'] && $second_field['bundle'] == $field['reference'])) {

to this:

if (($field_is_views && $second_field_is_views) || ($field['bundle'] == $second_field['reference'] && $second_field['bundle'] == $field['reference'])) {

I have created a newer, better patch for this. Please, disregard my patch in #3!

This patch is a pretty big one and makes a number of changes. I made major modifications to the admin form in cer.admin.inc and other, less major modifications to various parts of cer.module. I know this oversteps the boundaries of "Views support"; I apologize for my overzealousness.

That being said, here's a summary of what I did:

1. The CER settings form now uses Field API info functions to get information about entityreference fields and their corresponding instances. Entity reference fields that use Views as a backend are fully supported - if the view being used filters by entity bundle (only through static filters, NOT contextual ones), that filter will be applied to the corresponding reference. This is all in the _cer_get_target_bundles() function in cer.admin.inc.
2. Did some miscellaneous code cleanup. Help text for the admin forms was moved into hook_help(), and the function to format a CER label was made into a theme function (I found cer_format_label's output very difficult to read, considering that I had 243 corresponding references on the site I wrote this patch for!) A few crufty variables and elements were removed from the admin form. The update form's validation function was also removed and replaced with a #required flag in the form builder function.
3. Fixed various spelling and grammatical errors.

I hope this proves useful. Again, I apologize for changing more than is in the scope of this issue; I'd be happy to clean the patch up and split it into distinct, appropriately-sized pieces if this gets committed.

It has been discovered during internal testing that Views support is still kinda broken in CER. The patch in #5 only fixes the admin screen and shows potential references with a Views backend, but actually making those references can cause the references to end up in the wrong field. I'll take this back to the drawing board.

I think the issue I mentioned in #6 should be fixed by the patch at http://drupal.org/node/1971250.

As I explained at http://drupal.org/node/1945864#comment-7263076, the real problem here is, I believe, CER not validating its corresponding references through Entity Reference before saving them to the database. The patch I mentioned above implements that.

Fixed in the 2.x branch (you can use git to get a copy of it).

7.x-1.x is deprecated.