Node Type Example fails to reinstall

Could you add a little more information about the error? For example, if you get an error message, you can either pasted in the text (best), or do an image capture (second best, since we like to copy and pasted into Google to see if the message tells us something).

I've just tried the following, using an install of Drupal 8.2.x-dev (which is what our test system now uses), using command line installs with Drush:

vagrant@rules:/var/www/drupalvm/drupal/modules/contrib/examples/node_type_example$ drush en node_type_example
The following extensions will be enabled: node_type_example, examples
Do you really want to continue? (y/n): y
 [notice] examples was enabled successfully.
 [notice] node_type_example was enabled successfully.
vagrant@rules:/var/www/drupalvm/drupal/modules/contrib/examples/node_type_example$ drush pmu node_type_example
The following extensions will be uninstalled: node_type_example
Do you really want to continue? (y/n): y
 [notice] node_type_example was successfully uninstalled.
vagrant@rules:/var/www/drupalvm/drupal/modules/contrib/examples/node_type_example$ pushd ../content_entity_example/
/var/www/drupalvm/drupal/modules/contrib/examples/content_entity_example /var/www/drupalvm/drupal/modules/contrib/examples/node_type_example ~
vagrant@rules:/var/www/drupalvm/drupal/modules/contrib/examples/content_entity_example$ drush en content_entity_example
The following extensions will be enabled: content_entity_example
Do you really want to continue? (y/n): y
 [notice] content_entity_example was enabled successfully.
content_entity_example defines the following permissions: add contact entity, administer contact entity, delete contact entity, edit contact entity, view contact entity

