I have a fairly unmodified 4.7 beta5 site. Users have to login twice (the first attempt takes them back to the main page with the login boxes still empty), and logout twice in order for the command to take effect. Someone else had reported this a couple months ago, but they said it only happened with the frontpage module activated, so the issue was closed and moved to the frontpage module area.

I have never downloaded or installed the frontpage module, so this could not be an issue with frontpage.

If anyone would like to see the problem in action, contact me through my contact form and I'll send you a username and password for my site.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

PakWaan’s picture

Title: Users have to login and logout twice for it to take effect » Users have to login and logout twice (FIXED in 4.7 RC1)

FIXED in 4.7 RC1.

PakWaan’s picture

FIXED in 4.7 RC1.

killes@www.drop.org’s picture

Status: Active » Fixed

.

PakWaan’s picture

Status: Fixed » Active

Well, it appeared to be fixed for a while- but it appears it's not. It doesn't happen every time, but at least every other time a user logs in. Happens in Firefox, don't use IE so not sure about that browser.

PakWaan’s picture

Version: 4.7.0-beta5 » 4.7.0-rc1

Additionally, if I log out, everything appears fine - I get the login block back on the main page. However, clicking my "About Us" static page returns my logged-in name to the menu, and it appears I'm logged in. Clearing the browser cache has no effect on the problem. Re-loading the page also doesn't fix it.

kus’s picture

problem confirmed with ie/firefox 4.7 rc1

kus’s picture

...and it only occurs, if caching is enabled. without caching it works fine.

webchick’s picture

Title: Users have to login and logout twice (FIXED in 4.7 RC1) » Users have to login and logout twice

well then it's not fixed, is it? ;) let's get that out of the title

BryanSD’s picture

Kus...I just want some clairifcation, are we talking about cachng enabled for the browser or Drupal? Like others I've been seeing this problem too.

PakWaan’s picture

If Drupal caching is disabled, the problem disappears - I just tried it.

That's why I originally thought it was fixed in RC1 - the default on installation is caching disabled. It wasn't until later when I enabled caching that the problem came back.

BryanSD’s picture

My Drupal caching is disabled...and I'm still seeing the problem. Now I do have eaccelerator on the server caching my php pages, but I didn't see this problem before. What is irritating is that it is not a consistent problem.

-Bryan

PakWaan’s picture

Title: Users have to login and logout twice » Login and logout very sporadic
Priority: Normal » Critical

To follow up on my previous comments, my site and several other 4.7 sites I've been on today are all doing it. I even logged in as another user, and after clicking through a few pages, it showed me logged in as myself again. Clearing the browser cache doesn't help, and enabling/disabling the Drupal cache on the site itself is not helping either.

kus’s picture

BryanSD....i was talking about drupal caching.

kus’s picture

drual version cvs head as of 4.april 2006

i did some more testing and i can reproduce the error:

drupal caching off: always fine

drupal caching on + internet explorer 6, caching automatic (default): login is fine, but returning to the frontpage, reloads the non logged in version. a reload loads the logged in version...then everything works fine.

drupal caching on + firefox, caching 0 or something else: always needs to enter the username/pw twice and returning to the frontpage loads the non logged in version. a reload loads the logged in version....then everything works fine.

drupal caching on + internet explorer 6, caching on every visit to page: no problem

PakWaan’s picture

Well, I've had caching turned off for over 24 hours and it's still messing up constantly, as has been the experience of a few others. Just so no one tries looking only in the caching feature of the code..... but somehow it's retaining the login information somewhere it shouldn't.

chx’s picture

my two cents are on browser caching.

PakWaan’s picture

As I noted above, completely clearing the browser cache doesn't fix it. And it never did it with 4.6.

BryanSD’s picture

I'm finding that I'm seeing this issue in Firefox 1.5.0.1 and personally have not seen it in IE6. I don't think we can rule it out being a browser issue. If not a browser caching, how about a cookie issue?

Either way, there was no upgrade to my Firefox and never once did I see this problem with earlier versions of Drupal 4.7 (though I never loaded Beta 6). So to me it appears that there is something about the Drupal 4.7 RC1 upgrade that has caused Drupal and my browser to not get along.

