I inadvertently installed the core search module when I already had the search api installed and now I have errors. I don't know if Search is the real problem but I need to uninstall modules to find what is causing the problem. The page, /admin/modules/uninstall, returns HTTP ERROR 500. It's a pretty white screen with ugly text, I think this is called, WSOD? <I tease. Laughing keeps me from screaming.>

The Drupal 8 database is a complete overhaul from Drupal 7, where setting status to 0 for a module would turn the module off. Unfortunately, over time, orphaned modules and broken pieces would lead to fatal errors of unknown causes and now modules are installed and uninstalled, rather than enabled and disabled. It's great the that 8 doesn't have that orphaning "feature," but where is the emergency back door to uninstalling a module?

Am I stuck with rebuilding a database? I was just getting started with this one, so I can rebuild it, I have the technology, but I don't want to and if I do, I still need to know how to fix my "inadvertent" errors when they occur.

Thank you!

Comments

vm’s picture

first thing to do is try to obtain an error (check apache and php logs).

Also worth trying to get an error to print to screen see https://www.drupal.org/node/158043

WriteCo’s picture

It was an http error, so there were no errors in the server logs. I could not access Drupal error logs because those relied on search to produce lists and that functionality was what threw errors.

vm’s picture

a 500 error is an interal server error in spite of the http.

Drupal error logs can be obtained from the watchdog table of the database but as the error is coming before drupal is loaded, I doubt anything useful will be found there.

The suggestion remains open to get an error to print to screen using the link I've provided.

dibyajyoti.mallick’s picture

Hi,

First of all you can enable error log form back end so that you can understand the actual error and short it out.

Admin > configuration > development > performance > logging & error  "select all message" and save it.

You can also uninstall module by using Drush command :

https://www.drupal.org/docs/8/extending-drupal-8/uninstalling-modules

Thanks

WriteCo’s picture

Every page that produced a list would break and I could not access the Drupal error logs. I suspected it was a battle of the search modules. Drush is not available on my shared hosting. It took months to get them to give me access to Composer and that requires an annoying workaround to use but composer works, now. Drush will have to wait.

vm’s picture

You're running yourself out of options. Suggest pulling a copy or your database and loading it on a localhost with a copy your website. Then install drush and utilize its command line to try and disable the module you believe to be the cause of the issue. I'm not entirely convinced this issue is only because of the enabling of a module. Seems odd that the server would be crying before drupal is loaded.

worth working through https://www.lifewire.com/500-internal-server-error-explained-2622938

WriteCo’s picture

I rebuilt the site because it was still new. I said in my post I would probably do that. I did not begin with a lot of options but I want to be prepared if this happens again or on another site that cannot be rebuilt so easily. I had no errors in the server logs and I could not find where anything was in the Drupal 8 database. I did learn that everything is rearranged and cleaner than 6 and 7.

I have a lot of problems with my webhost since they were U.S.-based and bought out by a UK company. A few months or so ago, they got rid of all U.S. support, then things slowed down and now I get timeout errors. The recent breakage happened after I enabled modules and apparently did too much at once with updates and cache clearing for the server to handle. I dunno. The only error I saw when it happened was that my services were restricted (throttled to nothing). Tech support over there was clueless.

When I first complained about the slow server a few months ago, they sent me an email saying to the effect, "I see you're running WordPress, check out how to optimize WordPress at this link." ... Uh, no baby, it's Drupal.

mmjvb’s picture

The real emergency back door is still there, just different tables from D7. Upon installation the module is registered which can be removed.

For D8: SQL: delete from key_value where collection = 'system.schema' and name ='[MODULE]';
where [MODULE] should be replaced with the system name of the module.

Note that this gets you back in but it not the equivalent of a clean removal of a module. It just removes its registration.

WriteCo’s picture

That looks like what I wanted. In 7, you could change the status from 1 to 0 and then get back into the site to fix things. You can't leave it that way and I wanted something in 8 that could do that. This looks like right. Thanks!