This suggests that under at least some circumstances, node_type_example (and also content_entity_type_example; it isn't clear which you did) will install.

So I need a bit more information about what you did that failed. Things we'll want to know:

• What version of Drupal were you using when this happened? 8.0 could well fail. Perhaps 8.1 could fail as well.
• Was this an install of the Node Type Example, or of the Content Entity Example as you set in Component?
• What was the exact error you got when you tried to do the install?
• How did you do the install? (i.e., what did you do in Drupal to do this? Is the install local, or did you install via ftp in the Extensions page?)

Was this your error:

Unable to install Node Type Example, core.entity_form_display.node.basic_content_type.default, core.entity_form_display.node.locked_content_type.default, field.field.node.basic_content_type.body, field.field.node.locked_content_type.body, node.type.basic_content_type, node.type.locked_content_type already exist in active configuration.
Warning message

If so, it means that you installed the module, uninstalled the module, and that when you reinstalled the module, you got this error. If so, I have a suspicion what's up here. Let me see if I can get this properly fixed.

It appears that the yaml files in config/install are declaring the uuid key. This is a definite no-no.

I'll need to set up a new database for my virtual, but I'm guessing that simply by removing these, I'll be able to fix this. I'm not sure how to back this out from an already damaged install (i.e., where you've installed node_type_example already).

@AverilL: Do you mean that the instructions on the examples/node-type-example page are wrong? Because I just tried and they half-way work, so they could definitely use some improvement.

@Mile23: I can reproduce his problem. You can see his problem as so:

1. Start with a clean install.
2. Install the module.
3. Uninstall the module.
4. Try to install the module again. This will fail, with errors similar to what he reports.

This is why I checked the yaml files in config/install for embedded UUIDs: these need to be cleaned up before we check config files in. A config file with an embedded UUID will not auto-remove when the module is uninstalled, and the installer complains in step (4) because it won't let you install the same UUID twice.

I think Drupal is right to leave the content type, and we shouldn't demolish it. That's clearly something the user should do.

So we should figure out the best way to warn users that the content types will remain after they've uninstalled the module.

I think Drupal is right to leave the content type, and we shouldn't demolish it. That's clearly something the user should do.

If we can make the module reinstall, then sure. But if a module is "supplying" a content type, there are a couple of behavior questions you need to ask.

First, if there's content created from a content type, it needs to be hard to remove automatically. I'm fairly sure that the system already does this, but we should verify that this is so. IIRC, a confirm page comes up asking "do you really want to do this". I'm a little fuzzy on how dependencies work in this case, but arguably if the content type is retained, the module that "owns" it should not be uninstallable.

Second, if it's a module reinstalling a content type sees that the content type is already there, should it (1) refuse to install (as we do here), (2) treat installing the content type as optional, and skip this part of the install, or (3) overwrite the content type. (2) or (3) are probably reasonable if there is no content for the type, and (1) the better option otherwise.

In any case, you want the UUID lines removed from config files for a module install. The UUID should be specific to a config type and an install. Remember that if a content type has content, the system will protect us against destroying user data. And if there's no content for the type, there's really no reason not to let the module remove the type and/or modifying it.

I believe there are use cases for installing a module with a UUID, but they are mostly those involving deployment (similar to the way people use Features in D7). But a general purpose module should not do this.

So removing the UUIDs from our config files needs to happen.

I'm not sure how well some of this stuff is documented, but while working on extending the Content Entity Example last year, I got to see how this works in practice.

I just tried to install, uninstall, and then reinstall the node type example having removed the UUID from node.type.basic_content_type, and I'm still blocked from re-installing.

@AverilL links to this documentation: https://www.drupal.org/node/2629550 ..which tells us this:

Note: Be advised that we're adding an enforced dependency to the foobar module. If we don't add this dependency, Drupal will not remove the content type when we uninstall our module. When a site builder decides that this module is no longer required, we don't want to have the content type available anymore.

# node.type.car_brand.yml
langcode: en
status: true
dependencies:
  enforced:
    module:
      - foobar # This is the name of the module we're using for this example

So after we RTFM... :-) the solution might be to add an enforced dependency, which we currently don't do.

We'd then also want to write a test that uninstalls and then re-installs the module to see what explodes.

I just tried to install, uninstall, and then reinstall the node type example having removed the UUID from node.type.basic_content_type, and I'm still blocked from re-installing.

Was that on a clean install? I've found that it just about has to be. That, or you need to delete the content type manually, which you can do via the UI.

Removing a config isn't easy currently. I had thought that Drupal Console had something that does that, but if it did, it doesn't any more. You should certainly use Drush to check that a config installed by a module is removed or not by uninstall. I've done this test on the current Node Type Example, and no, the config is not removed during an uninstall, even if there is not content attached to the content type.

Declaring dependencies certainly isn't wrong. But IIRC, after doing some tests before D8 was released, I discovered that as long as you don't install with UUIDs in the YAML, the system will "remember" if it was installed via config/install, making the declaration unnecessary. But more tests will show if this is (still?) so or not.

This is basically configuration issue which are not getting deleted from Config table on uninstalling the module. Will add suppot to it.

I loved reading the comments :D, @jeevanbhushetty nice work :D

OK, so far so good.

I can verify that when you uninstall the module, the content types go away as well.

Still needs a kernel test to install and uninstall the module, and then check if our content types remain after we uninstall.

We also need to change some of the text for the locked node type, because it says you have to uninstall the module before you can delete it. It should say that the user is prevented from deleting the content type.

Hmm. I just tried uninstalling while there's still content for those node types.

Uninstalling goes fine, and it warns you that your content will be lost, but when you try to edit or view the content there's plenty of kaboom.

Fatal error: Call to a member function displaySubmitted() on a non-object in /Users/paulmitchum/projects/drupal8/core/modules/node/node.module on line 603

For the purposes of this issue, however, we want to be able to uninstall and reinstall the module.

So we have a solution in #17. We also need a test as per #20, except probably a browser test instead of a kernel test.

Unassigning... Re-assign yourself if you're still working.

Thanks.

Added test as we did in #2841840: Error shown while re-installing the simpletest module

Oops forgot to add fixing patch, hence test failed... Adding fix and test both in this patch.

Great, thanks! Committed and pushed.