Scaffold plugin does not always create autoload_runtime.php when upgrading to 11.4

Same for me (running on ddev)

Fixed by running composer install after updating the database ;-)

@phily Same here

It would be helpful if we could see the output of composer update when it causes the missing file.

Confirming the issue. Running:

drush config:set system.performance js.preprocess 0
drush config:set system.performance css.preprocess 0
drush cr
drush warm
drush cron

temporarily fixes it for me. Enabling preprocess reproduces the error reliably.

just run composer install after the update, that will copy the missing file from the core/assets/scaffold folder, nothing more to do...

You're right. Running composer install does address the 500 error. Aggregated CSS and JS still produces 404 for me though.

@neurer D11.4.0 changed the system.performance.yml config file, replacing gzip: true to compress: true for both css and js statements.
Is your config updated?

system.performance.yml has been updated to reflect changes. nginx config has been updated to reflect changes -- with brotli commented out, as its an unknown directive "brotli_static".

Aggregated CSS and JS keep producing 404 errors.

composer install do the job for me, thanks @phily

attempting to update from Drupal core 11.3.13 to core 11.4.0 caused catastrophic total site crash from which I have not yet been able to recover the site:

After core update, it is not possible to run {site}/update.php

After core update, the site issued an http "500" error.

After core update, drush update and and cache rebuild commands produce the following error output:

(Currently using Missing or invalid module The following module is marked as installed in the core.extension
configuration, but it is missing:
 * search_help

Review the  suggestions for resolving this incompatibility [1] to repair your
installation, and then re-run update.php.

[1] https://www.drupal.org/docs/updating-drupal/troubleshooting-database-updates
)

 // Requirements check reports errors. Do you wish to continue?: yes.

 [success] No pending updates.

In ExceptionHandler.php line 96:

  SQLSTATE[42S02]: Base table or view not found: 1146 Table '{database}.help_search_items' doesn't exist: SELECT "hsi"."sid" AS "sid", "hsi"."topic_id" AS "topic_id", "hsi"."section_plugin_id" AS "section_plugin_id", "hsi"."permission" AS "permission"
  FROM
  "help_search_items" "hsi"; Array
  (
  )


In PdoTrait.php line 109:

  SQLSTATE[42S02]: Base table or view not found: 1146 Table '{database}.help_search_items' doesn't exist


In ExceptionHandler.php line 96:

  SQLSTATE[42S02]: Base table or view not found: 1146 Table '{database}.help_search_items' doesn't exist: SELECT "hsi"."sid" AS "sid", "hsi"."topic_id" AS "topic_id", "hsi"."section_plugin_id" AS "section_plugin_id", "hsi"."permission" AS "permission"
  FROM
  "help_search_items" "hsi"; Array
  (
  )


In PdoTrait.php line 109:

  SQLSTATE[42S02]: Base table or view not found: 1146 Table '{database}.help_search_items' doesn't exist

drush config:delete core.extension module.search_help
drush config:delete core.extension module.search_node

Not sure if hsi table still needed after this, as I created it first, but here is SQL -

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for help_search_items
-- ----------------------------
DROP TABLE IF EXISTS `help_search_items`;
CREATE TABLE `help_search_items` (
  `sid` int unsigned NOT NULL AUTO_INCREMENT COMMENT 'Numeric index of this item in the search index',
  `section_plugin_id` varchar(255) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL DEFAULT '' COMMENT 'The help section the item comes from',
  `permission` varchar(255) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL DEFAULT '' COMMENT 'The permission needed to view this item',
  `topic_id` varchar(255) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL DEFAULT '' COMMENT 'The topic ID of the item',
  PRIMARY KEY (`sid`),
  KEY `section_plugin_id` (`section_plugin_id`),
  KEY `topic_id` (`topic_id`)
) ENGINE=InnoDB AUTO_INCREMENT=87 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='Stores information about indexed help search items';

SET FOREIGN_KEY_CHECKS = 1;

Running composer install did not resolve PHP Warning: require_once(autoload_runtime.php) error for me.

Scaffolding kept replacing index.php with version referencing autoload_runtime.php, which continued to present error.

In the end, I reverted back to 11.3.13

Running composer dump-autoload should regenerate the autoload files, which may fix this issue. It did for me.

I tried all of these to no avail:

composer dump-autoload

composer install

