Posted by Graham Leach on Sun, Oct 27, 2024 - 2:13am --- Updated: Oct 27 '24 - 2:15am

Hello,

I am wondering if there's any collective will to 

Add:

module_installed($module) 

Alongside:

module_exists($module)

In: 

core/includes/modules.inc

Here's the source for module_exists($module)

/**
* Determines whether a given module exists.
*
* @param string $module
*   The name of the module (without the .module extension).
*
* @return bool
*   TRUE if the module is both installed and enabled, FALSE otherwise.
*/
function module_exists($module) {
 $list = module_list();
 return isset($list[$module]);
}

Here's what I whipped up for module_installed($module)

/**
*
* @name
* module_installed()
*
* @description
* Determines if a module is installed or not.
*
* @param string $module
*   The name of the module (without the .module extension).
*
* @return bool
*   TRUE if the module is installed, FALSE otherwise.
*/
function module_installed($module) {

 $result = db_query("SELECT * FROM {system} WHERE type = 'module' AND name = '" . $module . "'");

 return $result->rowcount() ? TRUE : FALSE;

}

 

Comments

Sun, Oct 27, 2024 - 7:07am by herb

The system table shows rows of modules that are or were present in the codebase. So it would be unreliable.

Perhaps if I understood what you're trying to accomplish. Are you saying "installed" as in the module code is present, or that the module is enabled? If the latter then module_exists() already does that. As for the former, I don't think there's a performant way to do that.

Sun, Oct 27, 2024 - 8:13am by argiepiano

In addition to what Herb said, it's important to clarify the terminology used by Backdrop. 

  • Enabled module:  
    • Its code is included during a page request, 
    • All its tables (hook_schema) are present in the database
    • All its configurations (files placed in its config folder, and usually defined in MY_MODULE_config_info) are present in the site's active configuration folder
  • Disabled module:
    • Its code is not included in page requests
    • All its tables (hook_schema) are STILL present in the database
    • All its configurations (files placed in its config folder, and usually defined in MY_MODULE_config_info) are STILL present in the site's active configuration folder
    • The above allows the site manager to re-enable the module without losing data
  • Uninstalled module (for a previously enabled module):
    • Its code is not included in page requests
    • None of its tables (hook_schema) are present in the database. If the module defined a fieldable entity, the fields attached to it and their data have been purged (the latter is still somewhat buggy as of the time of writing this)
    • None of its configurations defined with MY_MODULE_config_info are present in the site's active config folder
    • Any configuration files present in its config folder that don't have a definition in MY_MODULE_config_info are STILL in the site's active config folder (e.g. Views installed by the module)
  • Uninstalled module that have never been enabled:
    • Its code is not included in page requests
    • There is no trace of it anywhere in the database or site's active config folder 

 

The list of modules displayed in /admin/modules is the result of reading the .info files placed within the usual module locations (modules folder, core/modules folder and sites/XXX/modules folder), and lists any module that contains type = module in those .info files. This list is stored in the system table. When you remove a module folder from the modules folder, the system table will not be updated (and the module record will not be removed) until you either clear caches, or visit the admin/module page. Therefore, your code (IF what you are trying to do is to see if the module code is in the modules folder) will be unreliable.

In addition, your syntax for db_query is not great. You don't want to concatenate strings for the query. Instead you should use placeholders.