Recent commit to try and set $base_url needs rethinking

15:25 < killes> that's the kind of usability a programmer would come up with, I guess. :p

What I mean is that a programmer tries to fix things the automagic way. This is not appropriate if it has such a high rate of possible failure.
I could provide a way to set this including subdirs, but then I would demand that this be encapsulated in a function. settings.php is a configuration file that shoudl be understandable by people.

I agree with Morbus. Please remove this change. I ran into this today, since when I install test sites, they always go in http://localhost/whatever_patch_im_working_on.

Now, *I* know enough about PHP to know I can just change:

$base_url = 'http://'. $_SERVER['HTTP_HOST'];

to

$base_url = 'http://'. $_SERVER['HTTP_HOST'] .'mysub';

or even

$base_url = 'http://localhost/mysub';

I wouldn't expect an end-user to know this though (yes I know it's written in the docs above but I guarantee you most people don't bother reading that unless they're deviating from the normal course of action).

But I will +1 the two examples given:

* $base_url = 'http://localhost';
* $base_url = 'http://example.com/drupal';

It's come up in #drupal_support and on the support forums many times where users install to a subdirectory but think $base_url is just the http://www.example.com part. I normally clarify this with, "Just enter whatever you type into your browser to get to your Drupal page" but I don't know if that's appropriate for installation documentation.

But how is that different than having the default being localhost?

localhost is useless unless it is the same machine you are running the browser on.

People will change it anyways, so putting a default that has more chances of running out of the box is better than localhost, me thinks ...

For me, I will also change it anyway ...

I was the one who spoke with Dries that we should use the 'tolerant base URL' in bootstrap and let settings.php override it if needed. He found that too complicated and made a quick commit. We _are_ better with the current settings than we were before -- most Drupal sites are at 80 and in the root. Those who are not are free to change the setting.

Sorry, I disagree. the new setting is much more confusing for users who have to change it. And you'd be surprised how many people start their Drupal experience with a site in a subdirectory because they want to test it.

i'm going to agree with Morbus, with the old setting it was obvious what you needed to change. the new one has too much "magic" to it.

This change in the settings.php file will confuse many users -- while I understand the perceived advantage (it will work fine for most people most of the time), it will deter many new users. So, either the syntax needs to be documented much more clearly -- such that a person who has never coded can make sense of what to do -- or this patch should be rolled back. As it stands, however, this will deter new users from trying/using drupal.

Morbus,

The present setting (http://localhost) is more confusing. The site will display OK, but clicking on any link will not work.

The new setting has more chances of working right out of the box.

The comments already give examples:

* Examples:
* $base_url = 'http://localhost';
* $base_url = 'http://example.com/drupal';
*

The real solution to all this is for an installer to set all this correctly, and no need for manual editing at all.

Until then, I think the newer setting is better. What we need is some more comments in the file (e.g. "you have to replace the entire line by blah if you have installed in a subdirectory"), and of course documentation to match this.

Regarding lack of community input, I am with you on this. This should have been at least advertised. Of course, I am giving chx and Dries every benefit of the doubt on this. They are stressed, overworked, ....etc. so this just slipped by ...

How about something like this then:

// 
// By default, Drupal tries to use a setting that should work in most cases.
$host = $_SERVER['HTTP_HOST'];
//
// $host = 'www.example.com';
// $host = 'www.example.com/subdirectory';
// You can uncomment a line above and put your own host name and subdirectory
// if you want to have Drupal in a subdirectory
//
// Do not change the line below
$base_url = 'http://' . $host;

All I did was break down into two components, and $host is the only place that needs to be uncommented and changed.

Again, this is mostly a documentation issue. If it is in the INSTALL.txt, on the Handbook, and in the comments, then it is a non issue.

I The problem, of course, is since you and Dries went behind everyone's backs

Dries have made changes to Drupal core more than once without asking anyone and there was no rucus. And I have just asked his opinion in this matter nd have not indeded to backstab anyone, I wanted to roll a patch after knowing his views on this.

Morbus, just because you do not like this change you do not need to cry foul. Peace.

So once again, I just asked Dries why we are not using this code, straight out of handbook, I thought there is a special reason.

Get rid of double ?:

Better wording may be:

* This is the base URL of your website. Normally, this is the main page
* of your site. Usually Drupal can automatically find this by itself.
* If it does not work, remove the // characters and put your
* domain/subdomain name.
* It consists of a hostname, and an optional subdirectory
* name. If you installed Drupal in the main directory of your site, then
* do not include a directory. A trailing slash is not allowed, since Drupal
* will automatically add it for you.

Once concern (or maybe a clarification), what happens if a site is accessed as www.example.com and as example.com? Both will work, but some features in Drupal may break.

For example, the external referer in admin/logs will sometimes consider www.example.com to be external, and on others will consider example.com to be so, hence giving an incomplete picture. There are some cache set/get in bootstrap.inc. In aggregator, the base_url is used.

Gosh, I've made thousands of commits without consulting the larger community, and I will continue to make changes without consulting the larger community. You make it sound as if I did something aweful, while this is what I used to do all the time. Relax, Morbus. I'll let you guys figure this out, and I'll commit whather change you come up with.

Also note that the issue is not assigned to me, anyone (for eg. kbahey, Morbus) should feel free to take over.

Just a few _sweeping_ changes: last November Dries refactored statistics module. Steven recently made a unicode.inc . I do not quite remember whether the new filter system got a peer review last fall or not.

I am fine with this model. If you want, consider it this way: for the upper class, peer review happens after commit and not before. Case closed.

for the upper class, peer review happens after commit and not before. Case closed

That's very arrogant. Almost to the point of flamebait.

I know Drupal isn't a democracy, but what is the big deal about putting all patches in the patch queue? Even if Dries applied the patch straight away without review the patch queue would at least be the correct 'Drupal' place to make comment and submit improved patches - bypassing the whole review process and leaving the responses to bug reports is imnsho just wrong.

Secondly, it sets a very bad example to other developers - pester Dries and get your patch applied...

Noone reads what I say? Is my English so terrible that you can not understand what I am trying to communicate through?

There was no patch, let me quote myself: "I have just asked his opinion in this matter nd have not indeded to backstab anyone, I wanted to roll a patch after knowing his views on this" and then he committed something what surprised even me.

By "upper class" I meant Dries and Steven and noone else.

No, it's not about pestering Dries and getting your patch committed. If I want my patch committed I post a followup "what holds this patch?"

I believe te fact a users gets as far as settings.php at least means he or she can read and can copy-paste. This patch does no longer use any "Smart" magic, but merely informs users about what to do .
I could not find a handbook page, but otherwise I would refer to also add a link to that page in the settings.php comments.

some odd line slipped in.

I vote for having the host populated automatically by default, and having an extra (optional) subdirectory variable, and possibly even a port variable.

So it would be :

/**** top of file ****/
/* if you run drupal in a sub directory, change it here */
$subdir = '';


/*** base url configuration - closer to the bottom of the file ****/
$host = $_SERVER['http_host']
$port = 80;

$base_url = 'http://$host" . ($port ? ":$port" : '') . ($subdir ? "/$subdir" : "");

I also trust dries enough to agree with the current commit practices.

In fact, I hardly understand all this buzz and fuzz about this setting. I really do not have the feeling that this is an issue at all.
It never comes up on the supp. mailinglist, if it comes up in the forums (and that is not too often) it is always solved within the day. There was one person who had some issues lately, but that is about the only one I can recall.

Also the CS usability investigation did not point out that this was a big issue. Can we not just leave it the way it was (never fix something that aint broken) and put all this energy into getting the install system up?

$base_url = 'http://$host" . ($port ? ":$port" : '') . ($subdir ? "/$subdir" : "");

Please, please no. :)

