00001 Clean up after a failed HumHub module installation

How to clean up references of a failed Humhub module installation or modification in the database?

Sometimes it happens that a plugin development causes some problems and you need to find and clean up all references that it already left in the Database to be able to reinstall it again.

In our case we had modified the module Classified Space and renamed it in a way that was causing other conflicts so we renamed it again conform to PSR12 and Bumm we got an error that a message couldnot be found .... In our case we liked to keep the same database and only wanted to reinstall the newly renamed module.

Let's start after you have made a Backup!

In our example we work on a HumHub Database but the approach can be used for many other Systems too.

NOTE: This is an example and you need to replace the DATABASE_NAME, database_name and the names of the tables and columns with your own ones!

A. Files and Folders

Move or delete the conflicting Module(s).

B. Database

1. Finding the references of the failed plugin in the HumHub Database

Let’s force it to report only the tables and columns in DATABSE_NAME:

1.1. List all table names in your schema

SELECT TABLE_NAME
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'database_name'
ORDER BY TABLE_NAME;

This will give you every table in your HumHub database.

1.2. For a quick per-table column dump

If you want each table with its columns in one shot, run:

SELECT 
  TABLE_NAME,
  GROUP_CONCAT(CONCAT(COLUMN_NAME,' ',COLUMN_TYPE) 
               ORDER BY ORDINAL_POSITION 
               SEPARATOR ', ') AS columns
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'database_name'
GROUP BY TABLE_NAME
ORDER BY TABLE_NAME;

You’ll get rows like:

… …

3. Or, one-by-one with SHOW commands

3.1. List tables

SHOW TABLES;

3.2. Get columns for a specific table

SHOW COLUMNS FROM `setting`;
SHOW COLUMNS FROM `contentcontainer_module`;
SHOW COLUMNS FROM `module_enabled`;
-- etc.

Once you have the exact table names, you can then safely run your DELETE FROM … WHERE module_id IN (…) statements against those tables:

DELETE FROM `module_enabled`
 WHERE `module_id` IN ('classified-space','abc-directory','AbcDirectory');

DELETE FROM `contentcontainer_module`
 WHERE `module_id` IN ('classified-space','abc-directory','AbcDirectory');

DELETE FROM `setting`
 WHERE `module_id` IN ('classified-space','abc-directory','AbcDirectory');

DELETE FROM `contentcontainer_setting`
 WHERE `module_id` IN ('classified-space','abc-directory','AbcDirectory');

DELETE FROM `task_list_setting`
 WHERE `module_id` IN ('classified-space','abc-directory','AbcDirectory');

DELETE FROM `migration`
 WHERE `version` LIKE '%classified_space%'
    OR `version` LIKE '%abc_directory%'
    OR `version` LIKE '%AbcDirectory%';

Then clear HumHub’s caches:

rm -rf protected/runtime/cache/* protected/runtime/compiled_templates/*
php yii cache/flush-all
That will guarantee you’re seeing your schema’s tables and columns, so you can identify and purge exactly the leftover module data.

2. Deleting the references from the database tables and their colums

2.1. Analyze the schema dump

Based on our schema dump, these are the exact tables you need to target. Run all of the following in your SQL console to purge every trace of classified-space, abc-directory, or AbcDirectory:

NOTE: This is an example and you need to replace the DATABASE_NAME, database_name and the names of the tables and columns with your own ones!

-- 1. Disable/remove from the enabled‐modules list
DELETE FROM `module_enabled`
 WHERE `module_id` IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);

-- 2. Remove any per‐space/module registrations
DELETE FROM `contentcontainer_module`
 WHERE `module_id` IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);

-- 3. Remove global settings
DELETE FROM `setting`
 WHERE `module_id` IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);

-- 4. Remove container‐specific settings
DELETE FROM `contentcontainer_setting`
 WHERE `module_id` IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);

-- 5. Remove any task‐list settings
DELETE FROM `task_list_setting`
 WHERE `module_id` IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);

-- 6. Remove any applied migrations
DELETE FROM `migration`
 WHERE `version` LIKE '%classified_space%'
    OR `version` LIKE '%abc_directory%'
    OR `version` LIKE '%AbcDirectory%';
Note: You saw tables named classified_space and classified_space_category—those are your original module tables. Do not drop them now; you only want to remove the settings/migration entries for the renamed module, not the real data.

4. Final step: clear all HumHub caches

From your HumHub root directory, run:

rm -rf protected/runtime/cache/* protected/runtime/compiled_templates/*
php yii cache/flush-all

After this, reload your site and go to Manage → Modules. The old abc-directory/AbcDirectory entries should be completely gone, and you’ll be able to reinstall your freshly renamed PSR-12 compliant module from scratch.

5. Re-install your renamed plugin

Once the DB is clean and the UI shows no leftover module:

5.1 Rename the folder back to your cleaned, PSR-12 name if you haven’t already:

cd protected/modules
mv classified-space AbcDirectory

5.2. Follow the steps to fix namespaces, class names, file names, and config as in the previous guide:

• Module.php → AbcDirectoryModule.php

• namespace humhub\modules\AbcDirectory;

• class AbcDirectoryModule extends BaseModule { public $id = 'abc-directory'; ... }

• Bulk sed replacements for any leftover classified-space, classified_space, or ClassifiedSpace.

5.3. Add back the module entry in your config/common.php or config/web.php:

'modules' => [
    // …
    'abc-directory' => [
        'class' => 'humhub\modules\AbcDirectory\AbcDirectoryModule',
    ],
],

5.4. Clear caches again and run migrations:

rm -rf protected/runtime/cache/* protected/runtime/compiled_templates/*
php yii cache/flush-all
php yii migrate/up --migrationPath=@humhub/modules/AbcDirectory/migrations

5.5. Enable the module

... under Manage → Modules and verify your /abc-directory/... pages load without errors.

6. Possible errors and their solution

Unknown column 'module_id' in 'WHERE'

While trying to delete references the following message pops up:

-- 5. Remove any task‐list settings
DELETE FROM task_list_setting
 WHERE module_id IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);
MySQL said: Documentation

#1054 - Unknown column 'module_id' in 'WHERE'

The error means task_list_setting simply doesn’t have a module_id column. That table isn’t tied to modules, so you can skip it entirely.

Here’s the revised cleanup SQL—run only the statements for tables that actually have a module_id (or version in the case of migrations):

-- 1. Remove from enabled‐modules
DELETE FROM `module_enabled`
 WHERE `module_id` IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);

-- 2. Remove per‐space module registrations
DELETE FROM `contentcontainer_module`
 WHERE `module_id` IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);

-- 3. Remove global settings
DELETE FROM `setting`
 WHERE `module_id` IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);

-- 4. Remove container‐specific settings
DELETE FROM `contentcontainer_setting`
 WHERE `module_id` IN (
   'classified-space',
   'abc-directory',
   'AbcDirectory'
);

-- 5. Remove any applied migrations for those module IDs
DELETE FROM `migration`
 WHERE `version` LIKE '%classified_space%'
    OR `version` LIKE '%abc_directory%'
    OR `version` LIKE '%AbcDirectory%';

After running those, clear HumHub’s caches:

rm -rf protected/runtime/cache/* protected/runtime/compiled_templates/*
php yii cache/flush-all

Now reload your site. The old abc-directory/AbcDirectory entries should be gone, and you’ll be set to install your freshly renamed module cleanly.