[5.x]: Installing plugin stuck on "Installing the plugin"

[samuel-clara]

What happened?

Description

When installing a plugin from the plugin store on the control panel the process gets stuck on "Installing the plugin.." screen. The workaround is to go under Settings→Plugins and manually install the plugin from there

Steps to reproduce

1. Go to the Plugin Store on the control panel
2. Select a Plugin and click the "Install button"

Expected behavior

The plugin should be added and installed immediately.

Actual behavior

Plugin is added but not installed

Craft CMS version

5.6.13

PHP version

8.4

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions

"craftcms/ckeditor": "4.6.0",
"craftcms/cms": "^5.0.0",
"jsmrtn/craftagram": "4.1.0",
"nystudio107/craft-cookies": "5.0.0",
"nystudio107/craft-seomatic": "5.1.11",
"nystudio107/craft-typogrify": "5.0.1",
"putyourlightson/craft-blitz": "5.9.12",
"spacecatninja/imager-x": "5.1.2",
"studioespresso/craft-date-range": "5.0.0-beta.4",
"verbb/image-resizer": "4.0.3",
"verbb/knock-knock": "3.0.2",

[brandonkelly]

Which plugin are you trying to install?

[samuel-clara]

Happens with every plugin since some weeks, using ddev on my local machine.

[brandonkelly]

Also using DDEV here, and not able to reproduce.

Can you post your composer.json file, or send it into support@craftcms.com?

[samuel-clara]

{
"minimum-stability": "dev",
"prefer-stable": true,
"require": {
"carlcs/craft-diywidget": "4.1.1",
"craftcms/ckeditor": "4.6.0",
"craftcms/cms": "^5.0.0",
"jsmrtn/craftagram": "4.1.0",
"nystudio107/craft-cookies": "5.0.0",
"nystudio107/craft-seomatic": "5.1.11",
"nystudio107/craft-typogrify": "5.0.1",
"putyourlightson/craft-blitz": "5.9.12",
"spacecatninja/imager-x": "5.1.2",
"studioespresso/craft-date-range": "5.0.0-beta.4",
"verbb/image-resizer": "4.0.3",
"verbb/knock-knock": "3.0.2",
"vlucas/phpdotenv": "^5.4.0"
},
"require-dev": {
"craftcms/generator": "^2.0.0",
"yiisoft/yii2-shell": "^2.0.3"
},
"config": {
"allow-plugins": {
"craftcms/plugin-installer": true,
"yiisoft/yii2-composer": true
},
"sort-packages": true,
"optimize-autoloader": true,
"platform": {
"php": "8.4"
}
},
"scripts": {
"post-root-package-install": [
"@php -r "file_exists('.env') || copy('.env.example.dev', '.env');""
]
},
"repositories": [
{
"type": "composer",
"url": "https://composer.craftcms.com",
"canonical": false
}
]
}

[redburn]

Same here, on a fresh install of Craft CMS using the starter project. Not sure it's exactly the same thing because the plugin does seem to be installed, but the page hangs on "Installing the plugin". Same when removing a plugin, it gets stuck on "The plugin was removed successfully", but the plugin is removed.

It goes from "Updating Composer dependencies (this may take a minute)…" to "Installing the plugin…" and then an endless spinner.

Happens with all plugins. No discernable errors anywhere.

• Craft CMS 5.8.11
• FrankenPHP (classic mode)
• AlmaLinux 9
• MySQL 8.0.41

Perhaps related to this known issue in FrankenPHP, but the workaround isn't working.

composer.json

{
  "minimum-stability": "dev",
  "prefer-stable": true,
  "require": {
    "craftcms/cms": "^5.0.0",
    "vlucas/phpdotenv": "^5.4.0"
  },
  "require-dev": {
    "craftcms/generator": "^2.0.0",
    "yiisoft/yii2-shell": "^2.0.3"
  },
  "config": {
    "allow-plugins": {
      "craftcms/plugin-installer": true,
      "yiisoft/yii2-composer": true
    },
    "sort-packages": true,
    "optimize-autoloader": true,
    "platform": {
      "php": "8.2"
    }
  },
  "scripts": {
    "post-root-package-install": [
      "@php -r \"file_exists('.env') || copy('.env.example.dev', '.env');\""
    ]
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://composer.craftcms.com",
      "canonical": false
    }
  ]
}

Come to think of it, I believe this happened at the end of recent Craft CMS updates, as well.

I'll do my updates, installs and removals from the command-line for now.

[brandonkelly]

@redburn In your case, I would bet money it’s related to FranknPHP.

[redburn]

@brandonkelly Found the culprit. The JSON output of the final XHR request (at the end of an install, update or removal) is preceded by voku deprecation warnings (#16606), preventing the browser from reading the JSON and firing the redirect.

I usually only see those deprecation warnings once after a restart of FrankenPHP, i.e. when the opcache is empty. For every subsequent request the warnings are hidden because they're part of the compilation/parsing process.

But I see that the runComposerCommand() method ends by invalidating the opcache. As a result, the deprecation warnings are shown again upon the first request, breaking the redirect.

[brandonkelly]

Hm, those shouldn’t be getting output to the browser, at least based on Craft’s default error reporting setting:

cms/bootstrap/bootstrap.php

Lines 159 to 160 in 43bd419

	$errorLevel = E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED;
	error_reporting($errorLevel);

[redburn]

The deprecation notices arise from autoloading before bootstrap.php can call error_reporting(). It's fixed when I put error_reporting(E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED); in web/index.php before bootstrap.php is loaded.

Instead I'll set display_errors = off in php.ini so that bootstrap.php can set it to "on" again (devmode) after autoloading.

I'm no expert but maybe there's a timing difference in the compilation phase between PHP-FPM (FastCGI) and FrankenPHP (embedded SAPI), causing FrankenPHP to output the deprecation notices early, whereas PHP-FPM suppresses them somehow.