composer clear-cache
composer install

composer update --lock

//to force scaffold file rewrite.
mv web/robots.txt web/robots.txt.txt 
composer install

Ok, the solution for me was to fix the permission issue on:

In Filesystem.php line 305:

Could not delete /.../.../web/sites/default/default.services.yml:

This prevented the whole scaffolding script to run.

After fixing that permission issue, just running composer install fixed the autoload_runtime.php bug.

Now, what is the recommend approach to patch the drupal/core-composer-scaffold to force update the scaffold files the first time we load Drupal 11.4.x?

Hi @xmacinfo - how did you fix the permissions? In my case the default.services.yml file is owned by the web user (www-data) but I still get the 'Could not delete /var/www/html/web/sites/default/default.services.yml:" error even if I make the file universally writable...

Never mind - I see that it's the `default` dir that needs the permission update.

@lightweight Try the default folder directly, not the file inside the default folder:

chmod 777 /var/www/html/web/sites/default

Thanks for your help! Must've posted at just about the same time! Fixes this problem but reveals another one... sigh.

Which new problem?

Running composer dump-autoload works for me

Updating to core 11.4.1 fixed it for us.

I can confirm #18 sequence fixes the problem. Thank you @xmacinfo

First you have to check file permissions to make sure that the update script will be able to write your sites/default directory.
Then Drush should be version 13.7 so that you don't get errors when trying to update database which prevents the script to create the autoload_runtime.php file.

If you previously ran the update and got the errors, you should check permission on sites/default folder or manually create the correct version of default.services.yml. Then upgrade Drush to correct version, flush cash and then run "composer install". If composer ran correctly run drush updatedb and then cash rebuild.

Confirming this on 11.4.1 with web-root: "." Workaround that worked: manually creating [web-root]/autoload_runtime.php with return require __DIR__ . '/vendor/autoload_runtime.php';, mirroring the existing autoload.php stub.

in my case with multiple drupal site.. all i did is

chmod 755 /sites/default
composer update
composer update

yes, run "composer update" twice, it works.. my problem is my default permission at "/site/default" is 555. Change it to 755 help with "Could not delete /sites/default/default.services.yml:" error.

I am moving this to a support request due to the diversity of reports. Some comments point to #3091285: Composer scaffolding fails when permissions on default.settings.yml or default.settings.php is not writable..

@cilefen: Yes, “some”, but not all.

There is definitely a bug. It did not happen from 11.0 to 11.1, 11.1 to 11.2 and so on. But it happens from 11.3 to 11.4.

autoload_runtime.php is new in 11.4, but the Composer scaffold should put the right files in the right places. But #11 mentions CSS/JS aggregation, which is different, and then #13/14 are talking about help search, which is different again, so there's at least three separate problems here as far as I can tell.

