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.
Comment | File | Size | Author |
---|---|---|---|
#82 | htaccess_6.patch | 1.06 KB | JonBob |
#76 | 56634-b.diff.txt | 1.97 KB | beginner |
#73 | tolerant.base.url.patch | 8.31 KB | Steven |
#66 | 56634.htaccess.diff.txt | 1.07 KB | beginner |
#61 | 56634.diff_1.txt | 2.92 KB | beginner |
Comments
Comment #1
PakWaan CreditAttribution: PakWaan commentedFIXED in 4.7 RC1.
Comment #2
PakWaan CreditAttribution: PakWaan commentedFIXED in 4.7 RC1.
Comment #3
killes@www.drop.org CreditAttribution: killes@www.drop.org commented.
Comment #4
PakWaan CreditAttribution: PakWaan commentedWell, 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.
Comment #5
PakWaan CreditAttribution: PakWaan commentedAdditionally, 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.
Comment #6
kus CreditAttribution: kus commentedproblem confirmed with ie/firefox 4.7 rc1
Comment #7
kus CreditAttribution: kus commented...and it only occurs, if caching is enabled. without caching it works fine.
Comment #8
webchickwell then it's not fixed, is it? ;) let's get that out of the title
Comment #9
BryanSD CreditAttribution: BryanSD commentedKus...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.
Comment #10
PakWaan CreditAttribution: PakWaan commentedIf 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.
Comment #11
BryanSD CreditAttribution: BryanSD commentedMy 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
Comment #12
PakWaan CreditAttribution: PakWaan commentedTo 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.
Comment #13
kus CreditAttribution: kus commentedBryanSD....i was talking about drupal caching.
Comment #14
kus CreditAttribution: kus commenteddrual 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
Comment #15
PakWaan CreditAttribution: PakWaan commentedWell, 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.
Comment #16
chx CreditAttribution: chx commentedmy two cents are on browser caching.
Comment #17
PakWaan CreditAttribution: PakWaan commentedAs I noted above, completely clearing the browser cache doesn't fix it. And it never did it with 4.6.
Comment #18
BryanSD CreditAttribution: BryanSD commentedI'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.
Comment #19
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedAre there any errors logged in watchdog?
Comment #20
dwwi'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....
Comment #21
BryanSD CreditAttribution: BryanSD commentedMost 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.
Comment #22
BryanSD CreditAttribution: BryanSD commentedOk..that sounded stupid. Once the files are deleted, I'll repopulate the directories with Drupal 4.7 RC1.
Comment #23
joelstein CreditAttribution: joelstein commentedI 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.
Comment #24
BryanSD CreditAttribution: BryanSD commentedThis 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
Comment #25
BryanSD CreditAttribution: BryanSD commentedSorry...you can tell it's a busy day. I meant to say the problem DID RETURN after restarting the browser.
Comment #26
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedcan you test if the problem persists if you clean out the sessions table?
Comment #27
BryanSD CreditAttribution: BryanSD commentedClearing 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.
Comment #28
markus_petrux CreditAttribution: markus_petrux commentedhmm... 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.But then again, these lines take effect depending on how your PHP is installed. So you may wish to check the values with phpinfo().
Comment #29
BryanSD CreditAttribution: BryanSD commentedVerified 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
Comment #30
drummCan you reproduce this on Drupal 4.6.6?
Comment #31
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedBryan, 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.
Comment #32
BryanSD CreditAttribution: BryanSD commentedI 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
Comment #33
moshe weitzman CreditAttribution: moshe weitzman commentedin 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
Comment #34
BryanSD CreditAttribution: BryanSD commentedSo 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.
Comment #35
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedSince 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).
Comment #36
chx CreditAttribution: chx commentedPlease 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.
Comment #37
chx CreditAttribution: chx commentedThis 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.
Comment #38
killes@www.drop.org CreditAttribution: killes@www.drop.org commenteddowngrding since it is apparently browser/server specific
Comment #39
BryanSD CreditAttribution: BryanSD commentedThe 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
Comment #40
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI 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?
Comment #41
dekova CreditAttribution: dekova commentedI'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.
Comment #42
moshe weitzman CreditAttribution: moshe weitzman commentedjnarmandin - 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.
Comment #43
chx CreditAttribution: chx commentedWe are trying to figure out what's going. Please try replacing session.inc with http://cvs.drupal.org/viewcvs/*checkout*/drupal/drupal/includes/session.... .
Comment #44
chx CreditAttribution: chx commentedLet's see a link
Comment #45
moshe weitzman CreditAttribution: moshe weitzman commentedthe 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.
Comment #46
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedProbably 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.
Comment #47
seanrhas 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.
Comment #48
dekova CreditAttribution: dekova commentedA 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.
Comment #49
beginner CreditAttribution: beginner commentedDoes 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?
Comment #50
beginner CreditAttribution: beginner commentedPlease, 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...
Comment #51
beginner CreditAttribution: beginner commented4-7-0-rc2 has not been added to the '4.7 critical issues' link in the 'Contributor links' menu.
Comment #52
beginner CreditAttribution: beginner commentedComment #53
chx CreditAttribution: chx commentedI doubt this issue is critical but let's hear back from BrianSD. The contributor links have been updated.
Comment #54
markus_petrux CreditAttribution: markus_petrux commentedhmm... 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:
On the other hand, if one prefers without www., then add the following:
Comment #55
beginner CreditAttribution: beginner commentedThis 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.
Comment #56
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedThe 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.
Comment #57
beginner CreditAttribution: beginner commentedpatch 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?
Comment #58
beginner CreditAttribution: beginner commentedComment #59
beginner CreditAttribution: beginner commentedslight adjustment.
Comment #60
markus_petrux CreditAttribution: markus_petrux commentedRegardless 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:
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).
Comment #61
beginner CreditAttribution: beginner commentedYou mean this way?
Comment #62
markus_petrux CreditAttribution: markus_petrux commentedMore 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.
Comment #63
beginner CreditAttribution: beginner commentedI'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?)
Comment #64
NaX CreditAttribution: NaX commentedIt was my understanding that you need to setup a site settings file per a domain name pointing to that site.
You would need have
and
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
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.
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.
Comment #65
markus_petrux CreditAttribution: markus_petrux commentedUsing 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? :-/
Comment #66
beginner CreditAttribution: beginner commentedHere'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.
Comment #67
beginner CreditAttribution: beginner commentedBy 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.
Comment #68
moshe weitzman CreditAttribution: moshe weitzman commented+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.
Comment #69
dekova CreditAttribution: dekova commentedPatch 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.
Comment #70
beginner CreditAttribution: beginner commentedI 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
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.
Comment #71
bermin CreditAttribution: bermin commentedI 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
Comment #72
PakWaan CreditAttribution: PakWaan commentedThis 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!!
Comment #73
Steven CreditAttribution: Steven commentedKilles, 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.
Comment #74
moshe weitzman CreditAttribution: moshe weitzman commentednice! 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."
Comment #75
markus_petrux CreditAttribution: markus_petrux commentedRegarding 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 :-)
Comment #76
beginner CreditAttribution: beginner commentedCan 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.
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).
Comment #77
chx CreditAttribution: chx commentedbeginner, 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.
Comment #78
beginner CreditAttribution: beginner commentedOoops! 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 ;-) )
Comment #79
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedThis has been commited with Moshe's suggestions implemented.
Comment #80
Steven CreditAttribution: Steven commentedMoshe: 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.
Comment #81
PakWaan CreditAttribution: PakWaan commentedOne 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?
Comment #82
JonBob CreditAttribution: JonBob commentedAgreed with PakWaan.
Comment #83
rstamm CreditAttribution: rstamm commentedthe variable $conf in settings.php is ignored
http://drupal.org/node/58418
Comment #84
webchickJonBob's patch is a no-brainer, RTBC.
Comment #85
rubenk CreditAttribution: rubenk commentedSimple 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?
Comment #86
markus_petrux CreditAttribution: markus_petrux commentedWhen 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:
Various RewriteCond do a boolean AND.
or:
or maybe simply:
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).
Comment #87
rubenk CreditAttribution: rubenk commentedClose. 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.
Comment #88
markus_petrux CreditAttribution: markus_petrux commentedhmm... if I understand you correctly, you wish them to use the www. prefix?
If so, I think you could try something like this:
If you don't wish them to use the www. prefix:
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.
Comment #89
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedapplied JonBob's patch. Please continue the .htaccess discussion elsewhere. this is too specific to put into the general .htaccess file.
Comment #90
markus_petrux CreditAttribution: markus_petrux commented@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
Comment #91
rubenk CreditAttribution: rubenk commentedI'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.
Comment #92
rubenk CreditAttribution: rubenk commentedI'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.
Comment #93
(not verified) CreditAttribution: commented