Enabling Commerce Recurring without Commerce Product installed is causing installation error

Do you see this file in your codebase? https://git.drupalcode.org/project/commerce_recurring/-/blob/8.x-1.x/src...

@netgeek123 so this makes commerce recurring incompatible with Drupal 9?

Added the release blocker tag to keep it in the radar.

I'm seeing this issue also, with the same steps.

Not just Drush, got this error when enabling via the UI, however in my case I did not have commerce_product installed, if I install commerce_product, then install commerce_recurring, no error.

So on one hand this appears to just be a hidden dependency on commerce_product, which is an easy fix; On the other hand it would be great if we could remove that hidden dependency, as I'm not planning to use commerce_product in my implemntation, so it would be nice if the two could be decoupled.

Thanks,
-Aaron

Did a little more digging, in commerce_recurring's config/install folder I found these references to product_variation:

ag product_variation
core.entity_view_display.commerce_subscription.product_variation.default.yml
7:id: commerce_subscription.product_variation.default
9:bundle: product_variation

core.entity_form_display.commerce_subscription.product_variation.customer.yml
8:id: commerce_subscription.product_variation.customer
10:bundle: product_variation

core.entity_view_display.commerce_subscription.product_variation.customer.yml
9:id: commerce_subscription.product_variation.customer
11:bundle: product_variation

If I move those three config files from config/install to config/optional, no error.

What about simply adding the dependency "commerce_product" to the info file?

@deneus18 I don't think that's an ideal solution because commerce_recurring shouldn't need to depend on commerce_product.

Product provides a very specific way to use Commerce, it provides a specific set of Purchasable Entity Types that follow a specific architecture. Recurring has generally been architected in a way that means one should be able to use a different architecture and a different set of Purchasable Entity Types, possibly provided by contrib or custom code.

In my case I have some Purchasable Entity Types that are built in a specific way and have no dependencies on Commerce Product.

I have experienced the same issue installing Commerce Recurring from scratch on a fresh Drupal install - both via UI and Drush, therefore I am updating IS.

UI:

The website encountered an unexpected error. Try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "product_variation" plugin does not exist. Valid plugin IDs for Drupal\commerce_recurring\SubscriptionTypeManager are: standalone in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php). 

CLI:

<

 [success] Installation complete.  User name: admin  User password: t8EgscG89u
zaporylie@drupal-commerce-web:/var/www/html$ drush en commerce_recurring
The following module(s) will be enabled: commerce_recurring, commerce, address, entity, inline_entity_form, token, commerce_price, commerce_order, commerce_store, commerce_number_pattern, entity_reference_revisions, profile, state_machine, commerce_payment, advancedqueue

 Do you want to continue? (yes/no) [yes]:
 > 


In DiscoveryTrait.php line 53:
                                                                                                                                         
  The "product_variation" plugin does not exist. Valid plugin IDs for Drupal\commerce_recurring\SubscriptionTypeManager are: standalone  
                                                                                                                                         

My initial idea is to move the config depending on commerce_product to the config/optional but will have to investigate this a bit closer.

It seems like the reg regression was unintentional and introduced in #3193200: Add an admin-facing page for viewing the details of a subscription. After some manual testing, I stand by my previous statement - moving the respective config mentioned in #9 from config/install to config/optional does the trick. MR to follow.

Why not make commerce_product a dependency and keep the files in config/install?
Aren't they required?

product_variation is refernced throughout the module not just in the config/install files mentioned above.

I am going to leave out the tests as the references are plentiful there too:
commerce_recurring.module:102: * Implements hook_form_FORM_ID_alter() for 'commerce_product_variation_type_form'.
commerce_recurring.module:104:function commerce_recurring_form_commerce_product_variation_type_form_alter(array &$form, FormStateInterface $form_state) {
commerce_recurring.module:142: $recurring_order_item_types = ['recurring_standalone', 'recurring_product_variation'];
commerce_recurring.post_update.php:111: 'core.entity_form_display.commerce_subscription.product_variation.customer',
commerce_recurring.post_update.php:129: 'core.entity_view_display.commerce_subscription.product_variation.customer',
commerce_recurring.post_update.php:146: 'core.entity_view_display.commerce_subscription.product_variation.default',
commerce_recurring.post_update.php:166: foreach (['product_variation', 'standalone', 'license'] as $bundle) {
commerce_recurring.post_update.php:192: 'core.entity_view_display.commerce_subscription.product_variation.default',
config/optional/field.field.commerce_order_item.recurring_product_variation.billing_period.yml:10:id: commerce_order_item.recurring_product_variation.billing_period
config/optional/field.field.commerce_order_item.recurring_product_variation.billing_period.yml:13:bundle: recurring_product_variation
config/optional/field.field.commerce_order_item.recurring_product_variation.subscription.yml5: - commerce_order.commerce_order_item_type.recurring_product_variation
config/optional/field.field.commerce_order_item.recurring_product_variation.subscription.yml10:id: commerce_order_item.recurring_product_variation.subscription
config/optional/field.field.commerce_order_item.recurring_product_variation.subscription.yml13:bundle: recurring_product_variation
config/optional/commerce_order.commerce_order_item_type.recurring_product_variation.yml:9:id: recurring_product_variation
config/optional/commerce_order.commerce_order_item_type.recurring_product_variation.yml:10:purchasableEntityType: commerce_product_variation
config/install/core.entity_view_display.commerce_subscription.product_variation.customer.yml9:id: commerce_subscription.product_variation.customer
config/install/core.entity_view_display.commerce_subscription.product_variation.customer.yml11:bundle: product_variation
config/install/core.entity_form_display.commerce_subscription.product_variation.customer.yml8:id: commerce_subscription.product_variation.customer
config/install/core.entity_form_display.commerce_subscription.product_variation.customer.yml10:bundle: product_variation
config/install/core.entity_view_display.commerce_subscription.product_variation.default.yml::id: commerce_subscription.product_variation.default
config/install/core.entity_view_display.commerce_subscription.product_variation.default.yml:10:bundle: product_variation
src/SubscriptionTypeManager.php:59: unset($definitions['product_variation']);
src/Plugin/Commerce/SubscriptionType/SubscriptionTypeInterface.php:32: * product variations, the ID will be 'commerce_product_variation'.
src/Plugin/Commerce/SubscriptionType/ProductVariation.php:9: * id = "product_variation",
src/Plugin/Commerce/SubscriptionType/ProductVariation.php:11: * purchasable_entity_type = "commerce_product_variation",
src/Plugin/Commerce/EntityTrait/PurchasableEntitySubscriptionTrait.php:14: * entity_types = {"commerce_product_variation"}

Commerce Product is not required by Commerce Recurring and the Recurring framework can be used standalone. MR is now open and ready for review. In addition to moving files dependencies were added where required.

Looks fine to me. It seems we have varying types of support for "Commerce Recurring without Commerce Product," though in practice I bet there are approximately 0 people using it that way. 🤣

Still, if moving this to optional doesn't bother anything, works for me!

I bet there are approximately 0 people using it that way. 🤣

There's at least one in #11 😉

Merged, thank you!