Reran this from backup: composer install does address the 500. CSS/JS aggregation stops working instantly. As it turns out, the updated NGINX directives (https://www.drupal.org/node/3526344) weren't helpful. They validate fine though. Removing them does the trick. CSS/JS aggregation now works.

I think the autoload_runtime issue is due to

#3091285: Composer scaffolding fails when permissions on default.settings.yml or default.settings.php is not writable.

Added as #3091285: Composer scaffolding fails when permissions on default.settings.yml or default.settings.php is not writable. related

I think the autoload_runtime issue is due to

#3091285: Composer scaffolding fails when permissions on default.settings.yml or default.settings.php is not writable.

Short answer: “No.”

Fixing manually the file permission on the web/sites/default folder does not fix the autoload_runtime.php bug.

After fixing the files permission on web/sites/default, we still need to run composer install when upgrading from 11.3.x to 11.4.0 (or 11.4.1).

Scenario one

If composer installs all the scaffolding files without permission error, run:

composer update -W (update from 11.3.x to 11.4.x)
composer install

Scenario two

1. composer update -W (update from 11.3.x to 11.4.x)
If composer reports a permissions issue.

    In Filesystem.php line 305:

    Could not delete /.../.../web/sites/default/default.services.yml:

2. Fix the file permission (manually or with pre/post-drupal-scaffold-cmd commands in composer.json #3091285: Composer scaffolding fails when permissions on default.settings.yml or default.settings.php is not writable..
3. Run composer install

What I do to update to 11.4.1

1. If I did not add the “pre/post-drupal-scaffold-cmd” commands in composer.json, I fix manually the web/sites/default permissions.
2. I run composer update -W to get all files (upgrade from 11.3 to 11.4.1).
3. Run composer install on top.

Note that if I omit to run composer install on top of the composer update -W, I get a fatal error, even if I did correct the file permissions.

It would be helpful if we could see the output of composer update when it causes the missing file.

Hopefully this helps. For me this also occurs with composer install.

The web/sites/default/default.*.* files and their directory are writable by the cli user:

$ ll web/sites/default
drwxrwxr-x 3 cli-user web-user  139 Jul  7 11:34 ./
drwxrwxr-x 3 cli-user web-user  176 Jun 28  2025 ../
...
-rw------- 1 cli-user web-user  11K Jul  7 11:34 default.services.yml
-rw------- 1 cli-user web-user  36K Jul  7 11:34 default.settings.php
...

Here's the composer output:

$ composer install --no-dev
Gathering patches for root package.
Removing package drupal/core so that it can be re-installed and re-patched.
  - Removing drupal/core (11.3.13)
Deleting /home/.../web/core - deleted
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Package operations: 6 installs, 12 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing symfony/runtime (v7.4.14): Extracting archive
  - Upgrading drupal/core-composer-scaffold (11.3.13 => 11.4.1): Extracting archive
  - Upgrading drupal/core-project-message (11.3.13 => 11.4.1): Extracting archive
  - Upgrading symfony/polyfill-mbstring (v1.37.0 => v1.38.2): Extracting archive
  - Upgrading symfony/polyfill-intl-normalizer (v1.37.0 => v1.38.0): Extracting archive
  - Upgrading symfony/polyfill-intl-grapheme (v1.37.0 => v1.38.1): Extracting archive
  - Upgrading twig/twig (v3.27.1 => v3.28.0): Extracting archive
  - Installing twig/html-extra (v3.28.0): Extracting archive
  - Upgrading symfony/polyfill-php84 (v1.37.0 => v1.38.1): Extracting archive
  - Installing symfony/polyfill-php86 (v1.38.0): Extracting archive
  - Upgrading symfony/polyfill-php85 (v1.37.0 => v1.38.1): Extracting archive
  - Upgrading php-tuf/composer-stager (v2.0.2 => v2.1.1): Extracting archive
  - Installing marc-mabe/php-enum (v4.7.2): Extracting archive
  - Installing justinrainbow/json-schema (6.8.2): Extracting archive
  - Upgrading guzzlehttp/guzzle (7.12.3 => 7.13.2): Extracting archive
  - Upgrading asm89/stack-cors (v2.3.0 => v2.4.0): Extracting archive
  - Installing drupal/core (11.4.1): Extracting archive
  - Upgrading drupal/core-recommended (11.3.13 => 11.4.1)
  - Applying patches for drupal/core
    ...

Generating optimized autoload files
50 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Scaffolding files for drupal/core:
  - Copy [web-root]/example.gitignore from assets/scaffold/files/example.gitignore

And the output from running composer install --no-dev again, which does create web/autoload_runtime.php:

$ composer install --no-dev
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove
Generating optimized autoload files
50 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> DrupalProject\composer\ScriptHandler::createRequiredFiles

In #39 you are patching core with cweagans/composer-patches. If you remove the patches section from your composer.json, do you still need to install for the second time?

In #39, when do you encounter the fatal 500 error, before running composer install --no-dev?

Or are you still stucked with a 500 error message after running composer install --no-dev?

Can you load the PHP error_log and give us the output? I want to see if this is related to the missing autoload_runtime.php file.

@longwave,

In #39 you are patching core with cweagans/composer-patches. If you remove the patches section from your composer.json, do you still need to install for the second time?

Can you tell me how to repeat it? For me, once composer install --no-dev correctly creates the file, it always works—even if I manually delete web/autoload_runtime.php and leave the patches in place. I've already done it on all environments for this site.

@xmacinfo,

In #39, when do you encounter the fatal 500 error, before running composer install --no-dev?

Or are you still stucked with a 500 error message after running composer install --no-dev?

I run composer install --no-dev twice. This was on deployment to stage / production, where I don't run composer update at all.

The error occurred after the first composer install --no-dev, and was resolved by the second composer install --no-dev.

Can you load the PHP error_log and give us the output? I want to see if this is related to the missing autoload_runtime.php file

It's related. I tracked down this issue after I got the error about the missing autoload_runtime.php file.

Plus, I manually checked for the autoload_runtime.php file. It was missing after the first composer install --no-dev, and appeared as expected after the second composer install --no-dev.

@longwave: actually, I'll try rolling back the composer changes completely to see if I can repeat it.

@kentr Perfect. Your second composer install fixes the missing file problem like it does for others on this issue. And based on your account, this is not related to file permissions.

To reproduce the problem

I maintain multiple Drupal 11 websites and on each of those, going from 11.3 to 11.4.1, the first composer command works without error, but the autoload_runtime.php is missing. When running composer install (after the first composer command), the autoload_runtime.php is created.

My workflow

composer update -W
500 error
composer install
no more error.

Your workflow

composer install --no-dev
500 error
composer install --no-dev
no more error.

file permissions

This issue about missing autoload_runtime.php is not related to files permissions. Although when we do have file permissions problems, the second composer command (install or install --no-dev) will not fix the missing autoload_runtime.php file.

If you remove the patches section from your composer.json, do you still need to install for the second time?

Ok, repeated by going back to 11.3.13 with composer and then going back up to 11.4.1. I did not recreate the lock file after removing the patches from composer.json, so there's the out-of-date lock file warning.

After the first composer install --no-dev, web/autoload_runtime.php is missing and I get the corresponding fatal error in the browser.

Output:

$ composer install --no-dev
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`.
Package operations: 5 installs, 13 updates, 0 removals
  - Installing symfony/runtime (v7.4.14): Extracting archive
  - Upgrading drupal/core-composer-scaffold (11.3.13 => 11.4.1): Extracting archive
  - Upgrading drupal/core-project-message (11.3.13 => 11.4.1): Extracting archive
  - Upgrading symfony/polyfill-mbstring (v1.37.0 => v1.38.2): Extracting archive
  - Upgrading symfony/polyfill-intl-normalizer (v1.37.0 => v1.38.0): Extracting archive
  - Upgrading symfony/polyfill-intl-grapheme (v1.37.0 => v1.38.1): Extracting archive
  - Upgrading twig/twig (v3.27.1 => v3.28.0): Extracting archive
  - Installing twig/html-extra (v3.28.0): Extracting archive
  - Upgrading symfony/polyfill-php84 (v1.37.0 => v1.38.1): Extracting archive
  - Installing symfony/polyfill-php86 (v1.38.0): Extracting archive
  - Upgrading symfony/polyfill-php85 (v1.37.0 => v1.38.1): Extracting archive
  - Upgrading php-tuf/composer-stager (v2.0.2 => v2.1.1): Extracting archive
  - Installing marc-mabe/php-enum (v4.7.2): Extracting archive
  - Installing justinrainbow/json-schema (6.8.2): Extracting archive
  - Upgrading guzzlehttp/guzzle (7.12.3 => 7.13.2): Extracting archive
  - Upgrading asm89/stack-cors (v2.3.0 => v2.4.0): Extracting archive
  - Upgrading drupal/core (11.3.13 => 11.4.1): Extracting archive
  - Upgrading drupal/core-recommended (11.3.13 => 11.4.1)
 13/14 [==========================>-]  92%    Skipped installation of bin scripts/dr for package drupal/core: name conflicts with an existing file
Generating optimized autoload files
50 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Scaffolding files for drupal/core:
  - Copy [web-root]/.htaccess from assets/scaffold/files/htaccess
  - Copy [web-root]/example.gitignore from assets/scaffold/files/example.gitignore
  - Copy [web-root]/sites/development.services.yml from assets/scaffold/files/development.services.yml
> DrupalProject\composer\ScriptHandler::createRequiredFiles

After the second composer install --no-dev, web/autoload_runtime.php now exists and the fatal error is gone.

Output:

$ composer install --no-dev
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`.
Nothing to install, update or remove
Generating optimized autoload files
50 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> DrupalProject\composer\ScriptHandler::createRequiredFiles

I just ran the following to try to reproduce this from a clean install:

$ composer create-project drupal/recommended-project:11.3.13
[composer download output]
$ cd recommended/project
$ ls web/auto*
web/autoload.php
composer update drupal/core-recommended -W
Do you trust "symfony/runtime" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?] y
ls web/auto*
web/autoload.php  web/autoload_runtime.php

In that case autoload_runtime.php is getting created fine.

Note I didn't bother installing the site or anything nor changed permissions in any way.

@kentr and/or @xmacinfo would you mind trying the same steps? It would be good to rule out environment/composer version issues. Then if that works, maybe we can isolate what's different on the actual site installs that are running into this.

Here's how we were able to upgrade Core from 11.3.13 to 11.4.1:

The first composer update does not create the autoload_runtime.php file. However, running composer install afterwards does create it. Now the site works in a localhost environment. But when deploying a new build artifact to one of our non-production environments, we get the WSOD and a message in the PHP error log saying that autoload_runtime.php does not exist.

Back in my localhost environment, after running both composer update and composer install, a .gitignore file in the same directory as autoload_runtime.php has autoload_runtime.php listed in it. I simply removed it from the .gitignore file, redeployed a new build artifact, ran database updates and flushed caches via drush, and voila!

would you mind trying the same steps? It would be good to rule out environment/composer version issues. Then if that works, maybe we can isolate what's different on the actual site installs that are running into this.

The steps in #46 also worked for me; web/autoload_runtime.php was created as expected.

I'll try to recreate using the "bad" composer.json, or post a diff for others to analyze.

I can reproduce on a project of ours starting on 11.3.11:

$ ls web/auto*
web/autoload.php

$ composer update drupal/core-recommended -W
...
  - Upgrading drupal/core (11.3.11 => 11.4.1)
...
symfony/runtime contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
Do you trust "symfony/runtime" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d] y
  - Installing symfony/runtime (v7.4.14): Extracting archive