killes@www.drop.org’s picture

Are there any errors logged in watchdog?

dww’s picture

i've been using both safari (1.3.2) and firefox (1.0.6 -- yes, i know it's ancient) on 3 different 4.7 test sites (all running the latest cvs head) and i can't reproduce any of the problems mentioned here. 1 site is my powerbook (osx 10.3), the other two are on a shared hosting site (one using php4, the other using php5). i tried all 3 with drupal caching both enabled and disabled. logging in and logging out has always worked fine. i'm not seeing anything wrong. just another data point....

BryanSD’s picture

Most times there are no errors being reported by watchdog. No wrong password or username unkown. It's as if you never even tried to log on or off. I just confirmed the issue now in IE7 Beta 2.

For those that are also reporting this problem...how did you send your files up to the server? I unpacked them on my Windows PC and then did an FTP on up to the server. Tonight, I plan on deleting all the Drupal Core flat files and see what that get's me.

BryanSD’s picture

Tonight, I plan on deleting all the Drupal Core flat files and see what that get's me.

Ok..that sounded stupid. Once the files are deleted, I'll repopulate the directories with Drupal 4.7 RC1.

joelstein’s picture

I had a user on IE6 with this problem, and just cleared the cookies and cache, and now they can login fine. I'm using RC1.

BryanSD’s picture

This problem is not related to the browser cache, but it appears to be a problem with the browser cookies (in all three IE6, IE7 Beta 2, and Firefox 1.5.0. On a theory...everyone that is having a problem...what OS are you using? I'm on Windows XP SP2.

In the process of elimination none of these were found to be the culprit:
1) Started with a frest install of Drupal 4.7 RC1 flat files.
2) Started with a fresh install of the database (no imports of the old database).
3) Cleaned out the cache, but not the cookies.

Not until I cleaned out the cookies did this problem get resolved. It would be great, but this problem did not return until after restarting the browser. When you clear the cookies...I found loggin in and logging out to not be a problem (must of done it a couple dozen times). However, it seems when you close the browser and return to your site...something with cookies and Drupal 4.7 RC1 is not working properly (no able to properly rewrite or access the cookie?).

This is all I have so far.

-Bryan

BryanSD’s picture

Sorry...you can tell it's a busy day. I meant to say the problem DID RETURN after restarting the browser.

killes@www.drop.org’s picture

can you test if the problem persists if you clean out the sessions table?

BryanSD’s picture

Clearing the sessions table had no effect. Everytime I log in, I return to the same page with no access to user/admin menu. Interestingly, each time creates a new sid in the table under the same uid.

markus_petrux’s picture

hmm... there might be problems with PHP sessions if session.auto_start is enabled (there might be records in the logs due to problems when session_start() finds the job has already been done automagically). session.auto_start is turned off in the .htaccess file provided by Drupal, but some admins may have one already and some may forget to add all relevant lines. Since this problem is not happening to everyone, it probably worths checking if you have the following in your .htaccess file.

  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0

But then again, these lines take effect depending on how your PHP is installed. So you may wish to check the values with phpinfo().

BryanSD’s picture

Verified that those are turned off.

We're on the same page with some concerns about the PHP session. I've been looking at the php.ini file and checking things out. This may have to do with server configuraiton. I've been grasping for straws...tried safe_mode off, tried eaccelerator off, etc.

Killes mention of the session table has me also looking at the session.inc. On the server, the php_value session.gc_maxlifetime is only set at 1440 (the default). While this is only 24 minutes it souldn't be causing the problem. But I almost wonder if it's possible that there maybe some conflicts in whether functions in Drupal look at my local time (CDT) and the UTC time. Well that's thought, but I'm running out of time with a busy day ahead so someone seeing this problem needs to put their weight around.

I do not have this problem with my current 4.6.5 sites (on the same server) and I don't recall having problems with some of the early 4.7 Betas.

Cheers, Bryan

drumm’s picture

Can you reproduce this on Drupal 4.6.6?

killes@www.drop.org’s picture

