August 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Custom registration fields should appear on admin/user/create
by moshe weitzman 08 Aug '05

08 Aug '05

Issue status update for http://drupal.org/node/23536 Post a follow up: http://drupal.org/project/comments/add/23536 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: chx Reported by: moshe weitzman Updated by: moshe weitzman -Status: patch (code needs review) +Status: patch (ready to be committed) I applied the patch and registered as regular user and as admin. works as advertised. code looks good, and consolidates the registration forms so we don't have special admin only form. +1 moshe weitzman Previous comments: ------------------------------------------------------------------------ Tue, 24 May 2005 19:02:40 +0000 : moshe weitzman When creating a new user as an admin, it is useful and even expected to be able to complete all the profile fields which are available on the usual registration form ... the approach might be to consolidate registration so that both users and admins use a single form. ------------------------------------------------------------------------ Sat, 25 Jun 2005 22:27:41 +0000 : chx Attachment: http://drupal.org/files/issues/user_reg.patch (8.69 KB) At first I thought it'd be better if I'd keep the separate form, but this version results in shorter code and it's not so ugly. However, if you do not like it, I have the version which only adds the $extra to user_admin_create. ------------------------------------------------------------------------ Sun, 26 Jun 2005 18:08:48 +0000 : killes(a)www.drop.org I like this patch. ------------------------------------------------------------------------ Tue, 28 Jun 2005 01:53:01 +0000 : moshe weitzman to me, this version is great as it unifies the registration code. i did a code review and all looks good to me. i applied the patch and noticed that - i added a required checkbox field via profile.module. the check appeared on the reg form without the 'required' marker and the registration was accepted without checking the box. then i tried this for a textfield and it properly showed the 'required' marker but it didn't enforce the 'required' bit either. so then i tried to edit the user and even then we seem not to be enforcing the 'required' bit. this looks like a profile.module bug. if you are up for it, you might want to investigate the above. but truly, enforcing the required bit is not related to this patch. so +1 from me. ------------------------------------------------------------------------ Fri, 01 Jul 2005 06:00:21 +0000 : chx Attachment: http://drupal.org/files/issues/user_reg_0.patch (9.01 KB) It was intentional that the check for required fields are skipped for admins. I deleted that check. ------------------------------------------------------------------------ Wed, 06 Jul 2005 06:28:35 +0000 : Torenware Attachment: http://drupal.org/files/issues/user_reg_4.6.2.patch (8.33 KB) This patch is massively useful (at least for me...) and was exactly what I was looking for. Since I can't use the CVS version, I back-ported it to 4.6.2. It's syntactically valid, and it seems to work, although I have not tested it thoroughly. I'm uploading it in case anyone else wants to try it out, or is willing to test it. I'll be using it in any case. YMMV, of course :-) Rob Thorne Torenware Networks ------------------------------------------------------------------------ Mon, 18 Jul 2005 20:07:18 +0000 : chx Attachment: http://drupal.org/files/issues/user_reg_1.patch (8 KB) after discussions with Dries and Moshe I put the requirement uncheck and removed my description trickery.

1 0

