If you use the Drupal 8 'Extend' page to manage modules, and enable anything, or even just allow the default profile to turn things on for you (the usual case) the module checkboxes are disabled. You cannot turn 'optional' things off.
It's not due to it being required by a dependency or anything, the checkbox is simply locked on, with no explanation of why you can't use it. The checkbox is still there, taunting you with its permanently on status. You want to turn off "Comment" because you are not going to use it? Too bad sucker!

It turns out this is by design

The short answer is - you probably are looking for the "Uninstall" tab found on the "Extend" (Modules) page /admin/modules/uninstall

There is no longer any grey area between a module being on and active vs off and "purged". "Disabled" is no longer a thing. Uninstalling a module means removing all traces of it.

The longer answer is because reasons

A huge debate and amount of thought went into this, with strong talk on both sides.
Reasons for this include :
* Because upgrades of some contrib module don't actually work (and can't be made to work) if upgrading when they are disabled.
* Because data left behind by a disabled module that is later re-enabled causes integrity issues and cruft.
* Some upgrades left behind data loss due to things like unexpected dependencies, plugins or hooks being unavailable at key times - when things were disabled.
.. that issue is several hundred arguments long, so It's unfair to over-summarize.

This change was made possible because the method for upgrading is now shifted into 'migration' (rather than internal upgrading) and configuration management (rather than module configs in database schema)

But things are broken - how can I remove this broken contrib module that now makes the site unusable?

... I'm still trying to figure that one out. The big discussion hints that we are expected to edit config files by hand now...

Can we make this developer experience less horrible?

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.

Comments

Jaypan’s picture

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.

dman’s picture

Yeah. I am deliberately NOT raising this as an issue. It's already been discussed to death. :-)

I'm adding this page here simply for searchers to find, as it killed hours for us yesterday as a bunch of experienced developers doing our D8 core contrib sprint all were convinced that D8 was fundamentally broken with our installs, and we lost ages trying to search for what was wrong.

The idea to fix the DX is just something I came up with as writing this.
If I can turn it into a proper proposal then I'll issue it. In the meantime - this is just my attempt at documenting new behavior that I feel is going to trip up a LOT of folk. We did search first and lost hours - so I write this so that the next victims don't have to.

NikLP’s picture

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.

J V’s picture

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.

lsabug’s picture

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

Appreciate the info. @dman

Emerya.thomas’s picture

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

Jon Pugh’s picture

I went through the same process.

A module won't appear in the uninstall page unless you add a modulename.install file and add a hook_uninstall() to it, like so:


function mymodule_uninstall() {
}

It doesn't even have to have any code in it, the function just has to exist.

This is now a major Drupal WTF!

If "uninstall" is the only way to disable a module, shouldn't it just work for any module?

sigh.

__________________________
Jon Pugh
President
OpenDevShop Inc
http://opendevshop.com
http://twitter.com/jonpugh

hendrik.fuss’s picture

So how do I uninstall a broken module that does not implement hook_uninstall()? I've tried adding the hook, but my module still doesn't show up on the uninstall page. Install Drupal from scratch?

slewazimuth’s picture

I've had success with a couple of methods: First method to try:

Use drush and uninstall the module that way. So if the module you're having the issue with is named apicmd then the drush command would be: drush pmu apicmd

If that should fail...

A more offbeat method if you are using cpanel:

1. Have file manager obliterate the module files.
2. In drush issue a cr command which tells drush to rebuild the cache
3. Manually upload the module files again.
4. Issue the drush pmu command with the module name again as mentioned as first method.

leanderl’s picture

Thanks @Jon Pugh – I wish one could vote in these discussions. This is the short sweet answer that I needed to understand this new Drupal 8 behaviour.

---

dman’s picture

As an addendum to this Admin UX bug...

The first thing I want to do on a new site is disable 'Comment' - not least because the added form takes up half the page.

* visit /admin/modules/uninstall

Once again I am given a checkbox - that is disabled - with no clear prompt about how to enable it.

The message "Field type in use" is obtuse. Luckily I have 10 years experience in Drupal and have the insight to find my way to /admin/reports/fields where I can see what content type has a 'comment body' field and I can go and edit that content type to remove it.
After doing so, it looks like it's possible to uninstall comment module.

A pretty unintuitive set of steps to take though. Personally, and as a developer, I understand what is happening. But as far as site-builder experience goes - Needs more hand-holding OR just being less weird, I think.

othermachines’s picture

Thanks, @dman. Your post showed up right at the top when I googled "drupal 8 modules can't disable". I'm also an experienced Drupal developer so I know where to look for fields, but that's going to be a huge roadblock for newer site builders.

At the very least, if the "Field type in use" were linked to the Fields list that would be helpful.

Screenack’s picture

Your post is most helpful. I agree a more informative notice will be helpful, too. And, I was just bit by a disabled checkbox issue as well.

legovaer’s picture

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!

tnfno’s picture

That is not true if the entity is created with Drupal Console. Right now you can only create a new entity for a disabled module, if the module is enabled the generate:entity:content command will look like it everything is OK, but the table is not created.

See issue here https://github.com/hechoendrupal/DrupalConsole/issues/2204

johnflower’s picture

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'.

lpalgarvio’s picture

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!

Luís Pedro Algarvio
Drupal Linux DevOps
lp.algarvio.org

Jaypan’s picture

Unfortunately this rant will go nowhere, as the Drupal organization does not use or care about the forums. It will only be seen by other users who have no sway in the matter.

Harry Slaughter’s picture

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.

--
Devbee - http://devbee.net/

info@cgfix.com’s picture

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.

Percept’s picture

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.

samgreco’s picture

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.

Sam Moore’s picture

In your shoes, I'd use D7.
Both Ubercart and Commerce are in alpha still, not to mention the constellation of submodules they both need for proper functioning.
D7 will continue to be supported for many years.

Or you could look at Magento...

PS you should probably move this to a new thread, rather than hijack this old one.

samgreco’s picture

My original comment was meant as an example of the problems with not being able to disable modules. Not really about me asking for help deciding which direction to go. So it really kinda does belong here. I am not hijacking this thread.

But thanks for trying to help anyway.

Sam Moore’s picture

Didn't mean for that to sound harsh - sorry. I feel your pain, as I too have obligations to customers to meet.

thomasmurphy’s picture

I shall be taking this for a spin https://www.drupal.org/project/disable_modules

alar’s picture

I'm with you on this one @thomasmurphy

HongPong’s picture

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?

scott@coverclubmedia.com’s picture

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.

calbasi’s picture

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

www.calbasi.net
Ps: If you can not understand me, it's my poor English skills fault :-p

edwinsarabiame’s picture

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)

alanpeart’s picture

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.

Technical Director at The Creative Coop

http://www.creative.coop

alanpeart’s picture

P.S. - and this is strictly the "dirty" fix for someone who temporarily just wants their site to work and to be able to install modules - just comment out lines 232-239 in /core/lib/Drupal/Component/Render/FormattableMarkup.php

This resolved my problem. It might not resolve yours. Caveat emptor.

Technical Director at The Creative Coop

http://www.creative.coop

codeelegance’s picture

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?!?!?