...

$ ls web/auto*
web/autoload.php

$ composer install
...

$ ls web/auto*
web/autoload.php  web/autoload_runtime.php

I think we might be running into https://github.com/composer/composer/issues/6408

What happens is:

1. Composer boots and loads the Drupal 11.3 scaffold plugin
2. composer update runs and downloads Drupal 11.4 including the updated plugin
3. Drupal\Composer\Plugin\Scaffold\Handler::scaffold() fires - but this is still the Drupal 11.3 code so it doesn't know about autoload_runtime.php

When you next run a Composer operation, the 11.4 version of the plugin is used, which does work.

However it's not clear why this is working for some environments and not others!

OK, so looking at \Drupal\Composer\Plugin\Scaffold\Plugin I think I see what might be happening.

handler() tries to lazy-load Drupal\Composer\Plugin\Scaffold\Handler class in order to prevent this sort of situation.

This is called from two events:

  /**
   * Post command event callback.
   *
   * @param \Composer\Script\Event $event
   *   The Composer event.
   */
  public function postCmd(Event $event) {
    $this->handler()->scaffold();
  }

  /**
   * Post package event behavior.
   *
   * @param \Composer\Installer\PackageEvent $event
   *   Composer package event sent on install/update/remove.
   */
  public function postPackage(PackageEvent $event) {
    $this->handler()->onPostPackageEvent($event);
  }

