Add a getPluginIdsByEntityType() method to src/Plugin/GroupContentEnablerManager

This assumes there can only be one plugin for a given entity type (and bundle), which is not the case. It's perfectly valid for 2 plugins to serve the same entity type, but it would get weird if both had entity_access set to TRUE.

You could have GroupMembership alongside GroupMemberInvite for instance, where both add users to groups without adding any entity access.

+++ b/src/Plugin/GroupContentEnablerManager.php
@@ -217,6 +217,24 @@ class GroupContentEnablerManager extends DefaultPluginManager implements GroupCo
+  public function getPluginIdByEntityType($entity_type_id, $bundle) {

Would have to be getPluginIdsByEntityType and $bundle would have to be optional. It would suck to have to provide a bundle for entity types that have none. And even if the entity type has bundles, the plugin could choose to ignore them (you don't have to specify a bundle in your plugin and then it would work on all bundles).

That said, I'm not entirely opposed to adding this to the base module. It's the fact that this would be the first of its kind that has me hesitating. I'd hate for the manager to become bloated with these types of getters over time, even though I can't think of a better place to put them than the manager.

I'm in the process of reducing the obscene amount of bloat in the plugins, so I'm not keen on adding bloat elsewhere without giving it some thought first :)

Minor nitpicks.

1. +++ b/src/Plugin/GroupContentEnablerManagerInterface.php
   @@ -102,6 +102,19 @@ interface GroupContentEnablerManagerInterface extends PluginManagerInterface, Ca
   +   * Returns the content enabler plugin IDs for a given entity type and bundle.
   

   For a given entity type.

2. +++ b/src/Plugin/GroupContentEnablerManagerInterface.php
   @@ -102,6 +102,19 @@ interface GroupContentEnablerManagerInterface extends PluginManagerInterface, Ca
   +   *   The optional entity bundle ID.
   

   (optional) The entity bundle.

Need to make some minor changes/fixes to Group next week for the Subgroup module, will try and have a look then.

Seems like I had a similar idea over at #3134072: Implement the query access handling for grouped entities, so depending on how that goes, I might commit this at the same time.

This should be perfectly unit-testable, so maybe GroupContentEnablerManagerTest?

That said, the patch looks good, but because of the complex if-statement we might want to test all possible scenario's so nothing breaks if some patch in the future changes the statement ever so slightly.

Given how you could work around it for now, it's no longer a blocker and I'm targeting it for the next release.

Cross-posting here: #2907838-21: Adding members to group in bulk

@dww
+1 For routine that does: Given entity_type & bundle return group_content plugin_id.


As in:
id: group_content_type_00cd4145804c3
content_plugin: 'group_node:xxx'
used by group_content_field_data.type

Request withdrawn.
For anyone dealing with issue of trying to triangulate group_content plugin given entity_type and bundle.

$manager = $container->get('plugin.manager.group_content_enabler');
$manager->getPluginGroupContentTypeMap();

Man would this be useful right about now... i'd even accept something at returns an array of plugins as I could reliably just grab the first!