We have a command line installer we use to automate Drupal installations. It has a composer manifest with all the modules and themes we require, and the installer basically just runs composer commands to install all that stuff and then drush site-install. The composer constraints specify the latest version of Drupal. A couple weeks ago it started throwing this error (with the text_default plugin specifically) in the profile installation phase, even though we've made no changes to the profile we use. All I've been able to determine is that there are configs it's trying to install that have this key and that the module installer is showing text_default isn't there. The installer bails at this point but the sites appear to install properly none the less.
Turned aggregation off and back on using drush instead of the GUI and now it works fine. Go figure.
Both sites were recently migrated from D9 to 10.1.5. Works with aggregation turned off, fails with it turned on. Failure appears on both my development environment and production. My local files directory permissions are wide open. If I manually create a css and js folder, Drupal deletes them, so I know it is able to access the files directory. Can't say I understand #comment-15267804 -- doesn't seem to be directly related and anyway that was patched a month ago, unless the patch has not yet made its way into a release. No errors being logged by Drupal or the web server. Nothing in the console either. Both admin theme and front end theme are failing.
Just a moment ago I tested it again and inexplicably the admin theme started aggregating, but the front end theme still did not. Cleared caches and now they're both broken again.
Can't test any of these other patches until a patch for the info file exists, so here's a patch for the info file.
I assume the patch I submitted failed because it has to be applied atop MR8. No idea how to specify that when I upload the patch.
I dunno, it looks similar. Could be.
As you're probably aware, the patch for v2 compatibility is drop dead simple. Including it here. I didn't do the group version check because it sounds like the GitLab thing has it covered.
Verifying this does not work with Group v2. I can install it and the field is available and can be enabled on group content types, but the manage display tab for content types with the field enabled pops an error:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "group_relationship" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 139 of /Users/fm56/Documents/Jobs/aws/hg/stage/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).
On creating new content with the field the Add to Group button churns for a long while but doesn't do anything but logs a similar error:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "group_relationship_type" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 139 of /Users/fm56/Documents/Jobs/aws/hg/stage/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).
I'm thinking it ought to be possible for this module to check what version of Group is running and substitute group_content and group_content_type accordingly. Easier than trying to maintain parallel versions. I'm going to take a stab at writing a patch because I need this module rather intensely.