Bryan, can you try Drupal 4.6.6 on that server? As part of the security patches we needed to change the way sessions are generated. This patch went into both 4.6.6 and beta 6 and rc1.

BryanSD’s picture

I may have an extra domain handy where I can test a fresh install of 4.6.6. I'll need a few hours to repoint the domain.

-Bryan

moshe weitzman’s picture

in order to debug this, we really need to see it in action. please provide an url and steps to reproduce.

in addition, it would be helpful if you enabled devel.module and enabled everything on admin/settings/devel and gave everyone permissions from this module except the dangerous php ones. if that sounds hard, activate phpinfo module - http://drupal.org/node/43006

BryanSD’s picture

So far I'm not seeing the problem with 4.6.6. I'm going to let it run for 24 hours before throwing 4.7 RC1 on the server. As PakWaan and kus pointed out...you think you don't have a problem, then it strikes you. With 4.7RC1 I should be able to configure it exactly like I have it at the site causing the problems. If I see this problem return on either 4.6.6 or 4.7 RC1 I'll open up the site for the developers to take a peek.

killes@www.drop.org’s picture

Since there are many servers where this problem does not occur, I infer it isn't really critical but mostly a server setup releated issue. I am however waiting for more feedback from Bryan or anybody else).

chx’s picture

FileSize
604 bytes

Please test this patch. Go to a page which is NOT the front page and try to reproduce. If this patch fixes the problem I will cook a final one, this is just for testing.

chx’s picture

This patch tests browser issues and not Drupal. It will only work if the front page has the login block. Our purpose here is to find whether we need to fix Drupal form handling or if it's a browser issue.

killes@www.drop.org’s picture

Priority: Critical » Normal

downgrding since it is apparently browser/server specific

BryanSD’s picture

Priority: Normal » Critical

The patch did not resolve the issue. Everything with 4.6.6 worked fine but Drupal 4.7 RC1 (with and without the patch) did not.

I had a detailed message, but lost connection. To make a long story short...the only way to resolve the issue from the user's point of view is to clear the cookies (IE and Firefox). No need to clear the cache. More than likely something in the late Drupal betas and RC1 was added that is preventing sessions to be properly recognized between my server and browser.

Personally, I don't have a problem with dropping the priority from critical to normal since this could be a Server Issue. I do think however, more people will be pointing out this bug if it's not resolved as we near final release. Nothing in how my server (FC 2, PHP 4.4.2, MySQL 4.1.15, php.ini, .htaccess, etc) "appears" out of order. All Drupal 4.6 and early 4.7 RC1 betas as well as other PHP applications work just fine on the server. However, in my haste to try things I've installed/uninstalled some RPM packages that have made the server unstable. Next week I plan to start with FC 2 baseline and upgrade the RPM packages (namely for PHP and MySQL). I'll keep track of whether I see this bug or not as I do the restore.

-Bryan

killes@www.drop.org’s picture

Priority: Critical » Normal

I am in no way opposed to fixing the issue even if it should only affect a minority of people. however, in this case it isn't critical. And if people need to clear their browser cache, the only thing we can do is to clear all sessions. Actually, when I did upgrade drupal.org I cleared the sessions table so that might have helped. Can anybody try if that fixes it?

dekova’s picture

Version: 4.7.0-rc1 » 4.7.0-rc2
Priority: Normal » Minor

I'm seeing this issue in a fresh install of 4.7.0 rc2. It appears to be browser independent, I'm experiencing it with IE, Firefox and Opera.

westwindycity.com

Since my install is fresh and I haven't done anything with the site as of yet, I can let you guys poke around as admin if you'd like to dig into an install with the problem occuring. Message me if so.

moshe weitzman’s picture

jnarmandin - i can't reproduce this on your site with firefox or opera on OSX. please provide instructions to reproduce. thanks for providing a server for this.

chx’s picture

We are trying to figure out what's going. Please try replacing session.inc with http://cvs.drupal.org/viewcvs/*checkout*/drupal/drupal/includes/session.... .

chx’s picture

Let's see a link

moshe weitzman’s picture

the current theory is that there is a cookie problem here. can you please install the phpinfo module so we can see server config? see my comment in #33. also, assure that your browser is not discarding cookies.

