February 2005 - Development - lists.drupal.org

[drupal-devel] Top navigation menu configuration
by Chris Cook 26 Feb '05

26 Feb '05

I am concerned about why primary and secondary navigation links are configured in Themes (or in the theme specific settings in the case of PHPTemplate). Menu links should be configured in Drupal settings somewhere and not in themes. Whether or not to display these navigation menus may be a theme setting but not creation of the menu items themselves. Off the top of my head I'm uncertain where the configuration of these menus should be moved to. Perhaps the main "Settings" page or perhaps a new page. Thoughts?

2 1

[drupal-devel] Codefilter
by Chris Cook 25 Feb '05

25 Feb '05

There are a couple of patches in the codefilter issue queue which would be nice to see applied on Drupal.org. The whitespace issue is particularly annoying. Is Steven Wittens still maintaining this module? There are several other issues as well that I haven't created patches for because I'm not exactly a regexpr guru. If anyone could step up it would be much appreciated. Cheers, Chris

1 0

[drupal-devel] [feature] "remember me" doesn't work
by pildit 25 Feb '05

25 Feb '05

Project: Drupal -Version: cvs +Version: 4.5.2 Component: user.module Category: feature requests Priority: normal Assigned to: kbahey Reported by: marco Updated by: pildit Status: patch Hi, I am a newbie to Drupal. I have installed Drupal 4.5.2 and I need to have the "remember_me" checkbox in the login box. Can anyone please explain me how to get it back and functional ? Thanks, pildit Previous comments: ------------------------------------------------------------------------ September 22, 2003 - 13: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 11, 2003 - 00:37 : moshe weitzman Can anyone confirm this? Also, how to fix? ------------------------------------------------------------------------ October 12, 2003 - 17: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 - 18: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 - 23: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 - 20: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 18, 2003 - 02:53 : moshe weitzman since noone can reproduce this, i am marking as 'by design' ------------------------------------------------------------------------ November 25, 2003 - 07: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 - 14: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 - 15: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 - 12:35 : moshe weitzman To make matters more complicated, I cannot reproduce this using PHP as an ISAPI module on IIS ------------------------------------------------------------------------ November 26, 2003 - 19: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 4, 2003 - 01: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 - 16: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 - 20: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 - 17: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 - 18: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 - 05: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 - 13: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 - 10: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 - 11: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 - 16: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 - 17: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 9, 2004 - 01: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 - 17: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 - 21: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 - 07: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 22, 2004 - 02: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 22, 2004 - 03: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 - 10: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 - 10: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 - 16: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 - 16: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 24, 2004 - 00: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 - 17: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 25, 2004 - 01: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 26, 2004 - 01: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 - 11: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 6, 2004 - 02: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 - 17: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 - 08:58 : bertboerland(a)www.drop.org never mind my previous remark... ------------------------------------------------------------------------ August 10, 2004 - 01: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 - 21: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 - 16: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 - 20: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 14, 2004 - 03:45 : kevin lapalme this is a bug actually. If you don't think so, you really aren't thinking about user experience. ------------------------------------------------------------------------ October 19, 2004 - 18:48 : kevin lapalme 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 - 16: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 22, 2004 - 03: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 27, 2004 - 04: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 - 23: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 - 06:02 : Anonymous wow. thanks. this was breaking my sites ------------------------------------------------------------------------ December 14, 2004 - 17: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 - 18: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 12, 2005 - 00: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 - 11: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 - 13: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 - 14: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 - 15: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 - 16: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 - 22: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 - 23: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 13, 2005 - 03: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 13, 2005 - 04: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 13, 2005 - 04:20 : kbahey Oops! That was me. Drupal.org logged me out. Sort of relevant to the discussion ;-) ------------------------------------------------------------------------ February 13, 2005 - 04: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 13, 2005 - 04: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 - 05: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 - 11: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 - 12: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 - 18: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 - 18: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 - 19: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 - 19: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 - 19:29 : stefan nagtegaal Maybe it would also be handy - for codewise cosistency - to use Doxygen comments.... ------------------------------------------------------------------------ February 13, 2005 - 20: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 - 21: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 - 22: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 14, 2005 - 04:03 : jvandyk Tested and works on my test machine (PHP 4.3.10, MySQL 4.19, Drupal HEAD). ------------------------------------------------------------------------ February 14, 2005 - 14: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 - 22:00 : Dries Can't we merge both patches? Or I can commit one, and ask for the other to be updated? ------------------------------------------------------------------------ February 16, 2005 - 22:36 : kbahey 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 -- View: http://drupal.org/node/2974 Edit: http://drupal.org/project/comments/add/2974

1 0

[drupal-devel] [bug] Vocabularies with no associated node types are not displayed
by drumm 25 Feb '05

25 Feb '05

Project: Drupal Version: cvs Component: taxonomy.module Category: bug reports Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/taxonomy.module_1.diff (1.98 KB) Changed the order of the joins so that a vocabulary which is not associated with any node types doesn't disappear. Also removed a centered column that shouldn't be hard coded and, IMO, looked rather weird. drumm -- View: http://drupal.org/node/17897 Edit: http://drupal.org/project/comments/add/17897