mmjvb’s picture

As mentioned it gets you back in most of the time. In another thread the user solved the problem by removing entries from config as well.

delete from `config` where name like "%[MODULE]%" should remove them, you may want to use a select first to see what is there and only remove what you are sure about.

Not sure about all the differences between D7 and D8. That row in key_value is used to determine which update the module is at. Removing the row means it is not in use. Obviously, everything else remains in the database and could hurt you later on. That is why enable/disable was removed. Uninstalling the proper way is more save, no guarantee though.

drupaldope’s picture

well, nope. it doesn't work.

I'm in the process of developing a module and screwed up the schema install.

Installation threw an error, and the checkbox to uninstall is greyed.

I deleted all instances I could find in the database and removed the folder. The module disappears from the module list, but when I return the folder, the module reappears with its checkbox already checked and greyed, so I am unable to re-test the install.

I found this while researching my issue:
https://sachinsuryavanshi.wordpress.com/2017/09/07/how-to-uninstalldisab...

This is so painful to do at every development fail.

Serialized data is horrible, serialized blobs even more horrible. At least Drupal should provide functions to update and cleanup data.

joris_lucius’s picture

I had a similar problem (D9): some left-over of an uninstalled module blocked drush. Solved it by plucking it out the json you'll get in the 'data' column via:

SELECT * FROM `config` WHERE `name` = 'core.extension';

So for example: if 'admin_toolbar' is your left-over, error generating module, you'll have to remove this from the json data:

s:13:"admin_toolbar";

Hope this helps.

jrwest_webguy’s picture

I ran your Select statement on my database, at the mysql command line, and saw the json response with the 'error-generating module' listed.  But how do I 'pluck' it out?  If the answer is dump it to a file, edit, and set database record to the contents of the edited file.  The dump and insert commands for the file would be helpful.  Thank you.

joris_lucius’s picture

Yes, that's basically what I did: edited the record (in SequelPro), removed that piece and saved it.

jrwest_webguy’s picture

Fortunately, for me, I didn't need to do that in the end.  For me, the 'error-generating module' was something called the 'config' module.  This turns out to be the machine name for the 'Configuration Manager' module that comes with Drupal core.  It went missing because I didn't properly format something in my site-project's .gitignore file.  I was trying to just ignore my Dev site's 'config' folder; but, what I put in the .gitignore file caused ALL of the 'config/' folders to be ignored.  So what I uploaded to my deployment repo -- and then deployed to my Production website -- was missing A LOT of code.  Anyway -- learn from my mistake everyone -- if you want to ignore just the config folder sitting next to your .gitignore file, use a slash in front AND in back: /config/

Thinking about changing my handle to jrwest_webnoob . . .  Anyway, thanks again Joris.

joris_lucius’s picture

venkat-rk’s picture

Been struggling with a broken D8 site (including admin UI) and after hours of search, your comment has been a life saver. In my case, the offending module was something called 'datetime'. I found references to it in both the ‘cache_config’ and ‘config’ tables:

s:8:"datetime";i:0;

So I removed the string and uploaded the edited blob (using TextEdit on Mac) back to the respective tables. This finally solved the PHP error relating to datetime, but I have a different error now:

[16-Jul-2020 09:26:30 Asia/Kolkata] Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "node" entity type does not exist." at /home/username/public_html/core/lib/Drupal/Core/Entity/EntityTypeManager.php line 133

Is there something about the string I removed that could be causing this new error?

 

joris_lucius’s picture

Glad to help, but I'm afraid your next issue this is too install-specific.

-- best, Joris

venkat-rk’s picture

Thanks. I guess so. drush status reports the same, too.

The weirdest thing is that I had a backup of the server with that Drupal site from two days ago, so I spun up a VM with that backup and pointed the cPanel licence (it was a cPanel server) at the new server's IP and did the same for the site as well and it's working absolutely fine!