Gerhard Killesreiter’s picture

Probably does ntot apply to a new site, but maybe to updated ones:

23:43 < seanr> killes, has someone checked the base path? A path set to include the www and
a manually placed in the theme without the www or vice versa
will cause that behavious.

seanr’s picture

has someone checked the base path? A path set to include the www and a manually placed in the theme without the www or vice versa will cause that behavious.

dekova’s picture

A little more info now, it seems that I'm generating a cookie for both www.westwindycity.com and westwindycity.com.

Seeing this, here's what I do and what I've noticed after being slightly more observant during the login process.

1. Clear all cookies.
2. Navigate to westwindycity.com (NOT www.westwindycity.com) using Firefox 1.5.0.1.
3. Login with user test/test and submit.
4. At this point, I'm redirected to www.westwindycity.com and am unauthenticated.
5. Login with user test/test and submit.
6. I'm now authenticated on www.westwindycity.com and have both cookies.

I've avoided making any changes to my default install to this point.

beginner’s picture

Does the test site www.westwindycity.com have a simple setup problem?
What do you have in sites/ ?
sites/westwindycity.com/settings.php
and sites/default/settings.php ?
and what is the base url for both?

How come you can navigate all the links without www. when you enter the site without www. but when you login there, THEN you are redirected to the www. site?

The clue is in the default/settings.php and whatever.the.site/settings.php
What's the settings, there?

beginner’s picture

Priority: Minor » Critical

Please, allow us to add and view some content (nodes) on the test web site. You'll see: when you navigate the site http://westwindycity.com/ you can navigate without the www. anywhere. but then, either when you login or logout, you are redirected to the www. site where the cookie is not valid.

It is NOT a browser issue, and it doesn't seem to be a server setup issue. It's definitely Drupal related.
At best, it is a documentation issue: how to setup the sites/ folder for different sites.

Again, check the different settings.php in the different folders.

I think it can be solved easily from there...

beginner’s picture

Version: 4.7.0-rc2 » x.y.z

4-7-0-rc2 has not been added to the '4.7 critical issues' link in the 'Contributor links' menu.

beginner’s picture

Title: Login and logout very sporadic » Login and logout problem because of sites/default/settings.php ??
chx’s picture

I doubt this issue is critical but let's hear back from BrianSD. The contributor links have been updated.

markus_petrux’s picture

hmm... maybe the problem happens when one has sites/example.com/settings.php (without the www. part) but the $base_url has been set to www.example.com

If you point the browser to example.com, since URLs do not carry the $base_url, the site can be navigated from example.com/foo to example.com/bar with no firther problems, but... as soon as you send a form, a drupal_goto takes place, which generates a header('Location: www.example.com/path').

Now, if you don't have defined a value for session.cookie_domain (default), cookies are attached to the domain used in the request (in this case example.com).

When you login, the form is still processed behind example.com, hence the cookie is created under example.com. However, when the form is submitted, the user is sent to www.exemple.com where the session cookie may not be visible. Bang! The user is sundely logged out.

Does that make sense? If so, I think the name of the directory created under /sites and the value for $base_url should use the same exact domain that is going to be used to navigate the site. One has to choose example.com or www.example.com

To force visitor to use www.example.com, just add the following to the .htaccess file:

RewriteCond %{HTTP_HOST}	!^www\.example\.com$ [NC]
RewriteRule .*				http://www.example.com/ [L,R=301]

On the other hand, if one prefers without www., then add the following:

RewriteCond %{HTTP_HOST}	!^example\.com$ [NC]
RewriteRule .*				http://example.com/ [L,R=301]
beginner’s picture

Title: Login and logout problem because of sites/default/settings.php ?? » Login and logout pb: inconsistent use of $base_url

This bug has the potential to affect all the sites that can be accessed both with www. and without... that makes a lot of people.

I just found out that I have the same problem on my live site: http://www.wechange.org/ (please don't link to it without the www.)

my settings are as follows:
I have both sites/defaults/settings.php
and sites/wechange.org/settings.php
so that the site can be accessed without the www. should someone forget it. But my preference is that people browse the site with the www. , so my base url is: $base_url = 'http://www.wechange.org';

