fix entity support for non-node entities

There are a few RTBC patches in the issue queue that should help, please give them a try and report back.

Definitely something funky going on with non-nodes. At the very least, the 'Do not count references from unpublished nodes." definitely doesn't apply if the relationship is strictly user to user or term to term.

Also the 'bundles' multi-select in the field configuration is assuming nodes as well. It's likely we need something more like entityreference does itself with both an entity AND a bundle select.

Seems like a lot of little issues are cropping up because it's too node centric still. Feels like a major to me.

holy smokes, you'd think after nearly a decade I could work the issue queue correctly, lol.

Entityreference does some pretty involved custom plugin behaviors to create that fancy ajax dependent entity/bundle select setting. It's not something that can just be ported over and not likely something I have time for any time soon.

I'm trying out a much simplified approach and would love some feedback:

It's not pretty, but its a start. Let me know what ya'll think.

Actually, the first step in the is process is to get rid of all remaining node specificity. This patch does that.

Also note, preliminary testing indicates that counting of references on terms and users now works.

I think the only remaining todo is how to handle when an er field occurs on multiple entity types which is what #8 is attempting to address.

Note that currently it counts within the entity type of the erc field.

Figuring out the interface is pretty simple-- #8 above is working quite well.

However, I'm having difficulty figuring out how to rewrite the db_query to properly do the count. Any ideas/suggestions/patches would be most welcome.

Use a combination of the field's settings to know what it's pointing to, and then EFQ to get a count for those entities based upon field conditions?

I agree with Damien.

Also, if I understand what you're saying, ideally the *Entity/bundles to count* that are available in the config screen's multi-select field should be limited to the ones configured on the entity_ref field(s) that are selected, and you're saying you don't have time to implement an ajax interface that updates the list to limit to only the ones selected, so you're just listing them all.

So here is a question:

Does the *field config* have to expose the option to count certain entity types/bundles? Or could the types/bundles to include in the count be on the field *display setting*? I don't know the underlying architecture of the module well enough to know if the count is being cached in a way that it cannot be calculated "on the fly" from display settings.

This would certainly make things more flexible: imagine configuring views, adding the count field, and selecting the things you want to count, and decide if they should be broken down by type/bundle, etc. Sorry if i totally blew your scope! hopefully not your weekend :P

I actually already looked into converting the existing code to use EFQ, but the "UNION ALL" (for multiple fields) prevents that (EFQ doesn't support unions) and is likely why it was written with db_select instead of EFQ in the first place.

Also, I'm not sure the ajax comment is really relevant any more. I can envision use cases for having different entity/bundle combinations here (imagine wanting to count Node/Article and Comment/Article comment for instance), and the ajax would simply limit the bundles to a particular entity type the way entityreference currently does. So while my current implementation isn't very 'attractive', it's actually fully functional for the most use cases.

Regarding doing the count distinction on output rather than input-- that's definitely an interesting option. It can't be done that way as is-- the module doesn't store that info so the schema would have to change. The one thing that does bother me about it is that we would be doing a lot of tracking for what could be a giant amount of conceivably unnecessary data-- imagine a site with thousands of articles but only a few pages and it's only the page counts that matter. In order to provide maximum flexibility for deciding what to display on output, we need to track and calculate ALL of it.

The one thing that does bother me about it is that we would be doing a lot of tracking for what could be a giant amount of conceivably unnecessary data-- imagine a site with thousands of articles but only a few pages and it's only the page counts that matter. In order to provide maximum flexibility for deciding what to display on output, we need to track and calculate ALL of it.

That is a fair point. Performance is a good reason not to do this, and I guess outweighs any potential benefits of ease of use on the site-builder. After thinking about it a bit, I'd suggest forgetting this idea for now. :) Proceed as originally planned! Do you have what you need? Or still trying to figure out architecture issues?

Still trying to figure out the best way forward for altering the queries to account for entity type in addition to bundle.

The $options array now looks like this:

$options =  array(
  'node-article' => 'Node / Article',
  'node-page' => 'Node / Basic Page',
  'user-user' => 'User / User',
  'taxonomy_term-tags' => 'Taxonomy term / Tags',
  'taxonomy_term-other_tags' => 'Taxonomy term / Other Tags',
  'custom_entity-custom_bundle' => 'Custom Entity / Custom Bundle',
  'custom_entity-user' => 'Custom Entity / User',
);

Which can be easily parsed into both $allowed_entities and $allowed_bundles arrays.

However, we can't do:

$query->condition('er.entity_type, er.bundle', array($allowed_entities, $allowed_bundles), 'IN');

Because a bundle could possibly have the same name on different entities. Using the $options above, we might need to count "User / User" & "Custom Entity / Custom Bundle" but not "Custom Entity / User".

I'm sure I'm missing something simple, but I'm just not seeing an elegant way forward.

1) I would go with a colon instead of a dash to separate them, because it is clearer to read and safer to explode.

2) Add a condition for *each* bundle/type combination. See tutorials on using db_or() and db_and()

// TOTALLY UNTESTED PSEUDOCODE
$db_or = db_or();
foreach ($selected_options as $option) {
  list($type,$bundle) = explode($option, ':');
  $db_and = db_and();
  $db_and->condition('er.entity_type', $type)->condition('er.bundle', $bundle);
  $db_or->condition($db_and);
}
$query = .......
->condition($db_or)
->execute();

brilliant! If it were any more obvious it would have bit me. Sometimes the most obvious methods are obscured by sub-conscience desire to over-engineer. I was waaaayyyy over thinking this, lol. I'll post back when I have an update patch.

Thanks jwilson3!

Lets move this into a separate issue focused on expanding the functionality: #2794921: Allow count field to be on a different entity type