1 2

[drupal-devel] Mailing stories and photos from Drupalcon 2005
by Robert Douglass 25 Feb '05

25 Feb '05

Sorry for abusing this list, but it is the quickest way to reach all the people who are in Antwerp! If you want to contribute stories or photos from Drupalcon 2005 to the soon-to-be-launched NowPublic.com site, send a mail to: bhndev(a)nowpublic.com with NP! 4288 in the body. Attach your photos, write your texts on another line - it will all be published under the appropriate story and you will also get registered on the site. If you're not in Antwerp, wish you were here, sorry for the noise! -Robert

3 2

[drupal-devel] [bug] Refactor/correct access rules pages
by drumm 25 Feb '05

25 Feb '05

Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: critical Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/user.module_14.diff (6.32 KB) * split up the menu callback for editing/adding/deleting rules * improved the delete message * fixed a double page printing bug drumm -- View: http://drupal.org/node/17931 Edit: http://drupal.org/project/comments/add/17931

1 0

Re: [drupal-devel] *Begging* for checkbox to moderation pages
by Kobus Myburgh 25 Feb '05

25 Feb '05

Hi, I have the same problem and it is really annoying. I agree that this patch is becoming a necessity. Thanks, Kobus >>> abalieno(a)cesspit.net 2/25/2005 7:54:40 AM >>> To understand why I'm asking this you have too see this picture: http://www.cesspit.net/misc/spam.gif Now all that is *already* in the moderation queue, so it's not published. But I absolutely need a way to delete all that crap. It spans various pages and it would take me HOURS to delete each message one by one. Please, can someone build a small patch to apply to Drupal 4.5.2 that adds checkboxes to each comment so that I can wipe all that with one action? Who I have to pay for that? -HRose / Abalieno

1 0

[drupal-devel] New taxonomy_xml.module
by Sheldon Rampton 25 Feb '05

25 Feb '05

I've just added my first project to Drupal contributions, titled "taxonomy_xml.module." Since this is my first time contributing (and I don't have a lot of experience with CVS), I'm not sure I did everything correctly. If I did anything wrong, I hope someone here can help me out so I can fix it. I *have* participated previously in contributing revisions to wmfilter.module, which was written originally by Aldon Hynes and subsequently reworked by both Aldon and myself. After some discussions, we've decided that it ought to be renamed to "interwiki.module." What's the procedure we should follow to deprecate "wmfilter" and replace it with "interwiki"? Regards, Sheldon Rampton

3 2

[drupal-devel] [feature] Small fix for conf.php.
by tangent 24 Feb '05

24 Feb '05

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Chris Johnson Reported by: Uwe Hermann Updated by: tangent Status: patch Makes sense to me. +1 tangent Previous comments: ------------------------------------------------------------------------ October 16, 2004 - 08:11 : Uwe Hermann As seen here [1] it's not so obvious what to fill into the $dburl line in include/conf.php. My suggestion to clarify this a bit: Replace # $db_url = "mysql://user:password@hostname/database"; with # $db_url = "mysql://dbuser:dbpassword@dbhostname/database"; This should make it a little clearer that the database user, password and host is meant. The same should be done with the PostgreSQL line... [1] http://drupal.org/node/11325#comment-17968 ------------------------------------------------------------------------ February 24, 2005 - 10:31 : Chris Johnson Attachment: http://drupal.org/files/issues/conf.php.patch (579 bytes) Here's a simple patch against 4.5.2. ------------------------------------------------------------------------ February 24, 2005 - 10:35 : Chris Johnson Attachment: http://drupal.org/files/issues/settings.php.patch (551 bytes) And here is the equivalent patch for HEAD, against settings.php. -- View: http://drupal.org/node/11645 Edit: http://drupal.org/project/comments/add/11645

1 0

[drupal-devel] [feature] Better validation of new users email address when creating account
by budda 24 Feb '05

24 Feb '05

Project: Drupal Version: 4.5.2 Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: budda Updated by: budda Status: patch Working with the user.module of 4.5.2 distribution I amended the user_validate_mail() function to provide additional checking for a new user. This was inspired by the constant bounced emails I was getting each day from new users mistyping their email address. Sorry that the code is not in patch form. The following code should be placed in user.module :- function _user_check_dnsrr($maildomain, $rectype = 'MX') { if(!empty($maildomain)) { if(function_exists('checkdnsrr')) { return checkdnsrr($maildomain, $rectype); } else { exec("nslookup -type=$rectype $maildomain", $result); foreach ($result as $line) { if(eregi("^$maildomain",$line)) { return true; } } return false; } } return false; } function user_validate_mail($mail) { if (!$mail) return t('You must enter an e-mail address.'); list($username, $maildomain) = split("@", $mail); if (!valid_email_address($mail) || !_user_check_dnsrr($maildomain, "MX")) { return t('The e-mail address %mail is not valid.', array('%mail' => "<em>$mail</em>")); } } I have been using the above on http://www.bargainspy.co.uk/user/register without problem for a day now. Another step in the direction of helping users hide their general stupidity! budda -- View: http://drupal.org/node/17780 Edit: http://drupal.org/project/comments/add/17780

3 4