I often face the issue that I need to have module metadatas (such as relative path) and in the standard Drupal way I seem to be enforced to hardcode the module name like this:


Is there an official way or a workaround to able to tell anywhere in your code (so not just .module) which module you are in (if it is module at all)?

  • I don't think that this is a supported task in Drupal, so the best way might be to get the module from the .module file, like here, stackoverflow.com/questions/16657904/…
    – user72672
    May 24, 2019 at 12:29
  • Since you know for which module you are writing code, I don't see what the benefit of using a dynamic value instead of a literal string is. If all the modules would do this, I think there would be a performance loss.
    – apaderno
    May 24, 2019 at 14:27
  • The question should be the other way around: Why I need to specify the module name? You say performance loss: you still have the chance to use the hardcoded version (sounds premature optimization anyway). 1. If I rename the module: I will have to rewrite it 2. If I put this functionality into another module, again I need to take care of it for no reason
    – ssibal
    May 24, 2019 at 14:36
  • Neither those cases are good reasons to penalize performance for the other 99% of the cases. There are modules that have been merged into Drupal core with a different machine name. In all those case, the solution was to manually edit each file.
    – apaderno
    May 24, 2019 at 14:46
  • 1
    It wouldn’t make conceptual sense to have such functionality. As kiamlaluno mentioned, it would just be a performance hit for no benefit. If you’re concerned about renaming the module in future. then make use of existing language features like constants, instead of using magic strings
    – Clive
    May 24, 2019 at 15:24

1 Answer 1


As Clive mentioned, a constant is your best bet. When I start up a new project, typically one of the first things I do is create an interface that contains constants that are applicable to the entire project. Usually the very first constant is for the module's machine name. I then use these constants, and not strings, throughout the project.

Here's a simplified and obfuscated version from one of my projects: (this file would be located in the folder my_module/src/MyModuleInterface.php)


namespace Drupal\my_module;

interface MyModuleInterface {

  const MODULE_NAME = 'my_module';
  const SERVICE = 'my_module.foobarbaz';
  const TAX_VOCAB_FOO = 'foo';
  const TAX_VOCAB_BAR = 'bar';
  const TAX_VOCAB_BAZ = 'baz';

  const PERM_ADMIN_FOO = 'administer foo';

   * Returns TRUE if the specified module is enabled.
   * @param string $module_name
   *  The machine name of the module to check as enabled. Defaults to this
   *  module's machine name.
   * @return boolean
   *  TRUE if the specified module is enabled.
  function isModuleEnabled($module_name = self::MODULE_NAME);

The benefits to this approach are:

  • Consistency through your project as well as for any other projects that might want to call on your module; they can also utilize the constant.
  • Reduction of errors due to typos.
  • If you use an IDE such as PHPStorm, you can take advantage of auto-completion, which is convenient and speeds code writing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.