It used to be that if someone accessed my site without the www., all the links on the page would have www. included, but the code to create those internal links must have changed, because now the links will have www. or not depending on how the site got accessed, so the base_url is no longer used to create the internal links. Why is that?

The problems comes from the inconsistency: base_url is used whenever there is a redirection (after a login or a logout, for example) but not to create internal links.

I kind of understand why it would be this way.
The question is: does this needs to be fixed or not?
If not, at least document this in comments in settings.php and have the proposed changes for .htaccess (Markus #54) commented out.

Gerhard Killesreiter’s picture

The described behaviour wrt cookies and subdomains isnt new at all. an easy fix is to set the cookie for the whole domain. I believe this should be documented in settings.php and be done with.

beginner’s picture

Status: Active » Needs work
FileSize
2 KB

patch based on Markus #54 code.

What settings need be changed to allow users to use both with and without the www. and make sure the cookie covers both?

beginner’s picture

beginner’s picture

FileSize
2.02 KB

slight adjustment.

markus_petrux’s picture

Status: Needs work » Active

Regardless of the directory from where Drupal grabs the settings.php file, there is only one $base_url that is going to be used wherever drupal_goto is executed (ie. at form submit).

So I think the .htaccess rules posted above are somehow necessary, to avoid creating cookies that are not accessible from $base_url.

Worths to mention that cookies could be accessible from both example.com and www.example.com by setting:

ini_set('session.cookie_domain', '.example.com'); // note the leading dot ;-)

However, that cookie could be accessible from other subdomains too, which might not be desired. It depends on who runs both sites (security? privacy?) and also whether the other subdomains also need the PHPSESSID (it could be overwritten by different applications or the session data could be on different databases, which would break the thing).

beginner’s picture

FileSize
2.92 KB

You mean this way?

markus_petrux’s picture

More or less, but I think the description is not enough to cover all possibilities.

You might want to look at this too:
http://drupal.org/node/56357

It is related, but here we have introduced a mod_rewrite (optional or maybe not) rule to ensure visitors use the domain that matches $base_url, which is the one Drupal will use after form submit!

If that mod_rewrite rule is not used (ie. a particular full qualified domain is not enforced), it will probably confuse visitors if they init their navigation with a domain that doesn't match the $base_url.

beginner’s picture

I'd like several people to comment on the following, and I'll reroll another patch if necessary:

Those two issues (#56634 and #56357) are indeed very much related.

Why not combine them into one patch, either here or ther?

Or shall I provide a patch for .htaccess only, and the other issue will deal with settings.php (including our concerns here)?

chx says there what I already said above: there is a documentation issue involved, and we can't ship Drupal with the whole documentation. The patch can include a brief summary of the issue, and a link to the Handbook page (to be created) that will discuss this issue in more depth. But the handbook page must be created before a patch can be made, so we have the proper link in it. Markus? You understand the issue better than me. :)

Anything else?

(by the way, the preview still doesn't work. I thought that issue had been solved very recently?)

NaX’s picture

It was my understanding that you need to setup a site settings file per a domain name pointing to that site.

You would need have

sites/default/settings.php >> $base_url = 'https//example.com';

and

sites/www.example.com/settings.php >> $base_url = 'http://www.example.com';

When I did this on my test site for RC1 it stopped the double login problem.

If you have many sites running form the same drupal installation then it could become a little bloated. with settings.php files for every A record. In most cases every site has at least 2 (with and without www)

Maybe an alias array variable should be add to the settings.php file

sites/default/settings.php >> 

$base_url = 'http://example.com';
$alias_url = array('http://www.example.com');

So when conf_init() includes the settings.php file it loops through the $alias_url array first and if nothing matches then it uses $base_url. If something does match then it overrides $base_url with the matching $alias_url.

Or we should be able to put sub domains in the sites/default/ directory

eg.

sites/default/settings.php >> $base_url = 'http://example.com';
sites/default/www/settings.php >> $base_url = 'http://www.example.com';

And when conf_init() tries to load the settings.php for that domain name it should exclude the sub domains part when trying to find the sites directory using the domain name. Then sub directories would be the sub domains.

That way it would work the same as DNS.

But that would mean that the database settings would be in multiple places. What I would do then is that if you leave the $db_url out in any of the other alias/sub sites then it uses the main settings.php files $db_url. So that way the sub domain settings.php overrides any thing in the default settings.php, but if left out it uses the sites main settings.php file. This can be done by the order the settings.php files get include.

Hope that makes sense.

markus_petrux’s picture

Using alias in settings.php is a good point. However, (I may not see the point) isn't it easier to choose with or without www. at once?

What if people start posting links here and there with both methods in regards to SEO, PR, etc.? Does that affect? I mean, are they going to see 2 different sites with same exact contact? Does that affect PR? :-/

beginner’s picture

Status: Active » Needs review
FileSize
1.07 KB

Here's a patch only for .htaccess.
I think this at least could go in. The rewrite rule is useful if for SEO and PR (or other) purposes the site is to be accessed only one way (with www. for example) but without locking people stumbling on the site the other way (without www.).

The discussion about settings.php could carry on, and be combined with the other issue, since there is some code overlap.

beginner’s picture

By the way, something similar to that patch is good enough for Drupal.org : try accessing the site with www.
http://www.drupal.org/
:)

The patch doesn't not hinder site accessibility, but avoids the problems described in this issue.

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

+1 for the patch in #66. the best way to solve this is to document in .htaccess. it is essential for search engine rankings that there only be one domain for a given site .. i would like to see a documentation patch to settings.php as well but we need a handbook page first, and thats being handled in a separate issue.

dekova’s picture

Patch in #66 did the trick for me (as I'm sure you guys knew it would). My previous offer still stands if someone would like to do a bit more testing, but I imagine you're off to squash bigger and better bugs.

beginner’s picture

I think I found out what has changed in Drupal 4.7 that created this bug:

http://drupal.org/node/22218#base
We no longer use the base element

In versions of Drupal prior to 4.7, we used the HTML BASE tag to indicate the base to which all relative links should be appended to. In Drupal 4.7, however, the BASE tag has been removed entirely.

Before, in Drupal 4.6, the base element ensured that internal links would be consistent with $base_url . Even if the user enters the site the "wrong" way (say without www.), as soon as the user clicks any internal link, s/he is redirected to the "right" site (with www.).

In Drupal 4.7, without the html base tag, the user could browse the "wrong" site , bookmark it, post links to it... but they would have problems when trying to login, etc.

bermin’s picture

I have a feeling that there are more than one causes for this problem depending on your particular environment.

For those of you who find that the problem is not related to $base_url settings and are still experiencing the login problem, you may want to try this:

Something has changed in user.module after 1.583. Once I reverted back to 1.583 I found that login worked once again.

see node/56752

PakWaan’s picture

This issue has nothing to do with the utf-8 conversion issue mentioned in post #71.

I tried the new .htaccess settings mentioned by "beginner" in post #66. This seems to have solved the problem.

THANK YOU!!

Steven’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
8.31 KB

Killes, chx and me had a discussion on #Drupal about this issue. We felt it was time for the return of the tolerant base URL instead. A commented out .htaccess statement is not going to reach many people. Some people can't even use .htaccess. With a tolerant base URL, you will always stay on the same site you requested.

However, there is a difference with the previous attempt (which was very controversial). Instead of putting the tolerant $base_url directly into settings.php, we make the specification of $base_url optional instead (commented out). This avoids putting unnecessarily complicated code in settings.php. For existing users, nothing changes, because their settings.php file still defines the $base_url. It is also more interesting from a performance perspective that we do not first build and then again break apart the tolerant base URL.

However, after making this change I looked at how exactly the $base_url is used across Drupal. There are several places where it is used incorrectly, for example as a prefix for request_uri() (e.g. cache CIDs for the page cache). This will result in repetition of subdirectories because request_uri() is root-relative: http://localhost/drupal (root) + /drupal/node/123 (request_uri). To solve this issue I added a third base variable called $base_root: don't worry, it is very easy to extract (a simple substr) so there are no performance concerns by far.

$base_root also allows us to fix the outstanding issue where the watchdog's location links were wrong (they were request_uri()s, passed through url() as drupal paths) [can't find the issue atm]. This seemingly unrelated bug is in fact now tied to this one. When the base URL is tolerant, we have no choice but to store the complete absolute URI in the watchdog logs (i.e. on save). Otherwise the URL that the admin sees later in the log would not always be the same as the one the user requested from the server.

Summary:
- More sensible name for conf_init() -> conf_path() which only finds the config file path.
- Minor code cleanup in DRUPAL_BOOTSTRAP_DATABASE (separate loading of config file to conf_init())
- Introduce (optional!) tolerant base URL in bootstrap.inc. Keep settings.php clean. Only adds a single 'isset' statement compared to before this patch, if you still prefer a fixed base url.
- Introduce $base_root global.
- Fix unnecessarily long page cache CIDs.
- Fix bad URLs on watchdog logs.

For those who still want the .htaccess redirect, I left it in.

moshe weitzman’s picture

nice! i always use tolerant base url so this is one less step during config of new step.

a couple nits:
- this is wordy. use .= operator: $base_url = $base_url . $base_path;
- repeated word: + * and fill in the the URL to your Drupal installation.
- do we use hashmark for comment anywhere else? seems inconsistent
- I might add a sentence to settings.php like: "You might also want to force users onto a given domain by uncommenting the proper line in .htaccess file."

markus_petrux’s picture

Regarding HTTPS detection... it seems there are some servers that may set the value to 'ON'.
http://beeblex.com/lists/index.php/php.general/190410

And out of curiosity I checked how this is done is phpMyAdmin:
CVS:phpMyAdmin:/libaries/Config.class.php
Check out the method isHttps() close to the end of the file.

They look at REQUEST_URI for the presence of a scheme, but I checked my phpinfo and found that it just had a relative path (no scheme). OTOH, SCRIPT_URI has the scheme in there.

Go figure :-)

