Contrib.social

InvalidArgumentException: Class <class_name> does not exist when accessing settings form after drush install module

Open on Drupal.org →
Created on 28 July 2021, over 3 years ago
Updated 2 March 2023, almost 2 years ago

I was trying to install a custom module from the command line using drush and I ran into this error on a Drupal 9.2.1 site on a windows machine with XAMPP. The module installed fine but when I tried to access the settings form for the module, I get a WSOD and I see the following error in dblog.

InvalidArgumentException: Class "\Drupal\module_name\Form\SettingsForm" does not exist. in Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (line 24 of site.com\web\core\lib\Drupal\Core\DependencyInjection\ClassResolver.php).

This does not happen when you enable the module from the Drupal Admin interface. This also does not happen when you run drush cr after the module install.

I tried to see if this had something to do with how the module was written and tried to recreate the error with a contrib module. I tried with something that was already installed viz. clamav. Disabled the module and enabled it using drush and went to access the settings form and I got the white screen and the same error in dblog - InvalidArgumentException: Class "Drupal\clamav\Form\ClamAVConfigForm" does not exist.

I tried to recreate this on an Ubuntu machine (Apache) with the same custom module and clamav but was not able to recreate this.

💬 Support request
Status

Closed: outdated

Version

9.3

Component
Extension  →

Last updated 12 days ago

No maintainer
Created by

🇺🇸United States anoopjohn Washington D. C.

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇬🇧United Kingdom aaron.ferris

    I've come across this recently as well, although I can't add specific steps to reproduce I can say that this affected several modules I was enabling via Drush. Ban, twig_debugger as well as a custom module that was defining its own config form. All 3 settings forms would give the result from the opening post (class does not exist).

    Clearing the caches via Drush didn't help me, but clearing the caches via the UI did..... it's super odd. Adding this comment for anyone else who might come across this issue. Try clearing the site caches via the UI.

  • Comment almost 2 years ago →
    🇦🇹Austria tgoeg

    This sounds familiar.
    Sometimes, problems like this even make you unable to use the UI, so no way of clearing the cache via the UI.
    I don't know why there is a difference, but
    drush -l <site> php:eval "drupal_flush_all_caches();"
    is the function the UI triggers. This can be run from the CLI as well and saved my day a few times already.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024