Users understand what an "address" (URL) is for a page. It's the thing they type into their browser to get to a website:

http://drupal.org/about

They don't know that "drupal.org" is the host name, and "about" is a subdirectory, and it's running at the default port 80 so they don't need to change it.

Either have enough flexibility in the "smart" method of figuring this out to detect:

1. http or https
2. host name
3. port number
4. subdirectory

(aka the full path to my Drupal installation, no matter what wacky place I stick it)

or keep it as-is, let the user enter it his/herself, and just write better docs above the section to explain what that setting is for.

A question about this "smart" method of figuring it out though. Will this mess up statistics packages? Because the nice thing about a 'hard-coded' $base_url right now is that if I specify:

$base_url = 'http://www.example.com';

If a user tries to go to just http://example.com, it will automatically expand it to www.example.com when they click on any links.

@webchick my last patch does nearly all you ask for, mind reviewing it? :)

I alluded to the statistics issue in #18. It will affect Drupal statistics, e.g. external vs. internal referers.

Anything that uses $base_url has the potential to be affected by this flexible host name thing.

@berkes: I like your "patch" except that it fails to recognize that $base_url presents a real problem for users. I answer questions about this on forums and in #drupal_support two or three times per week, easily (I literally just finished answering it yet again). I'm not sure why the mailing lists don't reflect this trend, other than perhaps the mailing lists tend to get a more "technically savvy" audience than the forums since the forums are just "there" for anyone to post to... I don't know if most users who weren't using the Internet back in the mid-90s have ever touched a mailing list.

There are two problems that I see coming up consistently:

1. User leaves setting at http://localhost since he can see that fine on his computer, but since everyone else is accessing it via http://something.homelinux.org or whatever, it breaks for his visitors. (this is less common, though should be solved by the current method)

2. User installs to subdirectory, such as http://www.example.com/drupal, thinks $base_url refers to only the "base" part of the URL (http://www.example.com) and can't figure out why nothing works. (this is VERY common, and the current way only makes solving that problem harder and even more confusing)

But overall, I agree. Revert, and improve documentation, imo. Unless the "fancy" way can be made to deal with all the possible scenarios a user can throw at it.

@kbahey: Sorry, I didn't mean to reiterate what you'd already said. :(

I have the same perception as webchick that this is a common problem. I've been using this snippet for awhile and really like it. So my vote is to use chx's settings_3.patch

+1 Morbus!! :)

+1 For the Morbus way.
Was't KISS one of Drupals philosophies?

There seems to be a consensus on Morbus' solution.

Committed to HEAD. Thanks.

Okay, I know I'm weighing in late, but.....

+1 on the current state of HEAD (per Dries' latest commit). Among other things -- and I haven't seen anyone else mention this -- the use of "example.com" rather than something like "localhost" specifically complies with IETF RFC 2606, section 3, in the choice of second-level domains for documentation purposes.

Scott

Yes well I liked Dries commit better as well but hadn't had time to test it until last night. tested fine last night. Now I will have to test the new one sooner than later.