Why can't I uninstall modules in Drupal 8? (Explained)

This discussion sounds like a good one, but it would probably be better off opened as an issue in the Drupal issue queue (on the Drupal download page, right column) than as a forum thread, as most of the core developers don't seem to spend much time in the forums.

I have no idea what's going on with this, but thanks for posting this otherwise I would have probably gone insane. This wouldn't have taken long though, as it's just taken me about 6 hours to set up a D8 box. There's so little info. I absolutely hate the non-docs for this system.

Does this have an issue? It would probably be best to merge the "List" and "Uninstall" tabs and have it automatically do both installs and uninstalls when you hit save.

and all I wanted to do was disable the contact form. Yikes on Drupal 8!

Appreciate the info. @dman

I've made one custom module and It is in list of modules but not in uninstall list.

I bumped into this page while I was creating a new entity inside a module which was already installed. When I tried to test if my new entity was available, Drupal told me (WD with error messages) that he was not able to find the table that I had specified for this entity. Uninstalling doesn't work, because I'm not able to open the modules page (because of the WD with the error messages) and neither does drush pm-uninstall work.

Register a new entity

In order to register a new entity (create the database table according to your details in your entity class) you can simply execute drush updatedb. When executing this command, Drupal will inform you that it found a new entity and that there's a pending update. After applying the pending update, you will be able to start using your entity on your Drupal website!

Thanks for posting this. I thought I'd done something wrong because I couldn't uncheck boxes.
I searched google using 'drupal 8 uninstall module'.

Sorry, but I don't agree with this idea.
For me it's a big f*ck up.

Starts with not considering new or beginner users, continues with disrupting completely the expected behaviour from all previous drupal versions, and ends with making life hard for everyone else!

To be really honest, I'm very disappointed with this approach. Haven't you considered before a new hook for difficult upgrades? C'mon...

I can't believe we need today a module like this!
This is a regression to like, Drupal 4...

And before you comment about being unsafe, the right thing to do, core cannot take responsibility, etc, how about following this problem since the early development releasing D8 only after this (critical and functional) issue was solved? Care to compare now the pros and cons and stability with other platforms? And the credibility?

Sorry about the rant, but the truth has to be faced for what it is! This issue needs all the priority!

After attending Drupalcon NOLA, I became very excited about Drupal 8. After getting home and playing with it a bit, I realize it is nowhere near ready for prime time. It probably shouldn't have been released.

I'm a contractor and I work with many clients, large and small. I could never make a case for upgrading to 8 at this point.

On paper (and in sessions) 8 sounds great. More mature caching; integration of popular open source projects; versionable config management and so on. But in practice, I'm wondering if my D8 fears have been realized. An overly complex hybrid of technologies that not even the core team can wrangle into a shiny new release.

I've been with Drupal for over 10 years and am aware of the well-known shortcomings and quirks of all releases up to 8. I know the previous codebase won't provide scholarly examples for the design pattern pedants. But you could build a stable site with it and when there were bugs, they were generally not difficult to locate.

I'm not trying to be a Debby Downer here, I'm just saying that as a freelance Drupal developer, there's some cause for concern here.

Drupal's historic friendliness towards developers resulted in a lot of creative product. I'm afraid Drupal is now eschewing the developer in favor of the enterprise audience that supports the huge Drupal vendors that popping up at every turn.

This seems like a good idea and a bad one too. Some times when things go wrong, disabling a module is the way to get back into the admin to make a correction. But if we uninstall the module and it's data, then a small bug will set us back if we don't have a backup.

Wow, as a highly experienced Drupal Site-builder/Themer for 6 years, I was expecting to "jump in" at "medium level" Drupal 8 config. Turns out I'm not even able to uninstall a module anymore without searching google. And not being able to simply disable a module anymore without losing all the config is also mind-blowing.

I have been a Drupaler for over 9 years now. I am basically a site builder/themer.

D7 had it's early frustrations. But nothing like this. With D7 and prior, if something was causing issues, you could disable modules one at a time and figure out where the issue was. But now?

So I am currently deciding on a platform for a large wholesale eCommerce site. I really wanted to use D8. I have installed both Ubercart and Commerce on two VMs. Or I should say, attempted to. A whole lot of issues with BOTH. For instance: Ubercart didn't create it's tables correctly for the Order module, but went ahead and installed the next handful of modules that required it. So now I am uninstalling, one at a time, to get that module uninstalled and reinstall. But it won't uninstall now. I get:

"The website encountered an unexpected error. Please try again later." I can see my end users getting that message...

Drush pmu doesn't work. Gives me a litany of errors, because none of the stuff Order needed to do on install got done.

So what if I had a functioning store? And installed, say a new Coupon module when it came out and it caused problems. And say that it could be interaction with another module. I uninstall other, existing modules to try and find the interaction problem, and a bunch of configs get zapped? Really?

For the first time in 9 years, I am considering another platform. And I HATE Wordpress with a passion.

But I can't, in good conscience, build a D8 eCommerce site today. Even if it's not going live for months. Because this feels like it is so far off from being even usable for end users. So do I stay with D7? Or is it time to start looking elsewhere? Because anything but a basic D8 site, for me, is asking for trouble.

