I am using Drupal 8.0.3 and Commerce 8.x-2.0-alpha2.

Steps to reproduce:
1. Enable commerce and commerce_order.
2. Uninstall commerce_order module.
3. Enable commerce_order module then you'll get error message: 'Unable to install Commerce Order, core.entity_form_display.profile.billing.default, core.entity_view_display.profile.billing.default, field.field.profile.billing.address, field.storage.profile.address, profile.type.billing already exist in active configuration.'

Comments

edxxu created an issue. See original summary.

bojanz’s picture

Title: Can't re-enable commerce_order module. » Ensure that removing Commerce modules removes their configuration
Version: 8.x-2.0-alpha2 » 8.x-2.x-dev
Category: Bug report » Task
Priority: Normal » Major

We need to make sure all of our shipped configuration has a dependency on the parent module (commerce_order for modules/order/config, etc). That will cause Drupal to clean up after a module removal. I think that's done automatically for required config, but isn't done for optional config.

czigor’s picture

Status: Active » Needs review
StatusFileSize
new5.29 KB
czigor’s picture

Tested this with installing-uninstalling-installing all commerce modules.
E.g.
drupal module:install commerce
drupal module:uninstall commerce
drupal module:install commerce

I got no complaints about existing config.

harings_rob’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me, I have checked all (sub)modules and enabled + disabled them a few times.

bojanz’s picture

Status: Reviewed & tested by the community » Needs work

I think we went a bit overboard here.

 dependencies:
-  module:
-    - commerce_order
-    - commerce_price
+  enforced:
+    module:
+      - commerce_cart
+      - commerce_order
+      - commerce_price

commerce_order and commerce_price are calculated dependencies, they are fine as they are. We don't need to move calculated dependencies to enforced.
This example needs an enforced dependency on commerce_cart, since commerce_cart provides the configuration.

The rule, which I've just learned is:
Modules providing configuration for types they don't own need to add an enforced dependency on themselves.
For example, cart/config/install/views.view.commerce_cart_block.yml. This is a view, so there's an implicit dependency added on the "views" module.
But there's no dependency on commerce_cart, that's the one that needs to be enforced.

czigor’s picture

Status: Needs work » Needs review
StatusFileSize
new4.53 KB

Thanks for the explanation! I have changed the patch accordingly.

  • bojanz committed fa7f336 on 8.x-2.x authored by czigor
    Issue #2669016 by czigor: Ensure that removing Commerce modules removes...
bojanz’s picture

Status: Needs review » Fixed

Thank you, committed.

Views is supposed to always add a dependency on the providing module (the only config entity that does that), and yet that failed for the Shopping cart block for some reason. I worked around it by enforcing the dependency for now.

This situation is a mess, I've commented on this core issue: #2461513: The ConfigInstaller should add a dependency on the extension used to install the configuration.
Also opened an issue for adding a test to Commerce: #2677932: Add a test for reinstalling Commerce

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.