Have decided to create a fresh Drupal install with Composer on a different server and manually copy over stuff from this site to the new one.

Thanks once again for your clear explanation for uninstalling a Drupal 8 module through the db.

divspace’s picture

Only problem with that is it's serialized data, so if you just remove the string, you didn't update the count on the array (e.g. before it would have been like a:155 and after you removed it, it should be a:154). It's best to unserialize the data, make your changes, serialize it, and then save that.

joris_lucius’s picture

Great, thanks for the info

kevster’s picture

Thank you - that helped me fix an issue with feeds in D8 after it didnt uninstall cleanly - edited blob on config and cache_config tables and updated serial no, and its worked! 

Drupal development | SEO optimised build

yogesh kushwaha’s picture

If your site itself not broken and you are able to see normal pages. Then you can uninstall a broken module directly from database as suggested @joris_lucis using a custom module.

You can do it manually or you can simply create a custom module or add a controller to an existing module or write hook_update_n it is up to you to how do you want automate this process. 

In my case I have created a Controller into my existing module to uninstall the module completely from config table.

# Path web/modules/custom/boult/boult.routing.yml
boult.boult_schema:
  path: '/boult/schema'
  defaults:
    _controller: '\Drupal\boult\Controller\BoultController::repSalesforce'
    _title: 'Rep Salesforce'
  requirements:
    _permission: 'access content'

Then create a controller class

<?php

namespace Drupal\boult\Controller;

use Drupal\Core\Controller\ControllerBase;
use GuzzleHttp\Command\Guzzle\Deserializer;
use Symfony\Component\DependencyInjection\ContainerInterface;

/**
 * Class BoultController.
 */
class BoultController extends ControllerBase {

  /**
   * Drupal\Core\Database\Driver\mysql\Connection definition.
   *
   * @var \Drupal\Core\Database\Driver\mysql\Connection
   */
  protected $database;

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container) {
    $instance = parent::create($container);
    $instance->database = $container->get('database');
    return $instance;
  }

  /**
   * Remove broken module entry from config table.
   *
   * @return string
   *   Return Hello string.
   */
  public function repSalesforce() {
    // $query = "select data from config where name = 'core.extension'";
    $query = $this->database->select('config', 'c');
    $query->condition('c.name', 'core.extension')
      ->fields('c', ['data']);
    $result = $query->execute()
      ->fetchField();
    $arrayResult =  unserialize($result);
    foreach ($arrayResult['module'] as $key => $value) {
      // In my case module name is rep_mapping
      if ($key == 'rep_mapping') {
        unset($arrayResult['module']['rep_mapping']);
      }
    }
    $updated = serialize($arrayResult);

    $this->database
      ->update('config')
      ->fields(['data' => $updated])
      ->condition('name', 'core.extension')
      ->execute();

    return [
      '#type' => 'markup',
      '#markup' => $updated,
    ];
  }

}

Once you are done enable your module or clear cache for existing module. Now visit the url you have given in routing.yml file, in my case http://baseurl/boult/schema, to remove the entry from database. I hope this will help to avoid manual editing of blob file.

--
Yogesh Kushwaha

magendiran’s picture

Thanks @joris_lucius,

It's works!!!

The other option is disable module using drush command, If drush is installed.
Command : "drush pm-uninstall module-name"

hansrossel’s picture

If 
drush pmu MODULENAME
does not work due to an error, then you can also uninstall with:

drush eval "\$module_data = \Drupal::config('core.extension')->get('module'); unset(\$module_data['MODULENAME']); \Drupal::configFactory()->getEditable('core.extension')->set('module', \$module_data)->save();"

drush php-eval "\Drupal::keyValue('system.schema')->delete('MODULENAME');"

If you have still an error you should clear the cache or rebuild the router

drush cr
drush ev '\Drupal::service("router.builder")->rebuild();'
drush cc router (Drupal 9/10)