The grayed out checkboxes need to have a popup telling you to go over to the Uninstall modules tab. This would resolve the situation for most users. Is there a bug thread on this?

This new structure is a huge pain in the butt. Took me a while to figure out why everything was grayed out. Only after finding this post I realized this is the new way. I would have to agree this is not a good solution. A hint or removal of those check boxes would be the least you can do.

What boggles my mind is how I'm able to see some disabled modules right now, but once I enabled there for the first time you're only left with uninstalled lol.

Structure and settings will be all lost and this will only mess you over on a large scale module with a plethora of settings to setup. I guess this is why you're forcing the removal to clean the settings out. That is a massive deterrent in moving to 8. I highly suggest bringing back the 7 route for ease of use.

Edit: Uninstalled a few modules and site is now dead on all admin pages...A pile of road blocks while trying to uninstall modules and many errors coming from the uninstaller not properly cleaning things out.

Thanks @dman for your post ;-) I really though something was wrong on my site...
This issue is really counter-intuitive...

Entrar en la tabla system de la base de datos que contiene la instalación de Drupal.
Encontrar el registro cuyo campo filename contiene modules/update/update.moduley editarlo.
Cambiar los campos status, throttle y bootstrapy ponerlos a cero.
Grabar los cambios (Save)

Longtime professional Drupal user and developer here, since Drupal 4.6, with a large number of D7 sites under my belt. I felt like I must be going crazy but I have tried twice now simply to get a reasonably complex Drupal 8 site going with a few of the contrib modules that are essential for the type of sites I work on. This is my second full day of trying simply to complete the installation process of modules. Everything I do results in more error messages (one of which I googled to end up on this thread). My company are desperate and keen to move on to using D8 but it's simply impossible in this state. I don't understand what has happened but I thought I would share the view of a frustrated professional. I am not denigrating anyone's efforts here and I don't contribute code to core. We are dying to get our clients on to the latest and greatest tech, and there is so much good stuff about D8. But faced, after 6 hours, with no better option than deleting everything (everything!) and starting over, I have to report back to co-directors "nowhere near ready yet, let's check back in another 6 months" which is roughly what I said a year ago.

So, let me get this straight: After THOUSANDS of hours of discussions, architecture redesign, and core development for D8, we're left with a module list where I can ENABLE a module, but to reverse that decisions, I have to go to an UNINSTALL tab. Gosh, that makes total sense. How could I have missed THAT?!?!?

I am confused. According to this discussion, uninstalling a module from the uninstall tab removes it completely and there is no way to disable the module. When I attempt this feat, the module is disabled, and if I try to install a previous version or a dev version, I amm told that the module is already installed. I would happily use Drush, but after going to the trouble to SSH into my cPanel, I am told I don't have a "high enough bootstrap level", and I have never seen anything that tells me how to get Drush working in that environment.

There are configuration files left after the module is uninstalled.

This module allows you to delete the configuration files: https://www.drupal.org/project/easy_install

I think they should have:

Disabled (which disables and leaves configuration files)

Uninstall (which disables and deletes configuration files)

And I think there should be a uninstall --force to force the uninstall to complete regardless of errors. This would be upto a developer to use at his/her own risk.

Right now I am battling a module which did not install properly. A table is not installed. now i cannot uninstall the module.

Which configuration file would I have to edit for that?

After attending the last few DrupalCons, I felt like I've been in the "wrong" by not focusing more energy on Drupal 8. But then I run across something like this, and I feel that maybe staying in D7 has been a good move. Fortunately the site I'm currently building is rather simple, so I think I can still pull it off in 8, but it's a bit bizarre that I cannot easily disable modules that I'm testing, with the idea that I might attempt to use and/or fix issues as I go.

Frugal 8 does not support uninstall on any module as far as I know. I would ditch it and roll back to 7. 

Somehing to do with uninstalled tables might be needed later by created nodes. It's a design inherent to core.

So to follow up on the original post, in particular:

I suggest we really need to replace the "disabled" checkbox UI with (at least) an explanation of why you can't disable modules, and how you can uninstall them (and what those implications are). Right now it behaves like a broken UI, a buggy form that was accidentally crippled - because giving a user a checkbox and then telling them "this isn't really something you can change" is obnoxious.

Here's a new d8 module you can try out: module_checkbox_clean

Sorry, it doesn't fix everyone's gripes with d8. :) ...But, it does help out a bit with the UI on that page.

The various references to database and config in this thread led me to export the database to a databasename.sql file then open the file in Dreamweaver and do a search for the module name I could not get to uninstall.  The search showed me all the tables in the database with references to the module and I was able to remove the references from the records in each table and get my sites cleaned up.  I would not recommend doing anything to the database without first backing it up (which I did) but this was a fairly quick way to get my issue resolved.

As a long-time software developer, but beginner to Drupal 8, this confused me for longer than I'd like to admit. I think that checkboxes afford (i.e., suggest, solicit) clicking. I can't think of another user interface with informational checkboxes that are not meant to be clicked in any configuration.

oh well, where to start?

it's 2021. October.
been 2+ years since i stopped developing or using drupal.

and i get this notification in email, to an odd thing we found out with Drupal 8.
i hope, for everyone, that this bug, not a feature, has long been dealt with.

otherwise its going to be very, very embarassing. should had been a priority.

PS: editor here is broken.