Development
Threads by month
- ----- 2026 -----
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- 9354 discussions
Project: Drupal
Version: cvs
Component: theme system
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: tangent
Updated by: tangent
Status: patch
Attachment: http://drupal.org/files/issues/logo_title.patch (1.94 KB)
Using the XTemplate engine the logo title is not localizable.
Consequently, all default themes use a title and alt string of "Home"
which is language specific.
The attached patch solves the problem by adding a site_name variable to
the logo block and replacing the title and alt strings with {site_name}.
This patch only updates the "bluemarine" and "pushbutton" themes.
tangent
--
View: http://drupal.org/node/17446
Edit: http://drupal.org/project/comments/add/17446
2
1
[drupal-devel] [bug] Can't upload picture/avatar without PHP GD extension enabled
by mathias 17 Feb '05
by mathias 17 Feb '05
17 Feb '05
Project: Drupal
Version: cvs
Component: user.module
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: mathias
Updated by: mathias
Status: patch
Attachment: http://drupal.org/files/issues/image_get_toolkit_load_gd_on_existance.patch (3.74 KB)
When validating a user's picture, we currently send the file to
image_scale() to automatically resize the image. This works great, but
also assumes that an image toolkit is loaded to perform this action.
If no toolkit is loaded, the user will always receive an error message
even if the image is within specs, causing the upload to fail.
This patch make image_get_toolkit() return the current toolkit only if
it's enabled, that way we can use the elegant image_scale approach if a
toolkit is present, or resort to the old way of checking width and
height for a user's picture if need be.
mathias
--
View: http://drupal.org/node/17477
Edit: http://drupal.org/project/comments/add/17477
2
1
[drupal-devel] [feature] Option to disable printer friendly version for book module
by stefan nagtegaal 17 Feb '05
by stefan nagtegaal 17 Feb '05
17 Feb '05
Project: Drupal
Version: cvs
Component: book.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: kbahey
Updated by: stefan nagtegaal
Status: patch
Imo this is a theme feature, so it should be handled in there..
A link management system should be the best to handle such things, but
is - unfortunatly - quite hard to inplement...
stefan nagtegaal
Previous comments:
------------------------------------------------------------------------
November 20, 2004 - 07:30 : kbahey
Attachment: http://drupal.org/files/issues/book_17.patch (2.18 KB)
I wanted an option for the book module to NOT display a
'printer-friendly version' link for every node.
So, I implemented an option for the book module to allow this to be
turned off.
Using this option:
- Go to the /admin/node/book
- Uncheck the box that say 'show printer friendly links for books' if
you want
- Click 'Save settings'
There will be no printer friendly links after you do this.
Please consider applying this patch to CVS.
------------------------------------------------------------------------
November 21, 2004 - 18:01 : kbahey
Setting status to patch, so that it is discussed on the mailing list.
------------------------------------------------------------------------
November 26, 2004 - 00:36 : kbahey
Attachment: http://drupal.org/files/issues/book_18.patch (2.3 KB)
I have remade this patch to match what is in the current CVS version.
The previous patch had conflicts with the latest CVS version.
Will this be included in the base any time soon?
------------------------------------------------------------------------
November 26, 2004 - 01:07 : Bèr Kessels
options, options, options.
Alltough an option is an easy method to add fetaures, while not
breaking backwards compatibility, it is generally very bad for
useability.
I am therefore a -1 for this patch.
kbahey,
Eventhough the functionality is very nice, I would rather see you
either make thisa single site wide setting (in books settings).
Or -even better IMO- make the link dis(appear) through a theme
function.
Or -and thats the best option IMO- help the folks who are working on a
better $links (the links under each node) and introduce a general API
and theme system to show, hide and markup those links on nodes.
------------------------------------------------------------------------
November 26, 2004 - 22:55 : Anonymous
"I would rather see you either make thisa single site wide setting (in
books settings).
"
That is what it already does. The setting is global in books settings,
and not in every individual book.
It just so happens, for a reason unknown to me, that book's setting
page is under administer -> content -> books, and not under administer
-> settings -> book like other modules.
"Or -even better IMO- make the link dis(appear) through a theme
function.
Or -and thats the best option IMO- help the folks who are working on a
better $links (the links under each node) and introduce a general API
and theme system to show, hide and markup those links on nodes.
"
Those sound like a better option for sure.
If the option is in admin -> themes -> configure, under the "Toggle
display" part.
I am not familiar with that code at this point. Will do some digging to
see what can be done.
------------------------------------------------------------------------
February 17, 2005 - 15:58 : kbahey
One of the objections to this patch is that it introduces one more
option.
If I resubmit this patch without an option, does it have a change to be
accepted?
I will rely on the new $conf variable being able to override
variable_get(), so there is no option screen needed.
How about that?
--
View: http://drupal.org/node/13211
Edit: http://drupal.org/project/comments/add/13211
1
0
[drupal-devel] [feature] Option to disable printer friendly version for book module
by kbahey 17 Feb '05
by kbahey 17 Feb '05
17 Feb '05
Project: Drupal
Version: cvs
Component: book.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: kbahey
Updated by: kbahey
Status: patch
One of the objections to this patch is that it introduces one more
option.
If I resubmit this patch without an option, does it have a change to be
accepted?
I will rely on the new $conf variable being able to override
variable_get(), so there is no option screen needed.
How about that?
kbahey
Previous comments:
------------------------------------------------------------------------
November 20, 2004 - 01:30 : kbahey
Attachment: http://drupal.org/files/issues/book_17.patch (2.18 KB)
I wanted an option for the book module to NOT display a
'printer-friendly version' link for every node.
So, I implemented an option for the book module to allow this to be
turned off.
Using this option:
- Go to the /admin/node/book
- Uncheck the box that say 'show printer friendly links for books' if
you want
- Click 'Save settings'
There will be no printer friendly links after you do this.
Please consider applying this patch to CVS.
------------------------------------------------------------------------
November 21, 2004 - 12:01 : kbahey
Setting status to patch, so that it is discussed on the mailing list.
------------------------------------------------------------------------
November 25, 2004 - 18:36 : kbahey
Attachment: http://drupal.org/files/issues/book_18.patch (2.3 KB)
I have remade this patch to match what is in the current CVS version.
The previous patch had conflicts with the latest CVS version.
Will this be included in the base any time soon?
------------------------------------------------------------------------
November 25, 2004 - 19:07 : Bèr Kessels
options, options, options.
Alltough an option is an easy method to add fetaures, while not
breaking backwards compatibility, it is generally very bad for
useability.
I am therefore a -1 for this patch.
kbahey,
Eventhough the functionality is very nice, I would rather see you
either make thisa single site wide setting (in books settings).
Or -even better IMO- make the link dis(appear) through a theme
function.
Or -and thats the best option IMO- help the folks who are working on a
better $links (the links under each node) and introduce a general API
and theme system to show, hide and markup those links on nodes.
------------------------------------------------------------------------
November 26, 2004 - 16:55 : Anonymous
"I would rather see you either make thisa single site wide setting (in
books settings).
"
That is what it already does. The setting is global in books settings,
and not in every individual book.
It just so happens, for a reason unknown to me, that book's setting
page is under administer -> content -> books, and not under administer
-> settings -> book like other modules.
"Or -even better IMO- make the link dis(appear) through a theme
function.
Or -and thats the best option IMO- help the folks who are working on a
better $links (the links under each node) and introduce a general API
and theme system to show, hide and markup those links on nodes.
"
Those sound like a better option for sure.
If the option is in admin -> themes -> configure, under the "Toggle
display" part.
I am not familiar with that code at this point. Will do some digging to
see what can be done.
--
View: http://drupal.org/node/13211
Edit: http://drupal.org/project/comments/add/13211
1
0
Project: Drupal
Version: cvs
Component: base system
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: kbahey
Updated by: kbahey
Status: patch
This patch is badly needed. The lack of a leading / in many paths is
causing lots of problems.
kbahey
Previous comments:
------------------------------------------------------------------------
November 18, 2004 - 22:29 : kbahey
Looking at my site's logs, there seem to be several problems that are
caused by Drupal's use of relative path names.
If Drupal causes all the site's urls to be absolute, then none of this
would be an issue.
A. Search Engine Crawlers
Getting lots of 404s on things like: linux/index.html/robots.txt
Where 'linux' is an alias to a taxonomy, and 'index.html' is an alias
to a node within that taxonomy.
Another example, is recursing unnecessarily. I see 404s on things like:
/linux/index.html/linux/index.html
Where 'linux' is a path alias for a taxonomy term, and 'index.html' is
an alias to the main node within it.
This does not seem to happen when Google crawls my sites, but Yahoo's
Slurp suffers from this problem, and keeps recursing. MSNBot also
suffers from this.
Another crawler/harvester called Blinkx/DFS-Fetch keeps adding the .css
file to the relative path, getting a 404 on things like:
/linux/themes/xtemplate/pushbutton/logo.gif
And Fast Search Engine also attempts to access:
/linux/contact/tracker/tracker/user/password
The same goes for grub.org, another crawler.
B. Google Cache / Archive Way Back Machine
Pages in Google cache and archive.org Way Back Machine suffer form a
similar problem: the .css files cannot be found, and hence rendering of
the pages is not correct.
Examples:
Compare this: http://www.drupal.org/node/4647
To this:
http://www.google.ca/search?q=cache:www.drupal.org/node/view/4647
Notice the following:
How there is no formatting at all, because of the lack of a .css file
The httpd log on Drupal will show errors for:
linux/themes/pushbutton/style.css and linux/misc/drupal.css
Also see:
http://web.archive.org/web/20031016184902/http://www.drupal.org/
C. Proxy Caches:
When someone is browsing my site from behind a proxy cache, the web
site is hit with a rapid succession of requests, and many of it is just
for bogus pages.
Examples:
2004/11/17 - 17:47 404 error: linux/user/1 not found.
2004/11/17 - 17:47 404 error: linux/feedback not found.
2004/11/17 - 17:47 404 error: linux/tracker not found.
2004/11/17 - 17:47 404 error: linux/sitemap not found.
2004/11/17 - 17:47 404 error: linux/search not found.
2004/11/17 - 17:47 404 error: linux/misc not found.
2004/11/17 - 17:47 404 error: linux/programming not found.
2004/11/17 - 17:47 404 error: linux/programming not found.
2004/11/17 - 17:47 404 error: linux/linux not found.
2004/11/17 - 17:47 404 error: linux/technology not found.
2004/11/17 - 17:47 404 error: linux/writings not found.
2004/11/17 - 17:47 404 error: linux/family not found.
And also:
2004/11/17 - 07:23 404 error: history/user/1 not found.
2004/11/17 - 07:23 404 error: history/tracker not found.
2004/11/17 - 07:23 404 error: history/feedback not found.
2004/11/17 - 07:23 404 error: history/sitemap not found.
2004/11/17 - 07:23 404 error: history/search not found.
2004/11/17 - 07:23 404 error: history/misc not found.
2004/11/17 - 07:23 404 error: history/technology not found.
2004/11/17 - 07:23 404 error: history/science not found.
2004/11/17 - 07:22 404 error: history/history not found.
2004/11/17 - 07:22 404 error: history/writings not found.
2004/11/17 - 07:22 404 error: history/family not found.
As you can tell, history and linux are aliases to taxonomy terms, and
so is misc, technology, writings, family, ...etc. The user agent is
appending the taxonomy term alias to the url and forming a new URL.
D. Regular Browsing:
There is even at least one extreme case where the following URL was
accessed (the result was 404 of course)
/book/view/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/themes/xtemplate/pushbutton/logo.gif
It seems it was a normal user, because the user agent is: "Mozilla/4.0
(compatible; MSIE 5.5; Windows 98; Win 9x 4.90)"
Proposed Solution:
As a proposed solution, all URLs in Drupal can be made into absolute
path names. This can be done by the following:
The variable $base_url in the conf.php file is broken down into two
components:
$base_host (the 'http://whatever-host.example.com' part WITHOUT the
trailing slash)
$base_path (the '/path-to-drupal' part, WITH the leading slash. If this
is the DocumentRoot, then it is just a '/' character)
$base_url is now $base_host concatenated with $base_path
A simple filter can be written to preceed every href="path" with the
$base_path variable, so it becomes "/path"
This option can be turned on and off for a site. The default is to have
it off so current behavior is maintained.
A similar scheme applies for style sheets as well.
So, did I miss something obvious? Am I seriously off the mark?
Your thoughts!
------------------------------------------------------------------------
November 19, 2004 - 23:10 : chrisada
I am getting similar 404 errors, mainly from rss feed link that looks
like /blog/blog/feed and many manual links that are relative to drupal
root.
It was not a problem before Drupal 4.5, so I think there might not be a
need to change all URIs to absolute. I can't see where the problem is
coming from though.
------------------------------------------------------------------------
November 19, 2004 - 23:35 : kbahey
I am pretty sure that these problems were happening for at least the
past 10 months (ever since I moved to Drupal in January 2004).
The main issue here is that crawlers and other user agents get confused
by the relative path names.
Using absolute paths will definitely solve this. However, is this the
only solution?
I am looking for a discussion of this.
------------------------------------------------------------------------
November 20, 2004 - 04:55 : Goba
No absolute paths please. Having the path start with '/' solves all the
mentioned problems, and is not absolute, it is relative to the domain.
Sadly some crawlers and even the Google Cache does not obey to the base
href. I have reported this cache problem in April to Google, and they
promised they will keep it in mind... Hehe...
What we need is to have the printed relative path values relative to
the domain name, and not relative to the Drupal installation path.
Note that this issue will appear on the drupal devel mailing list if
someone finally provides a patch we can talk about :)
------------------------------------------------------------------------
November 20, 2004 - 05:19 : Dries
Goba is right. We need paths relative to the domain name to fix this
'problem'.
------------------------------------------------------------------------
November 20, 2004 - 15:19 : kbahey
Sorry for not making my self clear.
When I said absolute, I meant that they start with just a /. I did NOT
mean that they start with http://host.example.com. That would be a very
bad idea.
In any case, what do people think about the proposed solution (breaking
down $base_url into two parts?)
Also, does this address the style sheets as well, or more is needed?
------------------------------------------------------------------------
November 21, 2004 - 11:24 : chx
Attachment: http://drupal.org/files/issues/common_inc_patch.txt (471 bytes)
I have implemented what Goba suggested.
------------------------------------------------------------------------
November 21, 2004 - 11:43 : chx
Attachment: http://drupal.org/files/issues/common_inc_patch_0.txt (825 bytes)
Maybe this one is faster?
------------------------------------------------------------------------
November 21, 2004 - 12:34 : kbahey
Man! You are fast!
I tried the second version. It works fine for things that are not
inside the node body, I mean they have a / in front of them, as we
want it to be.
Two comments/issues:
- If there is a URL that is already "/" representing the home page, it
gets set to "//". Perhaps it should check for that case?
- URLs in nodes that do not start with / do not get changed to have a /
prepended to them. Do we need a filter for this?
- Do we need to do something for the style sheets in the page header? I
mean the "misc/drupal.css" and "themes/themename/style.css"?
Thanks
------------------------------------------------------------------------
November 21, 2004 - 19:28 : kbahey
Hi chx
Here is a fix for the case where you have a url that is just "/".
In your patch, instead of:
<?php
$base = $parts['path'] . '/' ;
?>
Replace that by:
<?php
$base = ( $path == '/' ? $base : $parts['path'] . '/' );
?>
------------------------------------------------------------------------
November 27, 2004 - 23:08 : kbahey
Did this patch make it into CVS yet?
If there are any objections to it, can someone please explain what they
are?
Thanks
------------------------------------------------------------------------
November 28, 2004 - 04:33 : Dries
Shouldn't your changes be included in the patch?
Also, it's better to cache $base rather than $parts.
Lastly, it this patch makes it to HEAD, we should probably remove some
'base url' cruft from the themes.
------------------------------------------------------------------------
November 28, 2004 - 13:54 : kbahey
Attachment: http://drupal.org/files/issues/x.diff (1 KB)
Here is the patch including my fix.
I am asking chx to comment on caching $base instead of $parts.
Will this make it faster?
------------------------------------------------------------------------
November 28, 2004 - 14:26 : chx
Hm. $base = ( $path == '/' ? $base : $parts['path'] . '/' ); this
depends on path which is a parameter. Thus I fail to see how could we
cache $base. I'd correct this code however $base = ( $path == '/' ? ''
: $parts['path'] . '/' ); 'cos I think $base is not defined before, but
this is not a problem, PHP will be happy to replace NULL with NULL...
Maybe instead of all parts, only $parts['path'] is enough to be cached,
yes, but the performance and memory usage difference -- I guess -- would
not be noticable...
------------------------------------------------------------------------
November 28, 2004 - 18:06 : kbahey
Attachment: http://drupal.org/files/issues/common-inc-patch.txt (1 KB)
OK.
I put in chx suggested change.
This patch can go in CVS then, to rid us of the problems with paths not
beginning with slash.
This is not an ultimate solution still. We need to address the problem
with .css files. Although the header contains a:
<base href="http://example.com" />
it does not seem that major search engines and archiving sites obey it
anyway.
------------------------------------------------------------------------
December 2, 2004 - 15:31 : Dries
Your coding style needs work. Also, I'm not going to commit this unless
the themes get fixed up: we'd end up with invalid URLs all over the
place. Lastly, I wonder how portable the themes will be when Drupal is
run from within a subdirectory.
------------------------------------------------------------------------
December 2, 2004 - 16:15 : chx
Attachment: http://drupal.org/files/issues/common_inc_patch_1.txt (849 bytes)
Well, my patch worked from a subdirectory very well, as fact, I have not
tested it from the root dir. And I think that it adheres to coding
standards. So I resubmit it with the root path fix. However, my Drupal
work is focused on i18n these days, and I was never into themeing so it
won't be me who fixes those.
------------------------------------------------------------------------
December 2, 2004 - 17:07 : kbahey
I have tested the previous patch (including my fix) with drupal
installed in the DocumentRoot of the server.
So, in effect, it is tested with both Drupal in / and Drupal in a
subdirectory.
This change fixes the problem for the crawlers and other browsers from
getting confused.
While it is true that there is no fix for the .css files in the HTML
head section yet, this fix deals with a major part of the problem, and
rids us of a major pain. Check your web server's logs some time to see
what I mean.
Someone who is familiar with the themes can contribute a patch later.
This patch and the future fix for themes are not mutually exclusive, so
let it go in CVS.
------------------------------------------------------------------------
December 9, 2004 - 10:31 : Goba
Please commit this into Drupal core, this fix is badly needed.
------------------------------------------------------------------------
January 17, 2005 - 08:00 : chx
Attachment: http://drupal.org/files/issues/base_url_kill.patch (4.34 KB)
Well as noone have stepped in to fix this problem, I have tried to fix
the themes also. themes.inc , xtemplate.engine and the bluemarine
template is patched besides common.inc.
Of course, more templates could follow, but first I'd like to see your
opinions.
------------------------------------------------------------------------
January 17, 2005 - 08:09 : Goba
I don't think that removing <base> from the themes is a good idea, using
$parts['path'] should be encouraged though before the files, which would
fix the google cache problem, and would still keep the HTML size low. It
would also help those, who save the file to find the originating site
easier, since clicking on a non-pagelocal link would lead to the online
version.
------------------------------------------------------------------------
January 17, 2005 - 11:03 : Steven
Definitely -1 on removing the <base> tag or using absolute or
root-relative URLs. This tag has been around for ages, and it is the
only way to make clean URLs work without bloating in the code. FYI,
"base" is (first?) mentioned in Berners-Lee's HTML 1.0 draft [1].
That's June 1993.
As the amount of clean URL-using sites grows, the crawlers will have to
be updated. Perhaps we could prevent crawlers from going too insane by
404ing for URLs with more than say 10 components? That would prevent
the really crappy ones from hammering your site.
I'm all for making the <base> tag easier to handle for the user (say,
by including a filter to allow simple anchor links to work as most
people expect them to), but we should keep Drupal-generated URLs clean
and completely relative.
[1] http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
------------------------------------------------------------------------
January 17, 2005 - 11:57 : kbahey
The problem with css is this: The @import argument does not start with a
/.
This is simple to fix.
We keep the "base" as it is today, but add the new variable: $base
before it.
So for a site where Drupal is installed in the DocumentRoot, all that
will change is that /misc/drupal.css and /themes/themename/style.css
will be preceded by a slash. For sites that use another path, that path
will be prepended to the css file name.
How about that?
------------------------------------------------------------------------
January 17, 2005 - 12:38 : Steven
What exactly is the problem with the @import? As far as I know:
- url() in stylesheets is interpreted relative to the base of the
stylesheet, not the source document.
- However, if the styles are inside an HTML document, through a style
tag or style attribute, then the stylesheet's location is the same as
the HTML document.
- Thus, the stylesheet's base is the same as the base of the HTML
document (which can be altered through the <base> tag).
I just don't see why it is necessary. As far as I know, the only
browser that has had problems resolving CSS urls properly was Netscape
4, which does not support @import at all, and which Drupal does not
support either, because of its CSS usage.
------------------------------------------------------------------------
January 17, 2005 - 13:35 : kbahey
The problem for stylesheets is as follows. I think it mainly affect
crawlers and Google's cache.
Say you have an installtion of Drupal in DocumentRoot. You then use url
aliases, and put slashes in them.
For example, you use news/general/2004-12-15.html for a node.
That node still has misc/drupal.css and themes/pushbutton/style.css in
the head section if the document. Crawlers get fooled by that and try
to look for /news/general/misc/drupal.css and
/news/general/themes/pushbutton/style.css, which don't exist.
So, just prepending the new $base variable (in chx's patch) before the
stylesheet @import argument would fix this issue. Assuming you are in
DocumentRoot, then /misc and /themes would be used instead of just misc
and themes.
It would still be compliant with standards, be relative to the web
site, and no ambiguous to anyone, be they crawler or browser.
I hope it is clearer now.
I think chx can change the patch to use the $base instead of $base_url
everywhere, so as to avoid the host/domain name in the urls.
------------------------------------------------------------------------
January 17, 2005 - 16:36 : Steven
But typical crawlers don't even pay attention to stylesheets, hence it
wouldn't have much use for them. I just don't see why we should adjust
to rare cases of buggy software. Reading out a base URL from an HTML
document is dead easy, and on top of that it doesn't add more
complexity as without the base tag, the document's URL is already an
implicit base which has to be parsed anyway.
I did not like it when we altered the <link> tag to accomodate buggy
RSS readers and I certainly don't like it now, as this is even rarer.
In both cases, it is not Drupal which is at fault.
------------------------------------------------------------------------
January 17, 2005 - 16:48 : kbahey
Steven
While I agree with most of what you said, the 404s show up in the logs
enough to be a bother.
Perhaps the original design of Drupal did not forsee that people will
use url aliases to mimic directory/file hierarchies. Whether this was
intended or not, it is the way many use Drupal today.
It does not matter where the bug is (Drupal or the external world), as
long as we can stop it ourselves, by adjusting our end of it.
The fix is simple enough and does not break standards (if implemented
as described with a leading / before the css).
------------------------------------------------------------------------
January 17, 2005 - 16:54 : Steven
It does not break standards, but it does bloat the code in an ugly way.
Why not send an e-mail to the owners of the crawlers and tell them to
implement a standard that is nearly 10 years old [2] (RFC 1808)?
Note that Google Cache now seems to correctly interpret base URLs [3]
and even adds a <base> tag of its own.
By the way, this problem has nothing to do with people using URL
aliases or not, as for a browser the regular nested paths that Drupal
uses (e.g. "node/1" is no different from aliases mimicking files
"foo/bar.html").
[2] http://www.faqs.org/rfcs/rfc1808.html
[3]
http://www.google.be/search?q=cache%3Awww.drupal.org&sourceid=mozilla-searc…
------------------------------------------------------------------------
January 17, 2005 - 17:34 : Goba
Steven, part of the problem is that Google cache does add a base href
even if there is a base href in the document. Eg adds a <BASE
HREF="http://drupal.org/node/13733"> on the plone comparision page
cached. Now that since HTML does not allow more than one base tag [4]
to be present, it is up to the browsers, to use the first or the last
base value, or any of the base values on the page for that matter as
the used base. So even pages displayed from the google cache will be
buggy if a full relative path to the domain root is not specified, due
to this problem.
[4]
http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html#head.content
------------------------------------------------------------------------
January 18, 2005 - 02:14 : chx
Attachment: http://drupal.org/files/issues/base_url_kill_0.patch (4.75 KB)
This one does not use the whole base_url only the path part of it. HTML
bloat is kept at minimal.
------------------------------------------------------------------------
February 1, 2005 - 18:33 : clairem
Please please can this be done?
It's a good idea in itself, but if using fully-qualified paths means we
can get rid of the BASE HREF, then page anchors will work without having
the overhead of a filter. That's be a huge bonus for those creating
larger nodes, or who just want to be able to put a "skip navigation"
link in their theme without having to abandon Xtemplate or PHPtemplate
------------------------------------------------------------------------
February 1, 2005 - 18:37 : Goba
Well, speaking of skip navigation links, phptemplate and xtemplate
should expose the REQUEST_URI to the templates, so when a link to an
anchor on the same page is needed, the link can be formatted with the
complete request URI in mind.
------------------------------------------------------------------------
February 2, 2005 - 18:40 : clairem
"hptemplate and xtemplate should expose the REQUEST_URI to the templates
"
Should, but don't :(
If BASE HREF isn't removed, surely it wouldn't be a big job to
implement this tweak?
--
View: http://drupal.org/node/13148
Edit: http://drupal.org/project/comments/add/13148
1
0
In Drupal, how are patches to branches handled?
For example, there is a DRUPAL-4-5 tag, which was done when the
repository was branched off for Drupal 4.5.0. Later, there was a
DRUPAL-4-5-1, ...etc.
Now, if someone finds a critical bug, that needs to be fixed in 4.5.1
for example, does it go to the daily build of 4.5.1? In other words,
will the tar ball for 4.5.1 before the fix (e.g. Feb 1, 2005) differ
from the 4.5.1 after the fix (e.g. Feb 2, 2005)?
If we are doing this in Drupal, then there is a serious issue: the
same release number can contain different code, which creates support
issues: a person having the 4.5.1 from Feb 1 will say they have a
problem, and another who has 4.5.1 from Feb 2 will say there is no
problem.
The obvious solution is that builds have to get a new number (e.g.
4.5.2) whenever fixes are made to a branch.
Are we sure we are not falling into this trap?
Of course, this does not apply to CVS HEAD, since by definition it is
a dynamic moving target.
8
19
Hi all,
I just want to point out this bug [1][2], that could break some upload
function around Drupal. I have no time at the moment to provide a patch.
I think this has to be fixed before 4.6.
Cheers,
flevour
[1] http://bugs.php.net/bug.php?id=31891
[2] http://bugs.php.net/bug.php?id=31757
1
0
Project: Drupal
Version: cvs
Component: system.module
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: Anonymous
Updated by: Anonymous
Status: patch
When accessing the admin...settings page on a subdomain site, I get the
following two errors:
warning: fsockopen(): php_network_getaddresses: getaddrinfo failed:
Name or service not known in
/home/username/public_html/includes/common.inc on line 227.
warning: fsockopen(): unable to connect to sub.domain.com:80 in
/home/username/public_html/includes/common.inc on line 227.
This is a result of a failure to resolve the subdomain at my host. (DNS
is hosted elsewhere from the server.) This could be easily fixed by
adding an "@" before
$request = drupal_http_request($GLOBALS['base_url'] . '/system/test');
in system.module.
I don't have an environment set up to create a patch at the moment, but
the change is very minor.
Anonymous
--
View: http://drupal.org/node/16309
Edit: http://drupal.org/project/comments/add/16309
1
1
Hello drupal-devel,
Lately, I've been working on the Node Relativity module, and I've come
up against some issues that I'm having trouble overcoming. The main
thing this module does is allow parent/child relationships to exist
between nodes. One of the features of this module is the ability to
require that a given type of node not exist unless it is a child of an
appropriate parent node. This works all well and good from within the
module (except for the occasional bug), but when a user goes to the
"create content" page (node/add), they see listed before them every type
of node that they have permission to create. I want to limit this view
and the menu associated with it.
This brings me to my question: How do I override what is displayed on
the node/add page or override the node_access permissions in general for
node types not defined by my module? I know that node.module checks
node_list() and calls node_access('create',$node) on each of the node
types to see if the current user has rights to create it. I suspect
that there's some way that I haven't seen yet that the node is mapped
back to the module that defines it. I would like to restrict this view
even further such that users can create these nodes, but only under the
appropriate circumstances.
Any ideas would be greatly appreciated.
Thanks,
Mark Howell
(javanaut)
6
23
Project: Drupal
Version: cvs
Component: user.module
Category: feature requests
Priority: normal
Assigned to: kbahey
Reported by: marco
Updated by: kbahey
Status: patch
Dries
I think the other patch is more general in that it addresses many of
the php parameters/flags that used to be in .htaccess.
It also has the benefit that these values can be set differently on a
per domain/subdomain basis.
So, unless others have more to say, you can safely ignore my patches
(the ones in this issue), and only commit the other one to HEAD.
Thanks
kbahey
Previous comments:
------------------------------------------------------------------------
September 22, 2003 - 08:37 : marco
"remember me" checkbox in the login box doesn't work; even if the
checkbox is left unchecked the user is NOT forgotten when he quits the
browser. Try logging in w/o "remember me", then quit the browser and
open it again: you should be still logged in.
What happens:
when you login w/o checkbox user.module outputs a cookie with lifetime
= 0 ("until session ends"); but user.module calls session_start() at
the beginning, which outputs a cookie too, with the lifetime specified
in .htaccess; and session_start() outputs this cookie always, so on the
next page the cookie from user_login() will be overwritten.
I run Mozilla 1.4; I can replicate with Drupal 4.0 and Drupal 4.2 on
PHP 4.3.3, and I can replicate this on drupal.org which also runs PHP
4.3.3; OTOH I can't replicate on a site running Drupal 4.2 with PHP
4.2.2, which may mean session_start() changed with PHP 4.3.x; I looked
in the changelog of PHP but couldn't find anything. I didn't have any
report about this before upgrading to PHP 4.3.3, which also seems to
strengthen the hypothesis of a changed behaviour in PHP. Another test I
did also showed that with PHP 4.2.2 no cookie is printed by
session_start() if a session cookie is found, while it is always
printed in PHP 4.3.3; I double checked the configurations and didn't
find anything which may cause this.
If you want to investigate this, I suggest you to use Mozilla and Live
HTTP Headers plugin.
------------------------------------------------------------------------
October 10, 2003 - 19:37 : moshe weitzman
Can anyone confirm this? Also, how to fix?
------------------------------------------------------------------------
October 12, 2003 - 12:45 : axel(a)debian.linuxrulez.ru
I agree it for Mozilla 1.0. On my site running on FreeBSD 4.7,
PHP/4.3.0, Drupal CVS (Oct 3) this function also don't work. Though,
with Galeon 1.2.5 cookie works ok.
On localhost (Debian GNU/Linux 3.0, PHP 4.1.2, same Drupal cvs version)
it works ok with Mozilla & Galeon.
------------------------------------------------------------------------
October 12, 2003 - 13:34 : al
The original bug report is surely due to Drupal needing to unset the
cookie that it originally stored?
To fix this bug, we therefore need a check on the user login/validation
stage which forcibly unsets the cookie if you don't do "remember me".
I suspect Axel's problems with one of his sites and not the other are
due to him blocking a cookie originally and having that site on his
Mozilla's list of sites to ban cookies from, or similar.
Axel - if you are genuinely having issues with remember me not working
at all (and not the fault originally described in this report by Ax)
then please open a different bug report. Please make sure it's a
genuine problem first - i.e. clear your blocked cookies sites list in
Mozilla.
------------------------------------------------------------------------
October 12, 2003 - 18:24 : axel(a)debian.linuxrulez.ru
Well. I don't sure what is a bug, therefore first post the question
about it to forum [1]. Answer to that question point me to this bug
report.
Already several users of my site [2] report me about problem with
"remember me" (I don't know which browsers they use). And there are not
any blocked sites in my Mozilla cookies list - from site I receive only
cookie PHPSESSID that expire time shows "at end of session".
[1] http://drupal.org/node/view/3601
[2] http://debian.linuxrulez.ru
------------------------------------------------------------------------
October 17, 2003 - 15:36 : dmo
Expect "remember me" problems for users of Internet Explorer 6.
Depending on the privacy settings, IE6 may automatically expire all
cookies at the end of the browser session if your site doesn't have a
compact P3P policy. See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/htm…
and http://www.oreillynet.com/pub/a/javascript/2002/10/04/p3p.html for
further details.
------------------------------------------------------------------------
October 17, 2003 - 21:53 : moshe weitzman
since noone can reproduce this, i am marking as 'by design'
------------------------------------------------------------------------
November 25, 2003 - 02:41 : junyoung
This is not a IE6 specific problem. I have seen the same symptom with
IE5.5/6.0, Opera 7.0/7.1, and Konqueror 3.1.x so far. FWIW, my blog
site is running with Drupal 4.2.0 + PHP 4.3.3.
------------------------------------------------------------------------
November 25, 2003 - 09:06 : remco(a)rc6.org
Same problem on http://rc6.org, though the other way around.
No matter what I do, my session will time out eventually. Tested using
Opera 7.x, IE, Mozilla and Epiphany.
------------------------------------------------------------------------
November 25, 2003 - 10:00 : moshe weitzman
reopening this case. i confirm the behavior that marco describes using
rc6.org and drupal.org.
i find it easiest to just turn cookie prompting on in order to watch
what is happenning. what i am seeing, like marco described, is that our
'permanent cookie' which is supposed to last for a year is being
overwritten in the next request with a standard session cookie that
expires in the time frame specified in .htaccess. for drupal.org,
standard sesson cookies last 1 month whereas the permanent cookie lasts
for a year.
i don't know how to fix this from within drupal. the cookie that we lay
down for 'remember me' is working fine. the problem is the later
overwrite which is caused by PHP's session handing, not drupal.
------------------------------------------------------------------------
November 26, 2003 - 07:35 : moshe weitzman
To make matters more complicated, I cannot reproduce this using PHP as
an ISAPI module on IIS
------------------------------------------------------------------------
November 26, 2003 - 14:07 : Dries
Maybe we can set a "remember" bit in the session table and periodically
wipe users who don't have the "remember"-bit set. The wiping part
could be added to sess_gc() ...
------------------------------------------------------------------------
December 3, 2003 - 20:30 : joshk
I have this problem w/musicforamerica.org
The really maddening thing is that I have another install of drupal 4.3
on the same webserver and it works just fine.
If the problem is with drupal's cookie being overwritten by a PHP
session cookie, can this be fixed by giving the cookies different
names? Sounds too simple to be the solution...
------------------------------------------------------------------------
December 12, 2003 - 11:48 : ykoehler
http://ca.php.net/manual/en/function.session-set-cookie-params.php
Even though drupal is sending a cookie, it should always set this PHP
parameter so that the session_start() call will use the same value, or
not send any cookie at all by itself and let session_start() do it
with, again, a call to this function to set the correct parameter.
The reason why you don't get the same on a site basis is probably due
to the different php.ini used for those sites as the default depends on
the installation and not drupal which is probably why only some get the
bug if there's such a thing.
------------------------------------------------------------------------
December 30, 2003 - 15:50 : paul(a)murphymaphia.com
I am having the opposite problem. Even if I check the "remember me" box
my session ends when the browser closes and I'm forced to log in the
next time I return to the site. No cookie is EVER set by my site.
http://www.murphymaphia.com
------------------------------------------------------------------------
January 20, 2004 - 12:31 : mathias
Charles Miller has written a persistent login cookie best practices [3]
i feel is worth reading.
[3]
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practi…
------------------------------------------------------------------------
February 11, 2004 - 13:20 : paul(a)murphymaphia.com
Has any progress been made on this? I have spent a lot of time in the
code and can't manage to track this problem down. If anyone has any
ideas, thoughts, etc to share, post them here so we can get this
solved.
------------------------------------------------------------------------
February 12, 2004 - 00:07 : dmjossel
I have this problem (remember me feature not working) in Drupal 4.3.x on
PHP 4.3.2.
I do NOT have it on Drupal 4.2 on PHP 4.3.2, in exactly the same
environment.
So perhaps sessions have changed in PHP 4.3.x, but this still didn't
break Drupal 4.2, only 4.3.x.
------------------------------------------------------------------------
February 26, 2004 - 08:47 : moshe weitzman
Attachment: http://drupal.org/files/issues/_4drupal (5.3 KB)
Here is a patch which attempts to resolve this problem. I took Josh's
suggestion - just rename the permanent cookie so it get overwritten by
the PHP session cookie. So this patch names our permanent cookie
'remember_me'. The value of this cookie is the current sessionID. This
cookie is checked in sess_read(). It is set just as before, in
user_login().
I refactored sess_read() a bit for cleaner flow. It uses a new helper
function called sess_construct_user().
Feedback welcome. Since not everyone experienced a problem with
remember me, I'm particlarly interested in feedback from those who did.
------------------------------------------------------------------------
March 2, 2004 - 05:43 : dmjossel
No observable effect. Users who click "remember me" are still logged out
after a period of inactivity or a browser restart, as is true in 4.3.2
(but not true in 4.2 on the same machine).
Just out of curiosity I made similar changes in a copy of 4.3.2,
renaming the cookie-- also with no effect.
What *is* odd is that I used to see this problem using Drupal.org
itself. But I seem now to have been logged in for quite awhile (several
days) without having to reauthenticate, despite long periods of
inactivity and browser restarts.
Has some change other than this patch been made to CVS running on the
live site?
------------------------------------------------------------------------
March 2, 2004 - 06:21 : dmjossel
One more follow up: the patch re-enables the "remember me" button on
logon and the preferences for the user.module, but not the "logout"
button in the user info block.
------------------------------------------------------------------------
March 6, 2004 - 11:33 : moshe weitzman
The logout link never left, so naturally this patch does not re-instate
it. By "user-info" block, i'm guessing that you mean the 'Navigation'
block which holds the menu().
Drupal.org issues session cookies for a month so you can remain logged
in for a long time.
Anyone else have feedback on this patch. It is working for me.
------------------------------------------------------------------------
March 6, 2004 - 12:01 : Jeremy(a)kerneltrap.org
Your patch works perfectly for me.
I tested with three browsers (from Linux): Mozilla Firefox, Konquerer,
Internet Explorer (via Wine)
I did the following with each:
1) with latest CVS installation, I log in then restart my browser. I
have to relogin.
2) I applied your patch to my CVS installation.
3) I logged in w/o checking "remember me". I then restart my browser,
and I'm not logged in.
4) I logged in w/ "remember me" checked. I restart my browser, and I'm
still logged in.
5) I logged in w/ "remember me" checked. I click logout, then restart
my browser. I have to login again.
------------------------------------------------------------------------
April 8, 2004 - 20:09 : Brian(a)brianpuccio.net
Using weitzmann's patch works for me. I had no problem when running
4.3.0, 4.3.1, or 4.3.2 on my site, but adding 4.4.0 I had to log in
each time. Applying the patch to my (next to stock, but ever so
slightly modified) install of 4.4.0 fixes the problem and I am
remembered across browser tab closings, browser closings and system
restarts.
Thank you greatly.
------------------------------------------------------------------------
April 11, 2004 - 12:18 : Jeremy(a)kerneltrap.org
Attachment: http://drupal.org/files/issues/session.inc.patch (651 bytes)
I believe there is a small bug in weitzman's patch. I've been running
with it applied on KernelTrap.org for some time, with much positive
feedback from users. However, I noticed that occasionally I become a
phantom surfer -- I'm logged in and accessing pages, but I don't show
up in the "Who's online" block. I suspect the online guests number is
low, too.
After a little digging, I came up with the attached simple patch. I
have yet to confirm if it solves the phantom surfer problem.
Essentially, when we log in with a cookie we also update the sessions
table timestamp.
To use, first apply weitzman's patch (earlier in this thread), then
apply this one.
------------------------------------------------------------------------
April 11, 2004 - 16:28 : Jeremy(a)kerneltrap.org
Attachment: http://drupal.org/files/issues/session.inc_0.patch (584 bytes)
My earlier patch didn't work. It was redundant with sess_write(), and
added nothing new. Hence, it didn't fix the "phantom user" that I've
been experiencing.
Now, however, I believe I fully understand what's going wrong.
Essentially what's happening is a user is being loaded via the
remember_me cookie, but their session id is different. Thus, the
db_query in sess_write() fails to update a user session in the
database. This patch detects that failure and acts accordingly by
creating a new entry.
This patch applies against drupal 4.4 with weitzman's patch [4]
applied.
[4] http://drupal.org/files/issues/_4drupal
------------------------------------------------------------------------
April 15, 2004 - 02:39 : mabster
Still seems to be a bit flakey. I get logged out every once in a while
at work for some reason (during the day). And every time I move from my
work to my home machines (or vice versa) I need to login again.
Does the cookie base itself on my IP address or something? Could it be
that because I'm switching between two different PCs that it can't
remember my session details?
------------------------------------------------------------------------
April 21, 2004 - 21:19 : dmjossel
I've upgraded the site Rampancy.net to Drupal 4.4 and applied Weitzman's
patch. The behavior I'm seeing now I don't completely understand.
Logging in to the site, you can quit the browser and stay logged in.
But after a period of inactivity, somewhere between 30 and 60 minutes,
the session expires and you have to log in again. I don't see this
behavior on drupal.org.
php.ini on the server is set for session cookies to last for 30 days.
Drupal, by default, is supposed to give cookies that last 1 year.
Is there anything else I should be looking at? Apparently some admins
have this problem and others don't.
Server info:
FreeBSD synfibers.com 4.7-RELEASE-p22 FreeBSD 4.7-RELEASE-p22 #29: Tu
i386
Apache/1.3.27 OpenSSL/0.9.7 (Unix) PHP/4.3.4
registered session save handlers are files and user. (local value is
user)
------------------------------------------------------------------------
April 21, 2004 - 22:20 : mabster
Yes, dmjossel's description matches the behaviour on my site
(www.madprops.org)
We're a hosted site, so I'm not exactly sure of the server's details.
I'm fairly certain it's Windows2003. Definitely a Windows flavour,
anyway, which means that this problem (with the patch applied) is not
restricted to Linux.
------------------------------------------------------------------------
April 23, 2004 - 05:26 : dmjossel
Apologies first for using this like a forum...
mabster, upload a file to the server with the phpinfo(); in it (inside
PHP tags of course).
What values does it show for cookie-related functions? For
session_save_handler?
Perhaps there is a common element in server configuration in these two
cases, despite the different operating systems.
------------------------------------------------------------------------
April 23, 2004 - 05:48 : mabster
session.save_handler = files
session.cookie_domain = no value
session.cookie_lifetime = 0
session.cookie_path = /
session.use_cookies = On
session.use_only_cookie = Off
Other info (at least until someone tells me that publishing this info
is dangerous and I remove the file) here [5].
[5] http://www.madprops.org/info.php
------------------------------------------------------------------------
April 23, 2004 - 11:12 : dmjossel
Suggestions... try setting session.use_only_cookies =1 either in
php.ini, or if you don't have access to that, by using ini_set in
drupal's php.conf and see if that has any effect.
Next change Drupal's site configuration for the user module, and toggle
whether you allow users to choose whether or not to be logged out (this
produces the "remember me" cookie if you've installed weitzman's patch)
or choose "users are never logged out".
Neither of these seem to help here, but perhaps they'd help you.
I noticed that until I set my browser to "accept all cookies
automatically" and set session.use_only_cookies =1, I was getting the
PHPSESSID cookie, but not the remember_me cookie.
Now I get them both... but still logged out after 30 minutes of idle
time, no matter what.
------------------------------------------------------------------------
April 23, 2004 - 11:26 : moshe weitzman
those are not the session values that ship with drupal (see .htaccess
file). for example, session_save_handler has to be 'user'. otherwise,
you are not using drupal's session table and your 'remember me' will
fail.
since you are using IIS, you have to set your php.ini with values like
those found in .htaccess. .htaccess files are only respected by Apache
(and even then, not always. depends on your web host).
------------------------------------------------------------------------
April 23, 2004 - 19:39 : mabster
Just out of interest, weitzman: How does drupal.org's 'remember me'
work? I installed a cookie inspector on my machine at work, and didn't
see any 'remember me' values in drupal.org's cookie. Does it use a
different system?
I will see what our host can do about changing the php.ini values.
Since there are many sites hosted on that one box, it'll be a long shot
to get them to change it.
------------------------------------------------------------------------
April 24, 2004 - 12:21 : dmjossel
Try tweaking the value of session.gc_maxlifetime either in the .htaccess
file or in php.ini.
The default value in the .htaccess file seems to be 1440 seconds-- or
24 minutes, almost exactly the amount of time my sessions were lasting
before being forced to log in again.
I've increased this value, and now I'm seeing the remember_me cookie
stay with the same value, while the PHPSESSID cookie is constantly
being replaced by a new one-- but I don't have to log in again.
------------------------------------------------------------------------
April 24, 2004 - 20:23 : dmjossel
Well, it's the next morning here, and I'm still logged in at
Rampancy.net and the other Drupal 4.3 sites that are hosted on the same
machine. I think at least this might be a workaround for those who have
this problem and Weitzman's patch alone doesn't solve it.
------------------------------------------------------------------------
April 25, 2004 - 20:02 : dmjossel
After a longer period of inactivity (equal to the value of
session.gc_maxlifetime) the sessions ALWAYS seem to log the user out,
regardless of the remember_me cookie value, the PHPSESSID value, or the
configuration settings for the user module.
------------------------------------------------------------------------
May 6, 2004 - 06:34 : Robert L
I can confirm #41, have tried changing some of the sessions vars in
.htaccess, but this did not solve the problem. Sessions are destroyed
after some time of browser inactivity (some hours). At the browser side
things look oke, it happens with Mozilla and IE. Have not tested the
patch yet, I am not using the remember me cookie option, and this looks
another unrelated (?) problem to me. I use PHP 4.3.6 with Apache 2.
------------------------------------------------------------------------
June 5, 2004 - 21:41 : Anonymous
I fixed it very simply by adding the line:
session_set_cookie_params(0, "/dev/null");
immediately before the call to session_start(). This causes the cookie
that PHP sets to only apply to the path "/dev/null" which, of course,
doesn't exist. Thus, the cookie that Drupal's setcookie() call sets,
with a path of "/", is held on to by the browser, and Drupal goes back
to its old behaviour. It's a hack, but it works.
A better long-term solution would be for Drupal to use the
session_set_cookie_params() call to set the expiry time, rather than
its own call to setcookie().
Tim Bates
------------------------------------------------------------------------
June 6, 2004 - 12:37 : bertboerland(a)www.drop.org
I am sorry to say, that adding a line like that in user.module doesnt do
the trick for me (running php 4.2.3/drupal 4.). Can it be that this
might work under certain conditions which differ from mine? Anyone else
still working on this *critical* bug?
I am not changing the status but I think it should still read "active"?
------------------------------------------------------------------------
June 8, 2004 - 03:58 : bertboerland(a)www.drop.org
never mind my previous remark...
------------------------------------------------------------------------
August 9, 2004 - 20:53 : moshe weitzman
perhaps someone will take interest in this bug. i hope not to release
another drupal version without 'remember me'.
------------------------------------------------------------------------
August 13, 2004 - 16:49 : seanr
This used to work for me. Now I hear it's been completely disabled.
Why? I'd rather have a feature that works for most users and not some
than not have the feature at all.
------------------------------------------------------------------------
September 22, 2004 - 11:39 : Anonymous
We dropped the whole 'remember me' posiibility in drupal 4.5. If it is -
strategically seen - a good move, is another story, but now marked this
as "Won't fix".
------------------------------------------------------------------------
September 22, 2004 - 15:35 : moshe weitzman
umm - thanks 'anonymous'. this is a valid feature request, even if it
isn't a valid bug anymore. marking as such.
------------------------------------------------------------------------
October 13, 2004 - 22:45 : jasper
this is a bug actually. If you don't think so, you really aren't
thinking about user experience.
------------------------------------------------------------------------
October 19, 2004 - 13:48 : jasper
I am having this problem with 4.5. After you login, the cookie that is
set to expire in a month is overwritten by a session cookie, so
remember me doesn;t work.
I "fixed" this by hacking user.module to set its cookie to a
non-existant path. Maybe that will mess something up.
I notice that drupal.org overcomes this by setting the initial cookie
to "host: drupal.org" and the second cookie to "domain: .drupal.org"
Where is this documented? How do you do that?
------------------------------------------------------------------------
October 21, 2004 - 11:43 : Anonymous
I was having the same problem. I changed user.module's call to
setcookie() so that the cookie would expire after 2000000 seconds. That
fixed it for me. Now I don't have to login every time I visit. I hope I
didn't break anything else, though.
setcookie(session_name(), session_id(), FALSE, $path);
becomes:
setcookie(session_name(), session_id(), time() + 2000000, $path);
------------------------------------------------------------------------
October 21, 2004 - 22:03 : dtan
Ya, suddenly noticed that I had to login everytime . . . not a huge
deal, but is a bit of a pain. Should this be a configurable option
for the site?? Obviously from the length of this issue, people feel it
is a useful feature. . .
dtan
------------------------------------------------------------------------
October 26, 2004 - 23:32 : tvst
I WANT THIS FEATURE BACK! Sure, there were problems with it -- but let's
fix the bug instead of killing a nice feature.
------------------------------------------------------------------------
November 3, 2004 - 18:02 : Goba
Dries just committed a patch, which removes that superflous cookie
setting, so session time in upcoming versions will be determined by the
PHP settings, and short lived cookies will not be set.
Until new versions are released, it is completely safe to remove the
setcookie line in user.module (and the preg line above that), and it
solves the problem of users needing to login everytime.
------------------------------------------------------------------------
November 5, 2004 - 01:02 : Anonymous
wow. thanks. this was breaking my sites
------------------------------------------------------------------------
December 14, 2004 - 12:06 : kbahey
This way, the PHP settings are the ones that determine the session
length.
Wouldn't it be better to have an admin option that allows users to set
their session length? with a global default for sessions (e.g. 1 week,
2 weeks, 1 month, ...etc.)
If this option is enabled, then it can be overriden by the user
individually too.
This is a better scheme than having a forced global setting outside
Drupal, on the PHP level for all users.
What do others think?
------------------------------------------------------------------------
February 3, 2005 - 13:50 : kbahey
Reviving this issue.
The session length should be an option that the administrator, or the
end user can set.
We should not rely on the PHP settings alone.
------------------------------------------------------------------------
February 11, 2005 - 19:54 : kbahey
Attachment: http://drupal.org/files/issues/use-module-session.patch (1.92 KB)
I feel that removing the setcookie() call was not the right thing to do.
Session length should not be relegated to .htaccess or php.ini, but
should be an application feature.
I am attaching a patch that reinstates this functionality via a
configuration option. The sysadmin determines how long visitors should
have their session for, and a cookie is set for them with the
appropriate lifetime.
Please look at this rationally and objectively and do not dismiss it
offhand because 'too many options are bad'.
I had to go through php.ini and .htaccess hell for the last few months
because my hosting company has implemented PHP suExec (hence .htaccess
cannot set php parameters), then moved to another machine with
.htaccess reinstated. This also allows people (like me) who serve
several domains from a single Drupal installation to set the session
length differently for different domains.
Moreover, the Drupal end user should not have to go through fiddling
with .htaccess values to get this functionality back.
------------------------------------------------------------------------
February 12, 2005 - 06:51 : Bèr Kessels
-1 for yet another config option.
Thisis a (very) advanced feuature, that will never have to be changed
on a site. Therefore we need to give it a good default, and if people
really want to chage it, those few can do so in conf.php.
Bèr
------------------------------------------------------------------------
February 12, 2005 - 08:57 : Goba
Please *do not use setcookie()* to overwrite the session cookie! The
problem before was that $path and $domain were not the same as set by
the session handler cookie, and so the session handler cookie was not
overwritten. This behaviour depends on host configuration... See, you
introduce a $path variable in your patch, which is not set, and you
don't care about the cookie domain... These were the main problems with
the previous aproach, and this is why the setcookie() was removed. You
should deal directly with the session ini settings!
So please ini_set() the session cookie lifetime, if .htaccess is not
enough for you, and let the session handler set the proper cookie.
------------------------------------------------------------------------
February 12, 2005 - 09:59 : kbahey
Attachment: http://drupal.org/files/issues/user-module-session-2.patch (8.89 KB)
Getting the sysadmin to tweek the .htaccess or php.ini is a tedious
thing. If we can provide a better interface for them to do this, then
it is better. Every time PHP gets upgraded by my hosting company or
move machines, things do not work.
With this patch, the sysadmin can set how long sessions are valid for.
This version of the patch still overrides the session cookie, but uses
the correct path.
I am seeing reluctance to putting this in CVS, based on 'yet another
option' objection, or it being a cookie.
While I can sympathise with the objections, and see their point of
view, I do not see another solution being proposed to those who asked
for this feature to be brought back. See for example comments 46, 49,
and 54.
Taking away a feature is not a good thing.
I would rather have had this be an end user settable option (a global
default for the site, and a per user settable option).
Until the feature is back with a technical solution that is acceptable
to the powers that be, users can use this patch for CVS.
------------------------------------------------------------------------
February 12, 2005 - 10:14 : Goba
kbahey, please, what is the problem with setting the ini setting with
ini_set() runtime? It would work without fiddling with the $path and
$domain... Also note that your patch contains a lot of unrelated
changes...
------------------------------------------------------------------------
February 12, 2005 - 11:06 : kbahey
Attachment: http://drupal.org/files/issues/user-module-session-3.patch (2.04 KB)
Sorry. The patch was for a lot of things by mistake. Here is the patch
only for user.module.
As for ini_set(), I can do:
ini_set ("session.cookie_lifetime", number_of_seconds);
But again, number_of_seconds has to be stored in a varaible, which will
be another option. Will we get the objection "no more options" again?
However, as I understand it, ini_set() has to be called before
session_start() which is the first thing in includes/session.inc. Can
variable_get() be called that early in Drupal life span to get the
stored value?
On a related note, why don't we have the following defaults set in
conf.php, so regardless of .htaccess or php.ini, we ensure they are set
in Drupal no matter what?
ini_set ("session.cache_expire", 200000);
ini_set ("session.gc_maxlifetime", 200000);
ini_set ("session.auto_start", 0);
ini_set ("session.save_handler", "user");
ini_set ("session.cache_limiter", "none");
ini_set ("session.use_trans_sid", 0);
ini_set ("session.use_cookies", 1);
ini_set ("session.use_only_cookies", 1);
This also has the advantage that every domain in a multi-domain
installation can have their own settings, if needed, instead of just
one .htaccess.
------------------------------------------------------------------------
February 12, 2005 - 17:15 : Abalieno
Excuse me, I'm one of the less experienced user of Drupal out there.
This problem was HUGE for me because my installation, by default,
remembered the sessions only for 20 minutes, then forcing me to relog.
I've asked on the mailing list, I had peoples trying to register at my
site to figure it out, I asked in other mailing lists. Nothing.
At the end I discovered that it wasn't Drupal but a variable into
php.ini (session.gc_maxlifetime). Noone was able to point me in the
right direction. The last message I received from Mark Quinn is:
"As for your PHP session issue, you may want to try and take it up with
your hosting service, or wait until drupal properly resolves the issue
with an application-managed cookie; I've not yet seen any discussion
patches come through on this, myself. Maybe the Usual Suspects may have
a better idea of whether someone is working on this part of the code, at
present."
At the end I was able to fix this by changing the php.ini. But it was a
pain.
I don't know from where comes the 'design choice' of 'not another
setting'. This is a *basic* feature that on EVERY other engine can be
set in the option.
What is better? Something that you can notice easily in a configuration
page or something that was set by someone else and there's no other way
to change than to hack it yourself because the engine isn't flexible?
"This a (very) advanced feature, that will never have to be changed on
a site."
No, this is a BASIC feature on EVERY engine. In general the users of a
site need to set this by themselves, some want to be anonymous, some
want to log it just once and forget, some want to log in once and
remain logged forever.
Not only this should be an option, but this should be also defined, by
default, in the permissions panel. So that each member can set the
cookie in the preferred way.
------------------------------------------------------------------------
February 12, 2005 - 18:47 : kbahey
This is exactly what I mean: we removed a feature and did not provide a
replacement.
My attempt to reintroduce the feature, admittedly having some
drawbacks, was dimissed with no alternative provided.
Can we discuss the alternatives, and implement a solution before 4.6 is
out?
------------------------------------------------------------------------
February 12, 2005 - 22:57 : Bèr Kessels
I did provide an alternative, only not in so much words:
Use variable_set("site_cookie_lifetime",200000) and then ini_set to
enforce a correct *default* lifetime.
This will do for 99% ofthe drupal sites and users.
For those 1% that want to control everything: use a setting in
settings.php:
# Variable overrides:
#
# To override specific entries in the 'variable' table for this site,
# set them here. You usually don't need to use this feature. This
is
# useful when used in a configuration file for a vhost or directory,
# rather than the default settings.php. Any configuration setting
from
# the variable table can be given a new value.
#
# $conf = array(
# 'site_name' => 'My Drupal site',
# 'theme_default' => 'pushbutton',
# 'anonymous' => 'Visitor'
# );
Really: I visit a lot of geeky pages everyday, but never, ever have i
even there seen an option to say how long a cookie will live on my HDD.
Let alone on the joe-average site.
We really do not want joe-average to give answers to questions like
"how long should you remain logged in". The machines i.c..w admins
should make that choice for him.
------------------------------------------------------------------------
February 12, 2005 - 23:19 : Anonymous
To start with the last comment about no sites doing this, Google's own
Gmail has a checkbox that says : "Keep me logged in for two weeks".
Hotmail and Yahoo both have a check box "remember my password on this
computer". Even Slashdot has such an option.
So, it is a fairly common way to do things, and was present in Drupal
but taken away.
Now to the solution:
You say
"Use variable_set("site_cookie_lifetime",200000) and then ini_set to
enforce a correct *default* lifetime.
"
So, we are still going to have an option to set and save the
site_cookie_lifetime. So, I assume that part of the user.module patch
will remain. Good!
Now, for the ini_set() part. I see that it has to be called before
session_start() is called. I asked above where it should go. Should it
go in session.inc? If so, I can add it there, and that would be that.
Regarding the second option: Which variable specifically should be
overriden in the $conf array to achieve this?
------------------------------------------------------------------------
February 12, 2005 - 23:20 : kbahey
Oops! That was me. Drupal.org logged me out. Sort of relevant to the
discussion ;-)
------------------------------------------------------------------------
February 12, 2005 - 23:32 : Bèr Kessels
to clarify:
an option is:
Session lifetime:
[400000_________]
provide the lifetime of your users sessions in seconds.
A user option for this would be:
username [__________]
password [__________]
session lifetime [__________]
Those are unwanted. Wanted, however is:
* No options in the interface, but in code only!
*
username [__________]
password [__________]
remember [x]
That is my point, and not that we should not have a lifetime in PHP.
------------------------------------------------------------------------
February 12, 2005 - 23:41 : kbahey
No one suggested that we should give the end user, nor the sysadmin the
number of seconds. Even the patch as it stands today does not do that,
but displays: 1 day, 2 days, 1 week, 2 weeks, 1 month, ....etc.
So, on the login screen, there would be a "remember me" checkbox. Then
in the admin screens there would be an option like the one above for
how long this 'remembering' should be.
If someone answers the last two paragraphs in #69, I can get this done
soon.
------------------------------------------------------------------------
February 13, 2005 - 00:23 : Abalieno
Again I cannot code myself but I think I can provide a good solution.
Why not to add options that are configurable, but just not under the
eyes of everyone?
This system should work this way:
- By default Drupal should do what it does already. Users are
automatically logged in for one month (about 2000000 seconds of the
default option). Not using php.ini or .htaccess but its own cookies.
- Then you add an option and link it to the permission pages.
- The admin of the site will access a special page where he can set:
* The default behaviour of the site for EVERY user. -> One day, one
week , two weeks, a month, three moths, forever.
Depending on this setting the variable will be reset as the standard
option for every new user.
Then, in the case the user is in a usergroup flagged to administer this
option, each user has a new option in the config page of his account:
* For how long you want Drupal to log you in automatically? -> One day,
one week , two weeks, a month, three moths, forever.
* A checkbox to remain anonymous even when logged in.
This makes no option appear on the homepage, it allows Drupal to be
set, by default, in an optimal way that doesn't need to be changed.
But, in the case it's needed, it provides configurable options that
both the admin and each user can set.
Imho, the "remember me" box on the homepage isn't needed. Drupal is ok
how it is already. What it needs is configurable options and
permissions on their own page (the same page where you can set the
timezone).
------------------------------------------------------------------------
February 13, 2005 - 06:19 : Bèr Kessels
I do no know if it is me that is not clear, or you that cannot
understand me:
I, and might be only me, do *not* want any new config option in the
config screens.
Be it textareas where you can add seconds, or dropdowns where you can
set weeks, days etc.
Why not?
I think this config option is 1) confusing and 2) unnessecary for 99%
of the drupal cases.
On top of that: this is a one-tim setting. On top of thát, it is a
setting only advanced users will want to tweak (the 1%).
So I am suggesting you code whatever you want to code for it, cookies,
init, php.ini settings, whatever. But do /not/ add new config options
in the admin or user screens. People (that 1%) can then set the
variable in settings.php
------------------------------------------------------------------------
February 13, 2005 - 07:15 : stefan nagtegaal
I totally agree with Ber on this one.. We already have to much
'setup-once-and-never-change-again' options inside drupal which are
UI-clutter.. This, is in my opinion an option of the same type. You set
this once, and never look at it again.. So, absolutely a -1 to put on
one of the options screens again..
------------------------------------------------------------------------
February 13, 2005 - 13:39 : kbahey
Attachment: http://drupal.org/files/issues/user-module-session-4.patch (1.27 KB)
Here is a new version of the patch.
There is no configuration option anymore.
The default is set to 30 days where the session cookie is valid for.
This value can be overriden by setting a line for it in the $conf
variable in the settings.php file under the sites directory.
How does that look to others?
------------------------------------------------------------------------
February 13, 2005 - 13:55 : Goba
How many times should I ask for ini_set()-ing the session cookie
lifetime, and using less code, instead of hacking around with
overwritinng the cookie? Please! Yes, the session.inc code is included
from bootstrap.inc after variable_get and the settings.php file data is
already available! I know this not because I know Drupal code, but
because I just looked into index.php, and followed the includes...
------------------------------------------------------------------------
February 13, 2005 - 14:10 : kbahey
Attachment: http://drupal.org/files/issues/session-inc.patch (1.11 KB)
Here is the patch using ini_set() for the session.cookie_lifetime
override.
Ber, Stefan, and Goba: do you have any more concerns/objections?
------------------------------------------------------------------------
February 13, 2005 - 14:17 : Goba
Yes, you have at least one typo in the comment: "by by", plus you don't
need to have one intermediate variable, you can directly include the
return value of variable_get() in the ini_set() call.
Plus since you override the .htaccess setting here, .htaccess needs a
comment in it that the setting is overwritten in the session.inc file.
Or better, the .htaccess setting needs to be commented out and it
should be noted there that this is set programatically. So someone who
changes the .htaccess should not expect the setting to change. This is
crucial to make this stuff be easy to handle from the support viewpoint
later...
------------------------------------------------------------------------
February 13, 2005 - 14:29 : stefan nagtegaal
Maybe it would also be handy - for codewise cosistency - to use Doxygen
comments....
------------------------------------------------------------------------
February 13, 2005 - 15:02 : kbahey
Attachment: http://drupal.org/files/issues/session-inc-3.patch (2.25 KB)
If it was up to me, I would have moved all the .htaccess php values and
flag into Drupal itself using ini_set. This way, it does not matter
who takes precedence over whom (.htaccess, global php.ini, php.ini in
users' public_html directory, ...etc.). However, different PHP versions
have different permissions and defaults, and this would not be possible
until everyone settles down on PHP5.
Goba, I know that it can all be on one line. My personal preference is
to break it down to be more readable. However, for the sake of being
consistent with everyones' else code, I will do it your way.
Here is a version of the patch that:
1. Makes it all on one line (variable_get is not stored in a temporary
variable)
2. Makes the comment doxygen style
3. Comments out the variable in .htaccess
4. Adds the values for ensuring that PHP would not append the PHPSESSID
to the url, and only uses cookies to .htaccess
------------------------------------------------------------------------
February 13, 2005 - 16:43 : Bèr Kessels
kbahey,
Thank you a lot for your work and efforts. Please do not get our (mine,
Gobas and Stefans) objections as nitpicking or as criticism. On
contrary. The very fact that I am commenting on your code is that I see
it valuable. But I saw it going into That Heap Of Patches That Will
Never BE Committed [tm]. Simply because of code style, config options
and all the likes.
I am confident thatboth Goba and Stefan, just like me, liked the fact
there is work done on important issues.
Thanks again for your time, and most of all for not getting annoyed by
people lilke me hammering (but not committing code myself) on issues!
we need people like you much more than people like me (only giving
critique on ones work).
Bèr
------------------------------------------------------------------------
February 13, 2005 - 17:34 : kbahey
Ber,
Thanks for taking the time to clarify, and for the clarification. I did
not take the comments negatively, and they did not upset me (not a lot
anyway).
I have tested the cookie, and it works well on my test machine.
I hope it does the same on my hosting machine, which I cannot upgrade
to CVS until 4.6 stabilizes a bit. On that machine, I had troubles with
php.ini (in public_html with PHP SuExec) and .htaccess, and confused
precedence
I hope Dries applies this before 4.6 is released.
Thanks again.
------------------------------------------------------------------------
February 13, 2005 - 23:03 : jvandyk
Tested and works on my test machine (PHP 4.3.10, MySQL 4.19, Drupal
HEAD).
------------------------------------------------------------------------
February 14, 2005 - 09:56 : kbahey
A related patch that moves the session.cookie_lifetime value to
settings.php is available.
Please see http://drupal.org/node/17303
------------------------------------------------------------------------
February 16, 2005 - 17:00 : Dries
Can't we merge both patches? Or I can commit one, and ask for the other
to be updated?
--
View: http://drupal.org/node/2974
Edit: http://drupal.org/project/comments/add/2974
1
0