Problem/Motivation

This is a new thread to gather discussion, regarding the issue that it's currently problematic to bootstrap Drupal from a PHP script that lives outside of the Drupal root directory (without a chdir() call), due to instances in core and contrib where DRUPAL_ROOT is not used in file includes everywhere that it should / could be.

Background: I recently built a non-Drupal PHP app (a Silex / Symfony2 app), which bootstraps Drupal 7 and which utilises Drupal for various tasks (e.g. authentication, page rendering). This app's index.php file lives outside of the Drupal install directory, and it manually sets DRUPAL_ROOT and $base_url before including and running the Drupal bootstrapper.

For the most part, my attempts at this integration went smoothly. However, on several occasions I ran into something that wasn't working, due to an include_once / file_exists() / etc call, in core or contrib, that doesn't prepend DRUPAL_ROOT to a filepath.

Proposed resolution

I originally had no doubt that all of the DRUPAL_ROOT bugs I found were bugs, and that the correct solution is to slowly but surely patch and fix them. However, this recent issue comment has made me unsure:

@sun: If you are using a custom script to boot Drupal, which does not happen to live in Drupal's root directory, then it is the responsibility of your custom script to chdir() to Drupal's root directory. All of the custom/complementary scripts in Drupal core are doing that, and so should yours. I'm actually very surprised that your ride into bugs starts in wysiwyg.module. I'm relatively confident that I can guarantee you that your ride won't end here. What you're trying to do is known to not work in D8 even, despite a massive move towards OO-namespaced code and a class loader that looks up files based on the Drupal root.

So, the reason for this new thread, is that I'd like to open up the question: should we even be trying to fix this? Am I doing something worthwhile, in submitting these DRUPAL_ROOT patches; and are they worth reviewing and committing? Or am I wasting my time, because Drupal flat-out does not support bootstrapping from a custom script without a chdir() call into the Drupal root dir? And if Drupal doesn't support this, should we make Drupal support it; or would our efforts be better invested elsewhere?

Original reports

The bug reports that I filed are:

Core:

#1891708: Need DRUPAL_ROOT in include of template.php
#1891802: Need DRUPAL_ROOT when rendering CSS include links
#1924212: Need DRUPAL_ROOT in file_scan_directory

Contrib:

#1890872: Need DRUPAL_ROOT in require of include files
#1890866: Need DRUPAL_ROOT in require of og.field.inc (fixed)
#1924236: Need DRUPAL_ROOT in various places

If anyone finds and patches more DRUPAL_ROOT bugs, please create a new issue for that specific bug, post patches there, and add a link to the issue in this thread. Please do not add individual DRUPAL_ROOT bug reports / patches to this thread, which is to be only for discussion of the wider issue.

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Version: 7.x-dev » 8.x-dev

The issue summary only links to individual spots that are lacking DRUPAL_ROOT.

The main question of bootstrapping Drupal without a chdir() is discussed in:

#1540136: Simplify index.php by moving DRUPAL_ROOT to bootstrap.inc

Also related:
#1792310: Wrong DRUPAL_ROOT with non-standard code structure
#1827448: Use __DIR__ instead of DRUPAL_ROOT where possible/sensible

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

JvE’s picture

JvE commented
Version: 8.3.x-dev » 8.5.x-dev

I think it's a worthwhile goal to be able to bootstrap a Drupal kernel from anywhere.

Why else would we have the $app_root argument in the DrupalKernel constructor?

  /**
   * Constructs a DrupalKernel object.
   *
   * @param string $environment
   *   String indicating the environment, e.g. 'prod' or 'dev'.
   * @param $class_loader
   *   The class loader. Normally \Composer\Autoload\ClassLoader, as included by
   *   the front controller, but may also be decorated; e.g.,
   *   \Symfony\Component\ClassLoader\ApcClassLoader.
   * @param bool $allow_dumping
   *   (optional) FALSE to stop the container from being written to or read
   *   from disk. Defaults to TRUE.
   * @param string $app_root
   *   (optional) The path to the application root as a string. If not supplied,
   *   the application root will be computed.
   */
  public function __construct($environment, $class_loader, $allow_dumping = TRUE, $app_root = NULL)

From #2631362: Inject DRUPAL_ROOT into DrupalKernel

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

voleger’s picture

voleger
he/his
Primary language Ukrainian
Location Ukraine, Rivne
commented

Now that can be achieved if the Drupal core will define a separate composer template for that purpose.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

joachim’s picture

joachim commented

Possibly a duplicate of #1792310: Wrong DRUPAL_ROOT with non-standard code structure?

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now 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.

joachim’s picture

joachim commented
Status: Active » Closed (duplicate)

This will probably get fixed by #1792310: Wrong DRUPAL_ROOT with non-standard code structure. The latest MR there uses absolute paths for defining Drupal's locations.