beginner’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
1.97 KB

Can we commit this patch first. It is self contained and leaves the wider settings.php issue open for further discussion. Also, nobody has voiced anything against it, on the contrary.
This new patch is basicaly the same as #66 with a few comments added in settings.php. Commit either #66 or this one.

Actually, Steven's latest comments at #73 make this patch even more necessary.

We felt it was time for the return of the tolerant base URL instead.(...) With a tolerant base URL, you will always stay on the same site you requested.

This latest statement makes the current patch even more necessary. Many site owners would want all the users to access the site the same way (say with the "www.") for several reasons:

1- for SEO and site ranking optimization.

2- for logs/statistics consistancy. I'd hate to see that http://example.com is the leading referrer to http://www.example.com

3- Webchick (38841#57130) pointed out that "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." Unfortunately, since the html tag BASE has been removed, it is no longer true. With Drupal 4.6, this double login/double logout problem was hardly present, because people were all forced to browse the site the same way (as set by $base_url). Now, with Drupal 4.7, we have both removed the BASE tag and we speak about a tolerant base URL.

4- as I pointed out above, this patch is good enough for Drupal.org: try accessing http://www.drupal.org/ (with www.). So why not share with the wider community the "dog food" that drupal.org is eating?

While this patch doesn't solve all the problems, and more changes would have to be made in settings.php and more documentation would have to be written to address every concern, the main change addressed by this patch concerns only .htaccess and will not be affected by any other changes that will be made in settings.php.

Also, if you read what Steven says, and read the issue he points to, the changes they have in mind are much more extensive, and as such, have virtually no chance to be committed in Drupal 4.7.

This patch however is a no-brainer and can be committed now and will already avoid many problems by itself (problems that were introduced only recently by the removing of the BASE tag).

So, +1 for committing this before we discuss the remaining issues.

(and preview still doesn't work).

chx’s picture

beginner, if you have looked into Steven's excellent patch then you'd see that it does include your htaccess addition and besides that it fixes request_uri which is broken for so long that I can not remember it.

Get it in, please.

beginner’s picture

Ooops! I didn't notice his attached patch.
Thank you chx for pointing it out.
Sorry.

(I shall always have the excuse that I'm only a beginner ;-) )

killes@www.drop.org’s picture

Status: Reviewed & tested by the community » Fixed

This has been commited with Moshe's suggestions implemented.

Steven’s picture

Moshe: the idea of the hash sign (which I failed to explain in the issue for lack of sleep) is to clearly distinguish the lines people can uncomment, from the stuff they shouldn't uncomment. The other 'nitpicks' are right on.

Committed (with moshe's suggestions) to HEAD.

PakWaan’s picture

One nitpick - the instructions in this patch say to "comment out" the following lines to use them - shouldn't that be "uncomment" the following lines, since they are all commented out already?

JonBob’s picture

Priority: Critical » Normal
Status: Fixed » Needs review
FileSize
1.06 KB

Agreed with PakWaan.

rstamm’s picture

the variable $conf in settings.php is ignored
http://drupal.org/node/58418

webchick’s picture

Status: Needs review » Reviewed & tested by the community

JonBob's patch is a no-brainer, RTBC.

rubenk’s picture

Simple question. On a multi-site single installation, how will

RewriteCond %{HTTP_HOST} !^www\.examplesite\.org$ [NC]
RewriteRule .* http://www.examplesite.org/ [L,R=301]

not create a conflict when using header-host redirect?

markus_petrux’s picture

When more than one subdomain points to the same documents root (please, correct me if that's not what you mean), I think you could do one of the following things:

RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteCond %{HTTP_HOST} !^subdomain1\.example\.com$ [NC]
RewriteCond %{HTTP_HOST} !^subdomain2\.example\.com$ [NC]
RewriteRule .* http://www.example.com/ [L,R=301]

Various RewriteCond do a boolean AND.

or:

RewriteCond %{HTTP_HOST} !^(www|subdomain1|subdomain2)\.example\.com$ [NC]
RewriteRule .* http://www.example.com/ [L,R=301]

or maybe simply:

RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule .* http://www.example.com/ [L,R=301]

Note that either way you're choosing a "default" site when nothing is specified, www.example.com in this case, but it could be any other subdomain (f.e. foo.example.com instead of www.example.com).

rubenk’s picture

Close. I actually have multiple domains in one install. I.e. nowhere.com , nothing.com , and samsalive.org when a person types in nothing or samsalive (the non default sites) then drupal looks at the header and redirects. i'll take a look at what you've put down and see if I can get it to work. I am trying to male sure each of the three sites, each with distinct content, has to have a www in front of them. thank you so much to everyone who helped I'D this logon problem.

markus_petrux’s picture

hmm... if I understand you correctly, you wish them to use the www. prefix?

If so, I think you could try something like this:

RewriteCond %{HTTP_HOST} !^(nowhere\.com|nothing\.com|samsalive\.org)$ [NC]
RewriteRule .* http://www.%1/ [L,R=301]

If you don't wish them to use the www. prefix:

RewriteCond %{HTTP_HOST} !^www\.(nowhere\.com|nothing\.com|samsalive\.org)$ [NC]
RewriteRule .* http://%1/ [L,R=301]

The %1 symbol replaces the first argument that matches (within the OR'd block delimited by parenthesis), so that can be used to generate the correct URL to redirect them.

killes@www.drop.org’s picture

Status: Reviewed & tested by the community » Fixed

applied JonBob's patch. Please continue the .htaccess discussion elsewhere. this is too specific to put into the general .htaccess file.

markus_petrux’s picture

@rubenk, if you open a forum post about this, please bump this issue with the link.

@killes: Pardon. It's just for anyone curious to see if that tip worked or how it evolves.

Thanks

rubenk’s picture

I've figured out how to use redirections for a multi site config. As per the above comment...BUMP.
Go here for more info http://drupal.org/node/58597 . I had to tweak the code given by Markus slightly.

rubenk’s picture

Category: bug » task
Priority: Normal » Minor

I've figured out how to use redirections for a multi site config. As per the above comment...BUMP.
Go here for more info http://drupal.org/node/58597 . I had to tweak the code given by Markus slightly.

Anonymous’s picture

Status: Fixed » Closed (fixed)