Problem/Motivation

Since Drupal 11.4, running core/scripts/dr or the deprecated core/scripts/drupal directly fails on projects where the Drupal root is in a web/ folder. While core does not use it, that is the default layout for projects made from drupal/recommended-project, and it's also used by Drupal CMS. For example, from the web/ folder:

$ php core/scripts/drupal recipe ../recipes/my_recipe
PHP Fatal error:  Uncaught Error: Failed opening required '/var/www/html/web/core/scripts/../../vendor/autoload.php'

The script looks for the class loader like this:

$autoload_path = $GLOBALS['_composer_autoload_path'] ?? __DIR__ . '/../../vendor/autoload.php';

When you run vendor/bin/dr, Composer's bin proxy sets $GLOBALS['_composer_autoload_path'], so this works. When you run the script directly, that value is not set, so it falls back to vendor/autoload.php inside the Drupal root.

So: if the vendor folder is not inside the Drupal root, then running the script directly breaks. With a web/ docroot, vendor/ is next to web/, not inside it.

This matters because:

  • core/scripts/drupal is deprecated but still supported until Drupal 13. The change record for #3453474: CLI entry point in Drupal Core says it is replaced with core/scripts/dr. Yet both fail in the most common project layout.
  • Various documentation, tutorials, CI scripts and contrib tests run php core/scripts/drupal (for example recipe and generate-theme).
  • Before 11.4, the script loaded __DIR__ . '/../../autoload.php', which worked in every layout.

The fallback was added in #3453474: CLI entry point in Drupal Core.

Steps to reproduce

  1. Create a project with composer create-project drupal/recommended-project (Drupal 11.4 or later).
  2. Run cd web && php core/scripts/dr list, or php core/scripts/drupal list.
  3. The script fails with Failed opening required '.../web/core/scripts/../../vendor/autoload.php'.

vendor/bin/dr list from the project root works fine though.

Proposed resolution

When _composer_autoload_path is not set, fall back to the autoload.php file in the Drupal root instead of the vendor directory which may be at a different place:

$autoload_path = $GLOBALS['_composer_autoload_path'] ?? __DIR__ . '/../../autoload.php';

Remaining tasks

  • Review.
  • Backport to Drupal 11.x and 11.4.x.

User interface changes

None.

Introduced terminology

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A.

Generated with the help of an LLM.

Issue fork drupal-3633186

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

gábor hojtsy created an issue. See original summary.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new1.24 KB

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

gábor hojtsy’s picture

Status: Needs work » Needs review
gábor hojtsy’s picture

Issue summary: View changes
larowlan’s picture

I run the layout you've mentioned - with app instead of web

I've recently committed several new commands and have tested each one beforehand with no issues

I have an autoload in both vendor and app (web in your case) and autoload runtime

phenaproxima’s picture

We in Drupal CMS have been broken by this, when we try to run php core/scripts/dr .... It only works with the binary proxy, running from the project root, which is why we need this trait to work around it: https://git.drupalcode.org/project/drupal_cms/-/blob/2.x/drupal_cms_help...

Here's my current manual testing against a new Drupal CMS project (stable version), which uses the common project layout:

$ php vendor/bin/dr --version
Drupal 11.4.11

$ php web/core/scripts/dr --version
# FATAL ERROR

$ cd web
$ ../vendor/bin/dr --version
Drupal 11.4.11

$ php ../vendor/bin/dr --version
Drupal 11.4.11

$ php core/scripts/dr --version
# FATAL ERROR

When I patch dr with Gábor's change, all of these variants work fine.

phenaproxima’s picture

Status: Needs review » Reviewed & tested by the community

Marking this RTBC based on my manual testing, and the fact that this is a one-line bug fix that hurts nothing. Sure, people should generally use vendor/bin/dr, but there's no need to punish those who take the scenic route. It's one line.

quietone’s picture

Title: 11.4 regression: core/scripts/dr and core/scripts/drupal fail to find the autoloader when the docroot is web/ » [regression] core/scripts/dr and core/scripts/drupal fail to find the autoloader when the docroot is web/

Changing title per Special titles.

catch’s picture

Status: Reviewed & tested by the community » Needs work

Couple of small comments on the test.

gábor hojtsy’s picture

Status: Needs work » Reviewed & tested by the community

Addressed @catch's comments on the test.

The test now uses #[TestWith] instead of a data provider. Shorter indeed :)

As for the loop, we need to copy both when we test drupal, just not when we test dr. We can special case that, but IMHO does not hurt to copy drupal too in that case? Otherwise when testing drupal, it is not enough to copy drupal only as it requires dr to be also there. I added a comment for this, hope that helps?

  • catch committed 35b54e15 on 12.0.x
    fix: #3633186 [regression] core/scripts/dr and core/scripts/drupal fail...

  • catch committed 912a0d3b on main
    fix: #3633186 [regression] core/scripts/dr and core/scripts/drupal fail...

  • catch committed a3fb67df on 11.5.x
    fix: #3633186 [regression] core/scripts/dr and core/scripts/drupal fail...

  • catch committed 00341afa on 11.x
    fix: #3633186 [regression] core/scripts/dr and core/scripts/drupal fail...

  • catch committed 81d27473 on 11.4.x
    fix: #3633186 [regression] core/scripts/dr and core/scripts/drupal fail...
catch’s picture

Version: main » 11.4.x-dev
Status: Reviewed & tested by the community » Fixed

Committed/pushed to main and cherry-picked back through to 11.4.x, thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.