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

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.

Comments

Comment #1

28 July 2021 at 01:03

anoopjohn created an issue. See original summary.

Comment #2

cilefen commented 28 July 2021 at 01:58

Component:	install system	» extension system
Issue tags:		+Bug Smash Initiative

How are you executing Drush and what version is it?

If you restart the web server after installing the module with Drush then try the form, what happens?

Comment #3

larowlan

🇦🇺🏝.au GMT+10

commented 28 July 2021 at 08:20

Are you using a global drush or running it from vendor

Comment #4

anoopjohn commented 28 July 2021 at 16:42

I am running Drush from git bash from Mingw64. It is the global drush and version 10.5.0.

I restarted Apache after drush pm-enable and ran into the same error

Comment #5

cilefen commented 28 July 2021 at 17:51

Something to consider, via https://www.drush.org/latest/install/:

Drush only supports one install method. It requires that your Drupal site be built with Composer and Drush be listed as a dependency.

Comment #6

larowlan

🇦🇺🏝.au GMT+10

commented 28 July 2021 at 18:26

Category:	Bug report	» Support request
Status:	Active	» Closed (works as designed)

Yeah, from drush 10, it needs to be installed with composer from the same autoloader as core

Comment #7

anoopjohn commented 4 August 2021 at 21:30

Status:

Closed (works as designed)

» Active

Thanks for looking into this.

I uninstalled global drush and ran it from the vendor/bin folder. I get the same error when I don't run drush cr after drush pm-enable clamav.

drush was already part of composer.json as a dependency and was present in vendor folder

./vendor/bin/drush status
 Drupal version   : 9.2.2
 Site URI         : http://default
 DB driver        : mysql
 DB hostname      : localhost
 DB port          : 3306
 DB username      : dbuser
 DB name          : dbname
 Database         : Connected
 Drupal bootstrap : Successful
 Default theme    : default_theme
 Admin theme      : seven
 PHP binary       : C:\xampp\php\php.exe
 PHP config       : C:\xampp\php\php.ini
 PHP OS           : WINNT
 Drush script     : C:\xampp\apps\sitename\vendor\bin\drush
 Drush version    : 10.5.0
 Drush temp       : C:\Users\user\AppData\Local\Temp
 Drush configs    : C:/xampp/apps/sitename/vendor/drush/drush/drush.yml
                    C:/xampp/apps/sitename/drush/drush.yml
 Install profile  : my_profile
 Drupal root      : C:\xampp\apps\sitename/web
 Site path        : sites/default
 Files, Public    : sites/default/files
 Files, Private   : sites/default/files/private/
 Files, Temp      : \xampp\tmp

Comment #8

cilefen commented 4 August 2021 at 22:05

I am not sure where to go from here. We’ll need complete steps to reproduce.

Do you know of another XAMPP user that could try to reproduce it?

Comment #9

anoopjohn commented 5 August 2021 at 00:44

Conceptually why would it fail? What is it that the module install does not do that causes this class to not be autoloaded which happens after a drush cr?

I can add debug statements and collect more information but would help to know where to start / add them.

Comment #10

cilefen commented 5 August 2021 at 00:48

Since it’s platform-specific I would scrutinize phpinfo differences.

Comment #11

tgoeg commented 6 October 2021 at 10:29

I don't think this is platform specific.
I have exactly the same problem with *some* modules.
Using global drush or the one from vendor/bin does not make a difference.
It just happened with file_extractor. Installed it with

composer require "drupal/file_extractor:<3" # I'm on latest 8.9.x
drush -l <site> pm:en file_extractor

Visited https://site/admin/config/media/file-extractor and got the mentioned error.
drush -l <site> cr
fixes it.
This is on a LAMP stack (Debian 9, PHP 7.2, mariaDB 10.1.48)

Any more debug info I can provide?

Comment #12

tgoeg commented 6 October 2021 at 10:35

Strangely, the same config import on a different server that's basically set up the same but runs on Ubuntu 18.04, PHP 7.2, mySQL 5.7.35 does not have this problem, no cache rebuild needed after config import, no error. This corresponds to anoopjohn's try to reproduce it on Ubuntu which also turned out not to show this error.

@anoopjohn: Does your XAMPP stack use mySQL or mariaDB?

Comment #13

anoopjohn commented 7 October 2021 at 01:14

@tgoeg - I have MariaDB

Comment #14

cilefen commented 7 October 2021 at 02:29

More debug? See comment #10.

Comment #15

cilefen commented 7 October 2021 at 02:30

Is opcache enabled on the CLI?

Comment #16

tgoeg commented 7 October 2021 at 08:28

Here is the diff of the two phpinfo()s when run as "php -r "phpinfo();"" from the CLI.

The only thing of notable difference seems to be redis support.

I am unsure however which php.ini gets used on the CLI anyway.
There's /etc/php/7.2/cli/php.ini which seems to get used when running the mentioned command, and there is /etc/php/7.2/apache2/php.ini which *does* use "opcache.enable_cli=1" and which definitely has an effect on the occ CLI command used by nextcloud (though I'd expect it to use /etc/php/7.2/cli/php.ini which it clearly does not).

Is opcache on the CLI supposed to work or produce problems?

Comment #17

7 October 2021 at 08:28

Version:

9.2.x-dev

» 9.3.x-dev

Drupal 9.1.10 (June 4, 2021) and Drupal 9.2.10 (November 24, 2021) were the last bugfix releases of those minor version series. Drupal 9 bug reports should be targeted for the 9.3.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #18

cilefen commented 16 January 2022 at 18:58

Status:

Active

» Closed (outdated)

I am closing this support request because there have been no recent comments.

Comment #19

tgoeg commented 17 January 2022 at 09:23

Hi @cilefen!
I'd have expected you to add a comment regarding my question in #16 ;-)
> Is opcache on the CLI supposed to work or produce problems?
As that's the only relevant difference I can see. Though I'm not quite sure whether the php.ini is the one that really gets used. Maybe you have more ideas for others to try this?
I fear I'm unable to help in providing more debug info on Debian, as the instance running Debian has been phased out during the upgrade to 9.x. That is, it is still running 8.9.20 but won't be upgraded to 9.x as another (Ubuntu) server has taken over its function.
I can still pull config data some more time I guess, if need be.

Maybe @anoopjohn can also provide more feedback, please?

Comment #20

cilefen commented 17 January 2022 at 10:22

AFAIK opcache on CLI can only cause issues. There is not even a shared memory space for it in most setups so it doesn’t in effect do anything.

Comment #21

aaron.ferris commented 2 March 2023 at 16:36

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). Code for the forms all looked good.

Drupal 9.5.2, Drush 11.4.0.

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 #22

tgoeg commented 2 March 2023 at 18:01

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.

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