My hypothesis is that if postPackage() is called *before* drupal/core-composer-scaffold is updated, then the old 11.3 version of Drupal\Composer\Plugin\Scaffold\Handler is loaded, and the autoload changes aren't there yet. If this happens *after*, then the 11.4 version is loaded instead, and everything works. I currently have no idea how to test this given it involves downloading and replacing code!

We might be able to work around it by extracting the autoload_runtime code from Drupal\Composer\Plugin\Scaffold\Handler into its own class that will only ever get autoloaded in the postCmd event, after the plugin has been updated? (as per the suggestion in https://github.com/composer/composer/issues/6408)

edit: I don't think this is going to work, because whatever we instantiate needs to be referenced from the 11.3 codebase already?

Managed to reproduce my hypothesis on my project. Starting on a clean 11.3.11, I edited vendor/drupal/core-composer-scaffold/Handler.php and added debug_print_backtrace() to the constructor.

$ composer update drupal/core-recommended -W
...
symfony/runtime contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
Do you trust "symfony/runtime" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d] y
  - Installing symfony/runtime (v7.4.14): Extracting archive
#0 .../vendor/drupal/core-composer-scaffold/Plugin.php(142): Drupal\Composer\Plugin\Scaffold\Handler->__construct()
#1 .../vendor/drupal/core-composer-scaffold/Plugin.php(115): Drupal\Composer\Plugin\Scaffold\Plugin->handler()
#2 phar:///.../composer/src/Composer/EventDispatcher/EventDispatcher.php(232): Drupal\Composer\Plugin\Scaffold\Plugin->postPackage()
#3 phar:///.../composer/src/Composer/EventDispatcher/EventDispatcher.php(161): Composer\EventDispatcher\EventDispatcher->doDispatch()
  - Upgrading drupal/core-composer-scaffold (11.3.11 => 11.4.1): Extracting archive
