Closed (won't fix)
Project:
Drupal core
Version:
7.x-dev
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
9 Oct 2008 at 18:12 UTC
Updated:
9 Oct 2008 at 21:03 UTC
Jump to comment: Most recent file
Comments
Comment #1
gpk commentedSee also the section Including Code at http://drupal.org/coding-standards. The distinction between require_once and include_once passes over my head somewhat :P
Comment #2
webchickSubscribe. Thanks, gpk!
Comment #3
kbahey commentedSubscribing
Comment #4
kbahey commentedHere is a patch that is tested and works.
The only exception is that install.php calls requires install.inc first, then requires bootstrap.inc after that, so I had to use ./includes/install.inc here.
Comment #5
webchickWait wait wait. We don't want to remove DRUPAL_ROOT. We want to just define it in one place.
Comment #6
webchickOhhh nevermind. I need to read patches. ;)
Comment #7
damien tournoud commentedI'm not sure I like this.
Sure we have a little code duplication by setting DRUPAL_ROOT at the beginning of every entry point. But there are not many of them, and we already have other shared code (namely include_once 'includes/bootstrap.inc' and 'drupal_bootstrap()'). With this patch we will go backward in term of consistency, because now there are some './' ... and some DRUPAL_ROOT . '/' ...
My call: this patch doesn't worth it.
Comment #8
kbahey commentedThe reason for this patch is to have DRY (Don't Repeat Yourself). This way, command line modules like drush don't have to define DRUPAL_ROOT either. See Moshe's comment in the linked issue.
bootstrap.inc is always required using the ./ syntax, so it is consistent.
The only exception is install.inc when included in install.php, and that is because it is the first include. If it can be moved after bootstrap.inc is included in install.php, we will be 100% consistent, but I am not sure if that is feasible (if it was, someone would have done it already).
Comment #9
dries commentedI'm with Damien on this -- it is probably not worth it.
Comment #10
webchickYeah, upon reviewing Damien's comments, and especially with Dries's -1, I think it's safe to put this in the "won't fix" bucket. Sorry for the trouble. It sounded good on paper, but it introduces lots of special cases which is going to lead to poor DX and developer confusion.