[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them
by djnz 08 Aug '05

08 Aug '05

Issue status update for http://drupal.org/node/4109 Post a follow up: http://drupal.org/project/comments/add/4109 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Eric Scouten Reported by: Eric Scouten Updated by: djnz Status: patch (code needs review) Attachment: http://drupal.org/files/issues/trans_sid.patch (1.4 KB) After further thought, there really is no point in appending the SID to a redirect url, so the attached patch solves this problem too. If anyone has a problem with session IDs in URLs after applying this patch, I'll offer them free hosting myself. Maybe. ;) djnz Previous comments: ------------------------------------------------------------------------ Thu, 13 Nov 2003 00:22:39 +0000 : Eric Scouten Some URLs get ?PHPSESSID=(whatever) added to them. I find this distracting and unnecessary for anonymous users. Submitting patch #147 for consideration to remove this issue. ------------------------------------------------------------------------ Fri, 05 Dec 2003 14:39:25 +0000 : Kjartan This is a local PHP configuration issue. Don't see it as something Drupal should mess with, the less PHP settings Drupal messes with the better. ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:11:33 +0000 : killes(a)www.drop.org Could you elaborate which config setting one has to tweak? ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:18:11 +0000 : Anonymous php_flag session.use_trans_sid off php_flag session.use_only_cookies on The first will disable the automatic addition of the session ID to internal URLs, the second will remove support for passing session IDs in URLs. See http://php.net/session [1] for more info. BTW the above settings are for Apache, in PHP.ini you should not add the php_flag part, and you should use = inbetween the name and value... [1] http://php.net/session ------------------------------------------------------------------------ Mon, 07 Jun 2004 22:42:06 +0000 : shane It seems that Drupal (via the .htaccess file) already "messes with" a bunch of PHP settings. For example, my Drupal install "came with" these messed with settings: php_value register_globals 0 php_value track_vars 1 php_value short_open_tag 1 php_value magic_quotes_gpc 0 php_value magic_quotes_runtime 0 php_value magic_quotes_sybase 0 php_value arg_separator.output "&" php_value session.cache_expire 200000 php_value session.gc_maxlifetime 200000 php_value session.cookie_lifetime 2000000 php_value session.auto_start 0 php_value session.save_handler user php_value session.cache_limiter none php_value allow_call_time_pass_reference On I'm not sure that adding two more "php_value" flags to the stock .htaccess file is going to arguably mess with more than already is. Personally I find it extremely un-professional and very un-clean to have funky PHPSESSID url strings tacked onto a majority of my URLs. I've worked extremely hard to implement clean URLs (above and beyond the already great "clean url" feature of Drupal - I don't like them being turned into muck. I'd vote that these two flags be added to the .htaccess file that is distributed with Drupal. However, I'm uncertain of the overall true impact of making these changes, so barring an technical reason - I would absolutely request this as a feature. I've implemented these in many of my production sites already (just today) - we'll see what impact they have. ------------------------------------------------------------------------ Tue, 08 Jun 2004 02:56:00 +0000 : marky It's a performance thing. You need to remember that while not everyone has edit access to php.ini, those of us that do control our own servers see no need for .htaccess directives that set php options. >From the Apache docs [2]: "Apache will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested." Ok, I'm lucky in that I control my own server, so I can effectively remove the .htaccess file and move its config options to php.ini and the vhost section of httpd.conf, thus speeding up the responsiveness of my server. But if you don't have that option there's nothing wrong with adding those directives to your directory .htaccess file. That's what it's for - it allows directory specific config options for those that don't have access to their server config. As Kjartan said, "the less PHP settings Drupal messes with the better". I've got to agree - as far as I'm concerned it's already big enough. The "php_value short_open_tag 1", "php_value session.auto_start 0" and "php_value session.cache_limiter none" for example serve little purpose, as they mirror the installation default settings (apart from the last, where the available options are: nocache, private or public). If you don't have the choice, use .htaccess, and add whatever directives you see fit. But please remember that not everyone uses it. Anyway, just my 2 beads. [2] http://httpd.apache.org/docs-2.0/howto/htaccess.html#when ------------------------------------------------------------------------ Tue, 08 Jun 2004 04:38:32 +0000 : cel4145 Why not add them, but commented out with an explanation? When I encountered this problem, I had to spend a little time on drupal.org finding the solution. However, I am familiar with the .htaccess file from doing installs. If it had been included there commented out, I would have probably remembered it. After all, this is much the same way that httpd.conf functions with it's many, optional, commented out configuration options. Just makes it easier when a non-standard configuration option has to be used. Besides, I've also seen many Drupal sites with this problem. I suspect that some of those sites would have implemented these flags if they had been an option in the .htaccess file. And it looks bad. People that visit the sites that don't know any better will assume it's Drupal, not the lack of proper PHP settings. ------------------------------------------------------------------------ Tue, 08 Jun 2004 10:39:27 +0000 : killes(a)www.drop.org It wouldn't hurt if Drupal had a better documented and possibly extended .htaccess file. Those who whish not to use it should really not care... session.save_handler = user should probably included as well. ------------------------------------------------------------------------ Tue, 08 Jun 2004 12:17:06 +0000 : robertDouglass If you use these settings: php_flag session.use_trans_sid off php_flag session.use_only_cookies on won't it make it so that people with cookies disabled cannot have session state? And if the PHPSESSID is in the URL, isn't that an indication that the browser being used refused to take a cookie? I'd really like clarification on this, if anyone knows the answers. ------------------------------------------------------------------------ Tue, 27 Jul 2004 13:25:46 +0000 : JonBob The original issue is definitely by design, as these URLs need the session ID to preserve the session when running under the given PHP settings. A better-documented .htaccess is a different issue entirely. ------------------------------------------------------------------------ Thu, 19 Aug 2004 18:04:13 +0000 : gtoddv It hasn't been mentioned in this thread or anywhere else that I can find, but this session ID issue breaks validation. I don't know is this will cause accessibility issues too. I have tried the .htaccess fix and that doesn't change anything. ------------------------------------------------------------------------ Sat, 06 Nov 2004 07:17:21 +0000 : wazdog The non-validating problem is another problem with your server setup. PHP can be setup to used encoded &'s or not. Your server isn't if the url isn't validating. You'd have to talk to your server admin to fix that. ------------------------------------------------------------------------ Thu, 30 Dec 2004 20:32:35 +0000 : m_freeman2004 This is what you have to include in the .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix ------------------------------------------------------------------------ Wed, 01 Jun 2005 19:07:53 +0000 : dr05 The code in .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix don't work! Error: "Internal Server Error!" ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:25:22 +0000 : jasonwhat Anyone else looking into this? Can one get rid of the id added onto the url but still keep the sessions going? ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:16:22 +0000 : Eric Scouten dr05, what version of Apache and what OS are you using? I've been using this same patch with no problems on Mac OS X, Linux, and FreeBSD-based servers using both Apache 1.3.x and 2.0.x. Attached patch will apply these changes to .htaccess. (IMHO, this is useful for the majority of users; those who are smart enough to understand the performance issues can comment out these lines.) ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:57:18 +0000 : clydefrog You forgot the patch, Eric. ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:02:26 +0000 : Eric Scouten Attachment: http://drupal.org/files/issues/htaccess-no-session-ids.patch (383 bytes) D'oh! ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:45:48 +0000 : kbahey There are cases where no parameter will fix this issue. On shared hosting systems where you do not have access to php.ini, and the hosting company has setup things in a way that they cannot be overriden. I found this out the hard way, after lobbying for the settings to be included in the init_set() statements in the settings.php prior to 4.6 being released. They are simply ignored on some hosts. On other hosts, you need to have a php.ini of your own, if suphp or SuExec is being used. In some cases, the only way to make things work is to compile your own PHP as a CGI (detailed writeup) [3]. This can have disadvantages too, such some performance impact, as well as excessive CPU utilization (hosting company may not like it). [3] http://baheyeldin.com/drupal/how-to-get-rid-of-phpsessid-in-drupal-and-othe… ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:49:31 +0000 : kbahey Here is some references: issue 21170 [4], and a forum discussion [5]. [4] http://drupal.org/node/21170 [5] http://drupal.org/node/17947 ------------------------------------------------------------------------ Sat, 30 Jul 2005 16:24:47 +0000 : ufku in my case (shared hosting, ini_set() disabled) a php.ini file with only this line in it solved the problem. url_rewriter.tags = '' you should place the php.ini in your site's base directory ------------------------------------------------------------------------ Sun, 07 Aug 2005 12:18:31 +0000 : djnz Attachment: http://drupal.org/files/issues/rewrite_tags.patch (468 bytes) Drupal already attempts to change a number of values using ini_set() in settings.php, including session.use_trans_sid which should cure this problem. Unfortunately as already noted elsewhere [6], session.use_trans_sid only worked in ini_set() up to PHP 4.2.3. Rather than change the whole philosophy and change this setting in .htaccess or php.ini (neither of which work for many hosted set-ups), surely the answer is to correct settings.php as described The attached patch does just that - it is only one line. Note that session ids are still appended to the url when redirecting by Drupal eg after a POST. This is also easily patched [7], but as it is done deliberately (why?) I have left it alone. [6] http://drupal.org/node/17947#comment-36339 [7] http://drupal.org/node/25852#comment-45111 ------------------------------------------------------------------------ Sun, 07 Aug 2005 13:26:17 +0000 : kbahey PHPSESSIDs in the URL are a) ugly, b) negatively affects search engine indexing, and most importantly, c) is a security risk that can enable a malicious user to hijack your session. We should work on a solution to eliminate this once and for all, and for all configurations. The current approach (putting some PHP parameters in settings.php, or instructing users to change them in .htaccess or php.ini) has severe shorcomings: Whatever we do, there are bound to be some configurations that no amount of PHP parameters will cure. Some hosts deny their users the ability to change some or all of the above parameters. I discovered this the painful way with many hosts I have used, and friends and clients I have helped. I think we need to rethink this whole session thing, in a way that we are not dependant on idiosyncracies of various hosts and PHP configurations. Perhaps attempt to set a DRUPAL cookie and not maintain a session unless we are able to set it. This way we know that we will not have a PHPSESSID in the URL. If we are not able to set the cookie, then we allow only anonymous access that is sessionless.. I am not sure if that will work or not: what other options do we have here? ------------------------------------------------------------------------ Sun, 07 Aug 2005 22:02:19 +0000 : djnz I am convinced that ini_set('url_rewriter.tags','') is the answer. I find it hard to believe that any host would go to the trouble to disable this (not just a matter of setting compile time paramaters, you would have to hack the PHP source; and why would they?) - certainly no cPanel host I have used does. The reason the code currently in settings.php doesn't work is not because hosts disable it, it is because PHP does not support it. RTFM.

1 0

[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them
by djnz 08 Aug '05

08 Aug '05

Issue status update for http://drupal.org/node/4109 Post a follow up: http://drupal.org/project/comments/add/4109 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Eric Scouten Reported by: Eric Scouten Updated by: djnz Status: patch (code needs review) I am convinced that ini_set('url_rewriter.tags','') is the answer. I find it hard to believe that any host would go to the trouble to disable this (not just a matter of setting compile time paramaters, you would have to hack the PHP source; and why would they?) - certainly no cPanel host I have used does. The reason the code currently in settings.php doesn't work is not because hosts disable it, it is because PHP does not support it. RTFM. djnz Previous comments: ------------------------------------------------------------------------ Thu, 13 Nov 2003 00:22:39 +0000 : Eric Scouten Some URLs get ?PHPSESSID=(whatever) added to them. I find this distracting and unnecessary for anonymous users. Submitting patch #147 for consideration to remove this issue. ------------------------------------------------------------------------ Fri, 05 Dec 2003 14:39:25 +0000 : Kjartan This is a local PHP configuration issue. Don't see it as something Drupal should mess with, the less PHP settings Drupal messes with the better. ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:11:33 +0000 : killes(a)www.drop.org Could you elaborate which config setting one has to tweak? ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:18:11 +0000 : Anonymous php_flag session.use_trans_sid off php_flag session.use_only_cookies on The first will disable the automatic addition of the session ID to internal URLs, the second will remove support for passing session IDs in URLs. See http://php.net/session [1] for more info. BTW the above settings are for Apache, in PHP.ini you should not add the php_flag part, and you should use = inbetween the name and value... [1] http://php.net/session ------------------------------------------------------------------------ Mon, 07 Jun 2004 22:42:06 +0000 : shane It seems that Drupal (via the .htaccess file) already "messes with" a bunch of PHP settings. For example, my Drupal install "came with" these messed with settings: php_value register_globals 0 php_value track_vars 1 php_value short_open_tag 1 php_value magic_quotes_gpc 0 php_value magic_quotes_runtime 0 php_value magic_quotes_sybase 0 php_value arg_separator.output "&" php_value session.cache_expire 200000 php_value session.gc_maxlifetime 200000 php_value session.cookie_lifetime 2000000 php_value session.auto_start 0 php_value session.save_handler user php_value session.cache_limiter none php_value allow_call_time_pass_reference On I'm not sure that adding two more "php_value" flags to the stock .htaccess file is going to arguably mess with more than already is. Personally I find it extremely un-professional and very un-clean to have funky PHPSESSID url strings tacked onto a majority of my URLs. I've worked extremely hard to implement clean URLs (above and beyond the already great "clean url" feature of Drupal - I don't like them being turned into muck. I'd vote that these two flags be added to the .htaccess file that is distributed with Drupal. However, I'm uncertain of the overall true impact of making these changes, so barring an technical reason - I would absolutely request this as a feature. I've implemented these in many of my production sites already (just today) - we'll see what impact they have. ------------------------------------------------------------------------ Tue, 08 Jun 2004 02:56:00 +0000 : marky It's a performance thing. You need to remember that while not everyone has edit access to php.ini, those of us that do control our own servers see no need for .htaccess directives that set php options. >From the Apache docs [2]: "Apache will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested." Ok, I'm lucky in that I control my own server, so I can effectively remove the .htaccess file and move its config options to php.ini and the vhost section of httpd.conf, thus speeding up the responsiveness of my server. But if you don't have that option there's nothing wrong with adding those directives to your directory .htaccess file. That's what it's for - it allows directory specific config options for those that don't have access to their server config. As Kjartan said, "the less PHP settings Drupal messes with the better". I've got to agree - as far as I'm concerned it's already big enough. The "php_value short_open_tag 1", "php_value session.auto_start 0" and "php_value session.cache_limiter none" for example serve little purpose, as they mirror the installation default settings (apart from the last, where the available options are: nocache, private or public). If you don't have the choice, use .htaccess, and add whatever directives you see fit. But please remember that not everyone uses it. Anyway, just my 2 beads. [2] http://httpd.apache.org/docs-2.0/howto/htaccess.html#when ------------------------------------------------------------------------ Tue, 08 Jun 2004 04:38:32 +0000 : cel4145 Why not add them, but commented out with an explanation? When I encountered this problem, I had to spend a little time on drupal.org finding the solution. However, I am familiar with the .htaccess file from doing installs. If it had been included there commented out, I would have probably remembered it. After all, this is much the same way that httpd.conf functions with it's many, optional, commented out configuration options. Just makes it easier when a non-standard configuration option has to be used. Besides, I've also seen many Drupal sites with this problem. I suspect that some of those sites would have implemented these flags if they had been an option in the .htaccess file. And it looks bad. People that visit the sites that don't know any better will assume it's Drupal, not the lack of proper PHP settings. ------------------------------------------------------------------------ Tue, 08 Jun 2004 10:39:27 +0000 : killes(a)www.drop.org It wouldn't hurt if Drupal had a better documented and possibly extended .htaccess file. Those who whish not to use it should really not care... session.save_handler = user should probably included as well. ------------------------------------------------------------------------ Tue, 08 Jun 2004 12:17:06 +0000 : robertDouglass If you use these settings: php_flag session.use_trans_sid off php_flag session.use_only_cookies on won't it make it so that people with cookies disabled cannot have session state? And if the PHPSESSID is in the URL, isn't that an indication that the browser being used refused to take a cookie? I'd really like clarification on this, if anyone knows the answers. ------------------------------------------------------------------------ Tue, 27 Jul 2004 13:25:46 +0000 : JonBob The original issue is definitely by design, as these URLs need the session ID to preserve the session when running under the given PHP settings. A better-documented .htaccess is a different issue entirely. ------------------------------------------------------------------------ Thu, 19 Aug 2004 18:04:13 +0000 : gtoddv It hasn't been mentioned in this thread or anywhere else that I can find, but this session ID issue breaks validation. I don't know is this will cause accessibility issues too. I have tried the .htaccess fix and that doesn't change anything. ------------------------------------------------------------------------ Sat, 06 Nov 2004 07:17:21 +0000 : wazdog The non-validating problem is another problem with your server setup. PHP can be setup to used encoded &'s or not. Your server isn't if the url isn't validating. You'd have to talk to your server admin to fix that. ------------------------------------------------------------------------ Thu, 30 Dec 2004 20:32:35 +0000 : m_freeman2004 This is what you have to include in the .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix ------------------------------------------------------------------------ Wed, 01 Jun 2005 19:07:53 +0000 : dr05 The code in .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix don't work! Error: "Internal Server Error!" ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:25:22 +0000 : jasonwhat Anyone else looking into this? Can one get rid of the id added onto the url but still keep the sessions going? ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:16:22 +0000 : Eric Scouten dr05, what version of Apache and what OS are you using? I've been using this same patch with no problems on Mac OS X, Linux, and FreeBSD-based servers using both Apache 1.3.x and 2.0.x. Attached patch will apply these changes to .htaccess. (IMHO, this is useful for the majority of users; those who are smart enough to understand the performance issues can comment out these lines.) ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:57:18 +0000 : clydefrog You forgot the patch, Eric. ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:02:26 +0000 : Eric Scouten Attachment: http://drupal.org/files/issues/htaccess-no-session-ids.patch (383 bytes) D'oh! ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:45:48 +0000 : kbahey There are cases where no parameter will fix this issue. On shared hosting systems where you do not have access to php.ini, and the hosting company has setup things in a way that they cannot be overriden. I found this out the hard way, after lobbying for the settings to be included in the init_set() statements in the settings.php prior to 4.6 being released. They are simply ignored on some hosts. On other hosts, you need to have a php.ini of your own, if suphp or SuExec is being used. In some cases, the only way to make things work is to compile your own PHP as a CGI (detailed writeup) [3]. This can have disadvantages too, such some performance impact, as well as excessive CPU utilization (hosting company may not like it). [3] http://baheyeldin.com/drupal/how-to-get-rid-of-phpsessid-in-drupal-and-othe… ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:49:31 +0000 : kbahey Here is some references: issue 21170 [4], and a forum discussion [5]. [4] http://drupal.org/node/21170 [5] http://drupal.org/node/17947 ------------------------------------------------------------------------ Sat, 30 Jul 2005 16:24:47 +0000 : ufku in my case (shared hosting, ini_set() disabled) a php.ini file with only this line in it solved the problem. url_rewriter.tags = '' you should place the php.ini in your site's base directory ------------------------------------------------------------------------ Sun, 07 Aug 2005 12:18:31 +0000 : djnz Attachment: http://drupal.org/files/issues/rewrite_tags.patch (468 bytes) Drupal already attempts to change a number of values using ini_set() in settings.php, including session.use_trans_sid which should cure this problem. Unfortunately as already noted elsewhere [6], session.use_trans_sid only worked in ini_set() up to PHP 4.2.3. Rather than change the whole philosophy and change this setting in .htaccess or php.ini (neither of which work for many hosted set-ups), surely the answer is to correct settings.php as described The attached patch does just that - it is only one line. Note that session ids are still appended to the url when redirecting by Drupal eg after a POST. This is also easily patched [7], but as it is done deliberately (why?) I have left it alone. [6] http://drupal.org/node/17947#comment-36339 [7] http://drupal.org/node/25852#comment-45111 ------------------------------------------------------------------------ Sun, 07 Aug 2005 13:26:17 +0000 : kbahey PHPSESSIDs in the URL are a) ugly, b) negatively affects search engine indexing, and most importantly, c) is a security risk that can enable a malicious user to hijack your session. We should work on a solution to eliminate this once and for all, and for all configurations. The current approach (putting some PHP parameters in settings.php, or instructing users to change them in .htaccess or php.ini) has severe shorcomings: Whatever we do, there are bound to be some configurations that no amount of PHP parameters will cure. Some hosts deny their users the ability to change some or all of the above parameters. I discovered this the painful way with many hosts I have used, and friends and clients I have helped. I think we need to rethink this whole session thing, in a way that we are not dependant on idiosyncracies of various hosts and PHP configurations. Perhaps attempt to set a DRUPAL cookie and not maintain a session unless we are able to set it. This way we know that we will not have a PHPSESSID in the URL. If we are not able to set the cookie, then we allow only anonymous access that is sessionless.. I am not sure if that will work or not: what other options do we have here?

1 0

[drupal-devel] [feature] "blog it" link lost in aggregator
by maui1 07 Aug '05

07 Aug '05

Issue status update for http://drupal.org/node/10752 Post a follow up: http://drupal.org/project/comments/add/10752 Project: Drupal -Version: 4.6.0 +Version: 4.6.2 Component: aggregator.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Gunnar Langemark(a)www.langemark.com Updated by: maui1 Status: patch (code needs review) I couldn't agree more. Placing the "Blogit" link in the block is almost worse than not having it. I only decide to blog an item or post it as a story based on reading the description, not from the title alone. Blogit and Post as Story were the two most used features in my Aggregator installation and users are screaming bloddy murder over their dissapearance. Please, Please add these features back to the main distribution and if necessary for some designers, have an admin check box to dissable it. maui1 Previous comments: ------------------------------------------------------------------------ Sun, 12 Sep 2004 07:51:48 +0000 : Gunnar Langemark(a)www.langemark.com I upgraded Langemarks Cafe and noticed that the "blog it" link from aggregator posts is no more. So I did a clean install of cvs - and it is still not there. I use it every day as it is an integrated part of my site maintenance routine. So for me it is critical - even though Drupal runs fine without. Sure hope this is a bug and not something which has been removed. ------------------------------------------------------------------------ Sun, 12 Sep 2004 23:44:20 +0000 : drumm I am on my slow computer and haven't done a full test (subscribe to feeds and confirm it works), but the permisison name recently changed from maintain blog to edit own blog. Make sure you have those all selected properly in admin >> users >> configure >> roles. Setting as a support request for now as I could not find any inconsistencies in the code yet. ------------------------------------------------------------------------ Fri, 18 Feb 2005 02:54:36 +0000 : tatonca Attachment: http://drupal.org/files/issues/aggregator.module_5.patch (1.11 KB) I hope this is the way to do this... There is a thread discussing this issue: http://drupal.org/node/10740 and I think Dries confirms that this was changed by design. I myself liked having the feature, so I added it back in on my site. Patch attached - hope folks find this useful... I thought it might be kewl to make this an option to be turned on or off in the aggregator admin settings - haven't got as far as figuring out how to do that yet ;) when I do I'll post that too... Since this was originally removed by design I've changed the status to feature request. I also tried to find another thread or issue but this seemed to be the only one... ~Tat~ ------------------------------------------------------------------------ Sat, 26 Mar 2005 07:14:04 +0000 : wal >From what I found, you have to be the original admin account to get the "blog it" icon. I even tried making an "admin" role and giving it all the permissions. The only way I see the icon is if I am logged in as the original admin account. Giving all the permissions to the "authenticated user" role didn't seem to be enough. I simply changed the original account to be my username. I know this isn't a real fix but since I am the only person using that specific install it fixes my issue. Good luck, --Bill ------------------------------------------------------------------------ Sat, 09 Apr 2005 17:22:49 +0000 : bloggator This worked for me: In your aggregator.module, replace everything from line 1111 to the end with: $output .= "<div class=\"news-item\">\n"; $output .= ' <div class="date">'. date('H:i', $item->timestamp) ."</div>\n"; $output .= " <div class=\"body\">\n"; $output .= " <div class=\"title\"><a href=\"$item->link\">$item->title</a> "; if ($user->uid && module_exist('blog') && user_access('edit own blog')) { if ($image = theme('image', 'misc/blog.png', t('blog it'), t('blog it'))) { $output .= '<span class="icon">'. l($image, 'node/add/blog', array('title' => t('Comment on this news item in your personal blog.'), 'class' => 'blog-it'), "iid=$item->iid") .'</span>'; $output .="</div>\n"; } } if ($item->description) { $output .= " <div class=\"description\">$item->description</div>\n"; } if ($item->ftitle && $item->fid) { $output .= " <div class=\"description\"> </div>\n"; $output .= ' <div class="source">'. t('Source') .': '. l($item->ftitle, "aggregator/sources/$item->fid") ."</div>\n"; } $result = db_query('SELECT c.title, c.cid FROM {aggregator_category_item} ci LEFT JOIN {aggregator_category} c ON ci.cid = c.cid WHERE ci.iid = %d ORDER BY c.title', $item->iid); $categories = array(); while ($category = db_fetch_object($result)) { $categories[] = l($category->title, 'aggregator/categories/'. $category->cid); } $output .= " </div>\n"; $output .= "</div>\n"; return $output; } ?> Best regards, Jeff ------------------------------------------------------------------------ Tue, 26 Apr 2005 22:58:57 +0000 : maui1 Hi Jeff, I tried your code patch for the aggregator module in 4.6 and it didn't get the blogIt and Post as Story links back. It did seem to slow access to aggregator down, but no links. Where was this design decision made, I would like to contribute my reasons for needing this functionality. ------------------------------------------------------------------------ Tue, 05 Jul 2005 04:11:13 +0000 : johnpg It's missing the $user declaration so it never gets past the "if" statements. Edit the theme_aggregator_page_item function so it looks like this. function theme_aggregator_page_item($item) { static $last; global $user; Then add if ($user->uid && module_exist('blog') && user_access('edit own blog')) { if ($image = theme('image', 'misc/blog.png', t('blog it'), t('blog it'))) { $output .= ''. l($image, 'node/add/blog', array('title' => t('Comment on this news item in your personal blog.'), 'class' => 'blog-it'), "iid=$item->iid", NULL, FALSE, TRUE) .''; } } Directly after this line: $output .= ' '. check_plain($item->title) .\" [1]\n"; This should really be back in the code as standard, very useful. John [1] http://drupal.org/'. check_url($item->link) .' ------------------------------------------------------------------------ Tue, 05 Jul 2005 04:12:50 +0000 : johnpg It's missing the $user declaration so it never gets past the "if" statements. Edit the theme_aggregator_page_item function so it looks like this. function theme_aggregator_page_item($item) { static $last; global $user; Then add if ($user->uid && module_exist('blog') && user_access('edit own blog')) { if ($image = theme('image', 'misc/blog.png', t('blog it'), t('blog it'))) { $output .= '<div class="icon">'. l($image, 'node/add/blog', array('title' => t('Comment on this news item in your personal blog.'), 'class' => 'blog-it'), "iid=$item->iid", NULL, FALSE, TRUE) .'</div>'; } } Directly after this line: $output .= ' <div class="title">'. check_plain($item->title) .\" [2]</div>\n"; This should really be back in the code as standard, very useful. John [2] http://drupal.org/'. check_url($item->link) .' ------------------------------------------------------------------------ Fri, 05 Aug 2005 17:06:24 +0000 : peacearena I get this working but with a strange problem. In the aggregator contents after the title, where the blog.png image should be, the actual code to the image file shows: <img src="misc/blog.png" alt="blog it" title="blog it" /> as a link. Yes the image exists, yes img span and div are allowed in that format. What am I doing wrong? I tried changing the path to the image, making it absolute, putting the image in the theme directory, but then nothing shows at all after the title. I hope someone can help me with this, I'd really like this feature. Using Drupal 4.6.2. Thanks. ------------------------------------------------------------------------ Sat, 06 Aug 2005 08:00:42 +0000 : Boris Mann Why the hell does this keep getting taken out?! Many people use it, it shouldn't be removed. If some developers somewhere don't like it, then add an admin setting to toggle this on or off. It really should be added to both 4.6 and 4.7. ------------------------------------------------------------------------ Sat, 06 Aug 2005 10:27:44 +0000 : Prometheus6 The link exists, but in the blocks created by the aggregator, not the page that displays the actual items. That's a somewhat less useful place.

1 0

[drupal-devel] [ann] flickr_block.module
by Kristjan Jansen 07 Aug '05

07 Aug '05

I contributed a flickr_block.module. Since I am crippled with day job, perhaps somebody wants to move on with this project? Jonas? Screenshot ---------------- http://trip.ee/files/images//flickr_block_demo.png Readme ------------ http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/flick… : Flickrblock is a simple module what generates blocks of Flickr images. It is proof-of-concept and not yet ready for mainstream use (no proper access control and error handling yet) Currently 2 blocks are generated: * 'Related Flickr Images' will show up on taxonomy/term/x pages. In addition for term name, the synonyms are also considered (should also 'related terms' be matched?) The block is useful f.e. travel sites where in each destination page the related images are shown in sidebar, http://www.43places.com and http://technorati.com style * 'My latest Flickr images' shows just stream of latest images added, matching the Flickr ID Fetching the XML is done by Drupal's new excellent xmlrpc() function, it is favoured over REST because of cleaner code (oh please make the 'external l()' patch to the core ;) PHP parsing is done by xml_parse_into_struct() and helper function that converts the struct into a a more usable nested array. The array structure might be too complicated though, looking for suggestions for simplifing the structure Demo -------- http://kika.trip.ee (unstable now, come back later) Todo & Future ------------- * 'See more pictures' link * CC licence link * access control * error handling * caching (should we cache xml, transformed array or images?) * CSS classes * image theme/CSS unification with image.module * introduce configuration * number of images be fetched * move all flickr paths to configuration (they have changed their url schemas already!) * more blocks * blog block (requires separate flick_user_id for each user); * my latest photosets * testing, testing, testing In future, I'd like to see this module integrated to Jonas' flickr.module http://drupal.org/node/14912 after some more integration: * unified naming conventions * unified configuration * unified xml parsing * unified caching k

2 1

[drupal-devel] [bug] $teaser misnamed in themes (theme_node)
by robertDouglass 07 Aug '05

07 Aug '05

Issue status update for http://drupal.org/node/26637 Post a follow up: http://drupal.org/project/comments/add/26637 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: robertDouglass Updated by: robertDouglass Status: patch Attachment: http://drupal.org/files/issues/main_teaser.patch.txt (3.1 KB) The documentation to theme_node clearly says the the parameter $teaser is "Whether to display the teaser only, as on the main page." Naming this parameter $main in the themes is confusing. Main is used elsewhere to mean "whether to show full view or teaser view", but the meaning of $teaser seems to be subtly different. An alternate to the patch I'm suggesting would be to eliminate $teaser altogether, system-wide. The variable $main makes it clear that it is transmitting state (whether or not on the node's main page), whereas the variable $teaser makes on think it is transmitting the actual teaser. robertDouglass

4 6

[drupal-devel] [feature] Comment module does not support extension of its forms
by koorneef 07 Aug '05

07 Aug '05

Issue status update for http://drupal.org/node/14708 Post a follow up: http://drupal.org/project/comments/add/14708 Project: Drupal -Version: 4.6.0 +Version: cvs Component: comment.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: koorneef -Status: duplicate +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/comment.module_10_0.patch (1.02 KB) Attached patch is for CVS (post 4.6.2, dd: 2005-08-07). Please check the patch for errors. It works on my test site but one never knows .... koorneef Previous comments: ------------------------------------------------------------------------ Wed, 22 Dec 2004 23:20:44 +0000 : tangent The comment module currently does not support 3rd party modules being able to add form elements or form validation. This is important for the captcha module to be able to add an extra form item. ------------------------------------------------------------------------ Wed, 22 Dec 2004 23:22:07 +0000 : tangent Attachment: http://drupal.org/files/issues/comment.form.patch (824 bytes) Here is a patch. ------------------------------------------------------------------------ Thu, 23 Dec 2004 11:54:00 +0000 : Anonymous Haven't tested it, but it seems identical to the changes I'd made for my experiments. +1 for this. This is important to have if people want captchas on comments. Other modules that I think can benefit by this: Ratings (rate the post along with commenting on it). ------------------------------------------------------------------------ Thu, 23 Dec 2004 12:15:44 +0000 : moshe weitzman this is a good direction for hook_comment(). for consistency with nodeapi, i propose splitting into 'form pre' and 'form post' operations and also adding a 'view' operation. ------------------------------------------------------------------------ Thu, 23 Dec 2004 14:37:56 +0000 : tangent I agree with the commentapi thing (however it is named or done) for several reasons. In the short term though, in order to use a captcha module immediately, it wouldn't hurt to update the existing code to support the purpose since I suspect the aforementioned redesign will not happen overnight. ------------------------------------------------------------------------ Fri, 24 Dec 2004 06:48:13 +0000 : TDobes There's a similar discussion going on in another issue [1]... one of these should be marked as a duplicate. [1] http://drupal.org/node/13539 ------------------------------------------------------------------------ Fri, 24 Dec 2004 11:51:35 +0000 : stefan nagtegaal Just not to forget: If such a patch like this makes it into core it would be nice to strip down the comment.module untill it is a real api. Removing the comment moderation part into an cmoderation.module would be a good thingtm. This way we make drupal more flexible and light weight... ------------------------------------------------------------------------ Sat, 22 Jan 2005 09:41:25 +0000 : stefan nagtegaal Duplicate of http://drupal.org/node/13539.. ------------------------------------------------------------------------ Sat, 02 Apr 2005 13:59:32 +0000 : escoles I'm not clear on how to apply this patch. The name of the file is "comment.form", not "comment.module"; is that simply an error? Or should I be able to find a resource somewhere with the filename "comment.form"? Related question: If I operate on the assumption that the filename should be "comment.module" and try to run patch, I get the error message "Only garbage was found in the patch input." Does anybody know what that would mean? ------------------------------------------------------------------------ Mon, 04 Apr 2005 12:13:11 +0000 : jotarp(a)www.jotarp.org Attachment: http://drupal.org/files/issues/comment.module_7.patch (674 bytes) Try this. ------------------------------------------------------------------------ Wed, 20 Apr 2005 14:19:54 +0000 : jgoerzen(a)changelog.complete.org I'm running Drupal 4.6.0 with the attached patch 7. It has been causing me all sorts of weird session troubles [2]. Reversing the patch makes the troubles go away. Something is really awry here... [2] http://lists.drupal.org/archives/drupal-support/2005-04/msg00061.html ------------------------------------------------------------------------ Sun, 12 Jun 2005 11:49:52 +0000 : varunvnair Is comment.module_7.patch still causing problems, esp with Drupal 4.6.1? Just wanted to know because I wanted to enable captchas for anon users and was thinking of applying this patch. ------------------------------------------------------------------------ Mon, 18 Jul 2005 11:27:01 +0000 : Hanu Attachment: http://drupal.org/files/issues/comment.module_9.patch (698 bytes) This patch works for me and my 4.6.2 installation. ------------------------------------------------------------------------ Wed, 03 Aug 2005 23:54:43 +0000 : Eaton That above patch (v 9) Works for me on 4.6.2 as well. I'm using it in a new custom module to impose length limits on comments, very very useful.

1 0

[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them
by kbahey 07 Aug '05

07 Aug '05

Issue status update for http://drupal.org/node/4109 Post a follow up: http://drupal.org/project/comments/add/4109 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Eric Scouten Reported by: Eric Scouten Updated by: kbahey Status: patch (code needs review) PHPSESSIDs in the URL are a) ugly, b) negatively affects search engine indexing, and most importantly, c) is a security risk that can enable a malicious user to hijack your session. We should work on a solution to eliminate this once and for all, and for all configurations. The current approach (putting some PHP parameters in settings.php, or instructing users to change them in .htaccess or php.ini) has severe shorcomings: Whatever we do, there are bound to be some configurations that no amount of PHP parameters will cure. Some hosts deny their users the ability to change some or all of the above parameters. I discovered this the painful way with many hosts I have used, and friends and clients I have helped. I think we need to rethink this whole session thing, in a way that we are not dependant on idiosyncracies of various hosts and PHP configurations. Perhaps attempt to set a DRUPAL cookie and not maintain a session unless we are able to set it. This way we know that we will not have a PHPSESSID in the URL. If we are not able to set the cookie, then we allow only anonymous access that is sessionless.. I am not sure if that will work or not: what other options do we have here? kbahey Previous comments: ------------------------------------------------------------------------ Thu, 13 Nov 2003 00:22:39 +0000 : Eric Scouten Some URLs get ?PHPSESSID=(whatever) added to them. I find this distracting and unnecessary for anonymous users. Submitting patch #147 for consideration to remove this issue. ------------------------------------------------------------------------ Fri, 05 Dec 2003 14:39:25 +0000 : Kjartan This is a local PHP configuration issue. Don't see it as something Drupal should mess with, the less PHP settings Drupal messes with the better. ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:11:33 +0000 : killes(a)www.drop.org Could you elaborate which config setting one has to tweak? ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:18:11 +0000 : Anonymous php_flag session.use_trans_sid off php_flag session.use_only_cookies on The first will disable the automatic addition of the session ID to internal URLs, the second will remove support for passing session IDs in URLs. See http://php.net/session [1] for more info. BTW the above settings are for Apache, in PHP.ini you should not add the php_flag part, and you should use = inbetween the name and value... [1] http://php.net/session ------------------------------------------------------------------------ Mon, 07 Jun 2004 22:42:06 +0000 : shane It seems that Drupal (via the .htaccess file) already "messes with" a bunch of PHP settings. For example, my Drupal install "came with" these messed with settings: php_value register_globals 0 php_value track_vars 1 php_value short_open_tag 1 php_value magic_quotes_gpc 0 php_value magic_quotes_runtime 0 php_value magic_quotes_sybase 0 php_value arg_separator.output "&" php_value session.cache_expire 200000 php_value session.gc_maxlifetime 200000 php_value session.cookie_lifetime 2000000 php_value session.auto_start 0 php_value session.save_handler user php_value session.cache_limiter none php_value allow_call_time_pass_reference On I'm not sure that adding two more "php_value" flags to the stock .htaccess file is going to arguably mess with more than already is. Personally I find it extremely un-professional and very un-clean to have funky PHPSESSID url strings tacked onto a majority of my URLs. I've worked extremely hard to implement clean URLs (above and beyond the already great "clean url" feature of Drupal - I don't like them being turned into muck. I'd vote that these two flags be added to the .htaccess file that is distributed with Drupal. However, I'm uncertain of the overall true impact of making these changes, so barring an technical reason - I would absolutely request this as a feature. I've implemented these in many of my production sites already (just today) - we'll see what impact they have. ------------------------------------------------------------------------ Tue, 08 Jun 2004 02:56:00 +0000 : marky It's a performance thing. You need to remember that while not everyone has edit access to php.ini, those of us that do control our own servers see no need for .htaccess directives that set php options. >From the Apache docs [2]: "Apache will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested." Ok, I'm lucky in that I control my own server, so I can effectively remove the .htaccess file and move its config options to php.ini and the vhost section of httpd.conf, thus speeding up the responsiveness of my server. But if you don't have that option there's nothing wrong with adding those directives to your directory .htaccess file. That's what it's for - it allows directory specific config options for those that don't have access to their server config. As Kjartan said, "the less PHP settings Drupal messes with the better". I've got to agree - as far as I'm concerned it's already big enough. The "php_value short_open_tag 1", "php_value session.auto_start 0" and "php_value session.cache_limiter none" for example serve little purpose, as they mirror the installation default settings (apart from the last, where the available options are: nocache, private or public). If you don't have the choice, use .htaccess, and add whatever directives you see fit. But please remember that not everyone uses it. Anyway, just my 2 beads. [2] http://httpd.apache.org/docs-2.0/howto/htaccess.html#when ------------------------------------------------------------------------ Tue, 08 Jun 2004 04:38:32 +0000 : cel4145 Why not add them, but commented out with an explanation? When I encountered this problem, I had to spend a little time on drupal.org finding the solution. However, I am familiar with the .htaccess file from doing installs. If it had been included there commented out, I would have probably remembered it. After all, this is much the same way that httpd.conf functions with it's many, optional, commented out configuration options. Just makes it easier when a non-standard configuration option has to be used. Besides, I've also seen many Drupal sites with this problem. I suspect that some of those sites would have implemented these flags if they had been an option in the .htaccess file. And it looks bad. People that visit the sites that don't know any better will assume it's Drupal, not the lack of proper PHP settings. ------------------------------------------------------------------------ Tue, 08 Jun 2004 10:39:27 +0000 : killes(a)www.drop.org It wouldn't hurt if Drupal had a better documented and possibly extended .htaccess file. Those who whish not to use it should really not care... session.save_handler = user should probably included as well. ------------------------------------------------------------------------ Tue, 08 Jun 2004 12:17:06 +0000 : robertDouglass If you use these settings: php_flag session.use_trans_sid off php_flag session.use_only_cookies on won't it make it so that people with cookies disabled cannot have session state? And if the PHPSESSID is in the URL, isn't that an indication that the browser being used refused to take a cookie? I'd really like clarification on this, if anyone knows the answers. ------------------------------------------------------------------------ Tue, 27 Jul 2004 13:25:46 +0000 : JonBob The original issue is definitely by design, as these URLs need the session ID to preserve the session when running under the given PHP settings. A better-documented .htaccess is a different issue entirely. ------------------------------------------------------------------------ Thu, 19 Aug 2004 18:04:13 +0000 : gtoddv It hasn't been mentioned in this thread or anywhere else that I can find, but this session ID issue breaks validation. I don't know is this will cause accessibility issues too. I have tried the .htaccess fix and that doesn't change anything. ------------------------------------------------------------------------ Sat, 06 Nov 2004 07:17:21 +0000 : wazdog The non-validating problem is another problem with your server setup. PHP can be setup to used encoded &'s or not. Your server isn't if the url isn't validating. You'd have to talk to your server admin to fix that. ------------------------------------------------------------------------ Thu, 30 Dec 2004 20:32:35 +0000 : m_freeman2004 This is what you have to include in the .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix ------------------------------------------------------------------------ Wed, 01 Jun 2005 19:07:53 +0000 : dr05 The code in .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix don't work! Error: "Internal Server Error!" ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:25:22 +0000 : jasonwhat Anyone else looking into this? Can one get rid of the id added onto the url but still keep the sessions going? ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:16:22 +0000 : Eric Scouten dr05, what version of Apache and what OS are you using? I've been using this same patch with no problems on Mac OS X, Linux, and FreeBSD-based servers using both Apache 1.3.x and 2.0.x. Attached patch will apply these changes to .htaccess. (IMHO, this is useful for the majority of users; those who are smart enough to understand the performance issues can comment out these lines.) ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:57:18 +0000 : clydefrog You forgot the patch, Eric. ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:02:26 +0000 : Eric Scouten Attachment: http://drupal.org/files/issues/htaccess-no-session-ids.patch (383 bytes) D'oh! ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:45:48 +0000 : kbahey There are cases where no parameter will fix this issue. On shared hosting systems where you do not have access to php.ini, and the hosting company has setup things in a way that they cannot be overriden. I found this out the hard way, after lobbying for the settings to be included in the init_set() statements in the settings.php prior to 4.6 being released. They are simply ignored on some hosts. On other hosts, you need to have a php.ini of your own, if suphp or SuExec is being used. In some cases, the only way to make things work is to compile your own PHP as a CGI (detailed writeup) [3]. This can have disadvantages too, such some performance impact, as well as excessive CPU utilization (hosting company may not like it). [3] http://baheyeldin.com/drupal/how-to-get-rid-of-phpsessid-in-drupal-and-othe… ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:49:31 +0000 : kbahey Here is some references: issue 21170 [4], and a forum discussion [5]. [4] http://drupal.org/node/21170 [5] http://drupal.org/node/17947 ------------------------------------------------------------------------ Sat, 30 Jul 2005 16:24:47 +0000 : ufku in my case (shared hosting, ini_set() disabled) a php.ini file with only this line in it solved the problem. url_rewriter.tags = '' you should place the php.ini in your site's base directory ------------------------------------------------------------------------ Sun, 07 Aug 2005 12:18:31 +0000 : djnz Attachment: http://drupal.org/files/issues/rewrite_tags.patch (468 bytes) Drupal already attempts to change a number of values using ini_set() in settings.php, including session.use_trans_sid which should cure this problem. Unfortunately as already noted elsewhere [6], session.use_trans_sid only worked in ini_set() up to PHP 4.2.3. Rather than change the whole philosophy and change this setting in .htaccess or php.ini (neither of which work for many hosted set-ups), surely the answer is to correct settings.php as described The attached patch does just that - it is only one line. Note that session ids are still appended to the url when redirecting by Drupal eg after a POST. This is also easily patched [7], but as it is done deliberately (why?) I have left it alone. [6] http://drupal.org/node/17947#comment-36339 [7] http://drupal.org/node/25852#comment-45111

1 0

[drupal-devel] [feature] re-assign all nodes from deleted users to anonymous.
by kubaZygmunt 07 Aug '05

07 Aug '05

Issue status update for http://drupal.org/node/28345 Post a follow up: http://drupal.org/project/comments/add/28345 Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: kubaZygmunt Updated by: kubaZygmunt Status: patch (code needs review) Attachment: http://drupal.org/files/issues/node_delete_user.txt (667 bytes) I've added node_user hook, to re-assign all content from deleted users to anonymous during deleting. kubaZygmunt

7 8

[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them
by djnz 07 Aug '05

07 Aug '05

Issue status update for http://drupal.org/node/4109 Post a follow up: http://drupal.org/project/comments/add/4109 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Eric Scouten Reported by: Eric Scouten Updated by: djnz Status: patch (code needs review) Attachment: http://drupal.org/files/issues/rewrite_tags.patch (468 bytes) Drupal already attempts to change a number of values using ini_set() in settings.php, including session.use_trans_sid which should cure this problem. Unfortunately as already noted elsewhere [1], session.use_trans_sid only worked in ini_set() up to PHP 4.2.3. Rather than change the whole philosophy and change this setting in .htaccess or php.ini (neither of which work for many hosted set-ups), surely the answer is to correct settings.php as described The attached patch does just that - it is only one line. Note that session ids are still appended to the url when redirecting by Drupal eg after a POST. This is also easily patched [2], but as it is done deliberately (why?) I have left it alone. [1] http://drupal.org/node/17947#comment-36339 [2] http://drupal.org/node/25852#comment-45111 djnz Previous comments: ------------------------------------------------------------------------ Thu, 13 Nov 2003 00:22:39 +0000 : Eric Scouten Some URLs get ?PHPSESSID=(whatever) added to them. I find this distracting and unnecessary for anonymous users. Submitting patch #147 for consideration to remove this issue. ------------------------------------------------------------------------ Fri, 05 Dec 2003 14:39:25 +0000 : Kjartan This is a local PHP configuration issue. Don't see it as something Drupal should mess with, the less PHP settings Drupal messes with the better. ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:11:33 +0000 : killes(a)www.drop.org Could you elaborate which config setting one has to tweak? ------------------------------------------------------------------------ Fri, 05 Dec 2003 15:18:11 +0000 : Anonymous php_flag session.use_trans_sid off php_flag session.use_only_cookies on The first will disable the automatic addition of the session ID to internal URLs, the second will remove support for passing session IDs in URLs. See http://php.net/session [3] for more info. BTW the above settings are for Apache, in PHP.ini you should not add the php_flag part, and you should use = inbetween the name and value... [3] http://php.net/session ------------------------------------------------------------------------ Mon, 07 Jun 2004 22:42:06 +0000 : shane It seems that Drupal (via the .htaccess file) already "messes with" a bunch of PHP settings. For example, my Drupal install "came with" these messed with settings: php_value register_globals 0 php_value track_vars 1 php_value short_open_tag 1 php_value magic_quotes_gpc 0 php_value magic_quotes_runtime 0 php_value magic_quotes_sybase 0 php_value arg_separator.output "&" php_value session.cache_expire 200000 php_value session.gc_maxlifetime 200000 php_value session.cookie_lifetime 2000000 php_value session.auto_start 0 php_value session.save_handler user php_value session.cache_limiter none php_value allow_call_time_pass_reference On I'm not sure that adding two more "php_value" flags to the stock .htaccess file is going to arguably mess with more than already is. Personally I find it extremely un-professional and very un-clean to have funky PHPSESSID url strings tacked onto a majority of my URLs. I've worked extremely hard to implement clean URLs (above and beyond the already great "clean url" feature of Drupal - I don't like them being turned into muck. I'd vote that these two flags be added to the .htaccess file that is distributed with Drupal. However, I'm uncertain of the overall true impact of making these changes, so barring an technical reason - I would absolutely request this as a feature. I've implemented these in many of my production sites already (just today) - we'll see what impact they have. ------------------------------------------------------------------------ Tue, 08 Jun 2004 02:56:00 +0000 : marky It's a performance thing. You need to remember that while not everyone has edit access to php.ini, those of us that do control our own servers see no need for .htaccess directives that set php options. >From the Apache docs [4]: "Apache will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested." Ok, I'm lucky in that I control my own server, so I can effectively remove the .htaccess file and move its config options to php.ini and the vhost section of httpd.conf, thus speeding up the responsiveness of my server. But if you don't have that option there's nothing wrong with adding those directives to your directory .htaccess file. That's what it's for - it allows directory specific config options for those that don't have access to their server config. As Kjartan said, "the less PHP settings Drupal messes with the better". I've got to agree - as far as I'm concerned it's already big enough. The "php_value short_open_tag 1", "php_value session.auto_start 0" and "php_value session.cache_limiter none" for example serve little purpose, as they mirror the installation default settings (apart from the last, where the available options are: nocache, private or public). If you don't have the choice, use .htaccess, and add whatever directives you see fit. But please remember that not everyone uses it. Anyway, just my 2 beads. [4] http://httpd.apache.org/docs-2.0/howto/htaccess.html#when ------------------------------------------------------------------------ Tue, 08 Jun 2004 04:38:32 +0000 : cel4145 Why not add them, but commented out with an explanation? When I encountered this problem, I had to spend a little time on drupal.org finding the solution. However, I am familiar with the .htaccess file from doing installs. If it had been included there commented out, I would have probably remembered it. After all, this is much the same way that httpd.conf functions with it's many, optional, commented out configuration options. Just makes it easier when a non-standard configuration option has to be used. Besides, I've also seen many Drupal sites with this problem. I suspect that some of those sites would have implemented these flags if they had been an option in the .htaccess file. And it looks bad. People that visit the sites that don't know any better will assume it's Drupal, not the lack of proper PHP settings. ------------------------------------------------------------------------ Tue, 08 Jun 2004 10:39:27 +0000 : killes(a)www.drop.org It wouldn't hurt if Drupal had a better documented and possibly extended .htaccess file. Those who whish not to use it should really not care... session.save_handler = user should probably included as well. ------------------------------------------------------------------------ Tue, 08 Jun 2004 12:17:06 +0000 : robertDouglass If you use these settings: php_flag session.use_trans_sid off php_flag session.use_only_cookies on won't it make it so that people with cookies disabled cannot have session state? And if the PHPSESSID is in the URL, isn't that an indication that the browser being used refused to take a cookie? I'd really like clarification on this, if anyone knows the answers. ------------------------------------------------------------------------ Tue, 27 Jul 2004 13:25:46 +0000 : JonBob The original issue is definitely by design, as these URLs need the session ID to preserve the session when running under the given PHP settings. A better-documented .htaccess is a different issue entirely. ------------------------------------------------------------------------ Thu, 19 Aug 2004 18:04:13 +0000 : gtoddv It hasn't been mentioned in this thread or anywhere else that I can find, but this session ID issue breaks validation. I don't know is this will cause accessibility issues too. I have tried the .htaccess fix and that doesn't change anything. ------------------------------------------------------------------------ Sat, 06 Nov 2004 07:17:21 +0000 : wazdog The non-validating problem is another problem with your server setup. PHP can be setup to used encoded &'s or not. Your server isn't if the url isn't validating. You'd have to talk to your server admin to fix that. ------------------------------------------------------------------------ Thu, 30 Dec 2004 20:32:35 +0000 : m_freeman2004 This is what you have to include in the .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix ------------------------------------------------------------------------ Wed, 01 Jun 2005 19:07:53 +0000 : dr05 The code in .htaccess file: # Fix for ?PHPSESSID in clean URLs php_value session.use_trans_sid 0 php_value session.use_only_cookies 1 # End of fix don't work! Error: "Internal Server Error!" ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:25:22 +0000 : jasonwhat Anyone else looking into this? Can one get rid of the id added onto the url but still keep the sessions going? ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:16:22 +0000 : Eric Scouten dr05, what version of Apache and what OS are you using? I've been using this same patch with no problems on Mac OS X, Linux, and FreeBSD-based servers using both Apache 1.3.x and 2.0.x. Attached patch will apply these changes to .htaccess. (IMHO, this is useful for the majority of users; those who are smart enough to understand the performance issues can comment out these lines.) ------------------------------------------------------------------------ Mon, 25 Jul 2005 06:57:18 +0000 : clydefrog You forgot the patch, Eric. ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:02:26 +0000 : Eric Scouten Attachment: http://drupal.org/files/issues/htaccess-no-session-ids.patch (383 bytes) D'oh! ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:45:48 +0000 : kbahey There are cases where no parameter will fix this issue. On shared hosting systems where you do not have access to php.ini, and the hosting company has setup things in a way that they cannot be overriden. I found this out the hard way, after lobbying for the settings to be included in the init_set() statements in the settings.php prior to 4.6 being released. They are simply ignored on some hosts. On other hosts, you need to have a php.ini of your own, if suphp or SuExec is being used. In some cases, the only way to make things work is to compile your own PHP as a CGI (detailed writeup) [5]. This can have disadvantages too, such some performance impact, as well as excessive CPU utilization (hosting company may not like it). [5] http://baheyeldin.com/drupal/how-to-get-rid-of-phpsessid-in-drupal-and-othe… ------------------------------------------------------------------------ Mon, 25 Jul 2005 08:49:31 +0000 : kbahey Here is some references: issue 21170 [6], and a forum discussion [7]. [6] http://drupal.org/node/21170 [7] http://drupal.org/node/17947 ------------------------------------------------------------------------ Sat, 30 Jul 2005 16:24:47 +0000 : ufku in my case (shared hosting, ini_set() disabled) a php.ini file with only this line in it solved the problem. url_rewriter.tags = '' you should place the php.ini in your site's base directory

1 0