...
  - Upgrading drupal/core-recommended (11.3.11 => 11.4.1)
#0 phar:///.../composer/src/Composer/Plugin/PluginManager.php(281) : eval()'d code(142): Drupal\Composer\Plugin\Scaffold\Handler->__construct()
#1 phar:///.../composer/src/Composer/Plugin/PluginManager.php(281) : eval()'d code(115): Drupal\Composer\Plugin\Scaffold\Plugin_composer_tmp0->handler()
#2 phar:///.../composer/src/Composer/EventDispatcher/EventDispatcher.php(232): Drupal\Composer\Plugin\Scaffold\Plugin_composer_tmp0->postPackage()
#3 phar:///.../composer/src/Composer/EventDispatcher/EventDispatcher.php(161): Composer\EventDispatcher\EventDispatcher->doDispatch()
...

After this, my changes to vendor/drupal/core-composer-scaffold/Handler.php have been removed as the file has been overwritten with the new version, and the next composer install succeeds as designed.

I am not sure why the plugin is run twice, the second time with eval(), but the Handler class itself is the stale version in both cases. Maybe the eval() is the workaround for my edit in #51: the plugin class itself is renamed and reloaded, so it *can* be self-updated?

For now should we add something to the release notes recommending that people un both composer update and composer install when updating to 11.4 and also double check that any build pipelines definitely include autoload_runtime.php in the artifact prior to a production deployment?

I'm also wondering if we should consider backporting only the scaffolding changes to an extra patch release of 11.3 and maybe 10.6, then sites that get onto the latest versions of those first would already have the plugin so it would run properly when they update to 11.4. Although if we can find a permanent workaround for the loading weirdness that would obviously be a lot better.

Taking a look at scaffold, we currently use the handler for two things:

   * Post command event callback.
   * 
   * @param \Composer\Script\Event $event
   *   The Composer event.
   */
  public function postCmd(Event $event) {
    $this->handler()->scaffold();
  }
   
  /**
   * Post package event behavior.
   *
   * @param \Composer\Installer\PackageEvent $event
   *   Composer package event sent on install/update/remove.
   */
  public function postPackage(PackageEvent $event) {
    $this->handler()->onPostPackageEvent($event);
  }

Would it help if we split that into two classes? e.g. if ::postPackage() gets called more often or earlier than ::postCmd()

edit:

The work in postPackages is to record things that later get used in the scaffold file, but that can still be two separate classes if we use a singleton/static for the post package stuff probably?

I believe postPackage gets called zero or more times depending on what is installed, and after that postCmd gets called exactly once.

Given the eval appears to ensure that Plugin.php is always reloaded with the new version for the postCmd at least, I think this is fixable in 11.4 with some careful refactoring.

Working on a fix and test for this.

MR!16266 solves the issue by adding another method that generates autoload_runtime.php to \Drupal\Composer\Plugin\Scaffold\Plugin, which is guaranteed to be reloaded after the plugin itself is updated. There is also test coverage which emulates the previous version by removing that code and then upgrading the plugin in place.

Parts of the fix and all of the test in this MR were written by Claude Code.

Couple more questions on the MR.

Bumping this to major since while there are workarounds (like running composer install) it's clearly been tripping a lot of people up.

Thanks for reviewing, replied to all comments.

@longwave May I suggest keeping "HTTP ERROR 500" in the issue title as it should make the issue easier to find for others. Something like: HTTP ERROR 500: Scaffold plugin does not always create autoload_runtime.php when upgrading to 11.4 will send more people in the right direction.

I have one minor nit in that I'm wondering if the test coverage should be in a new class, with a @todo to remove once we stop supporting updates from 11.3, so that its' easier/cleaner to remove it then. But that's very minor and this is urgent to get in, so moving to RTBC.