- Development - lists.drupal.org

[drupal-devel] [bug] patch: allow url_alias paths to have arguments
by jhenry 25 Jul '05

25 Jul '05

Issue status update for http://drupal.org/node/27206 Post a follow up: http://drupal.org/project/comments/add/27206 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: normal Assigned to: jhenry Reported by: jhenry Updated by: jhenry Status: patch Currently, urls that use the url_alias table do not allow arguments. This is not desirable because it is useful to be able to specify arguments on a script that is aliased without having to refer to it by node number. The code below replaces the drupal_get_normal_path() function in common.inc to allow aliased paths to have arguments. /** * Given a path alias, return the internal path it represents. */ function drupal_get_normal_path($path) { if (($map = drupal_get_path_map()) && isset($map[$path])) { return $map[$path]; } elseif (function_exists('conf_url_rewrite')) { return conf_url_rewrite($path, 'incoming'); } else { //look at each of the path components of $path and allow extra components to be arguments //do a greedy search first for the largest paths if ($map && (strpos($path, '/') !== false)) { $newpath = clone($path); $args = ''; while($path_end = strrpos($newpath, '/')) { $args = substr($newpath, $path_end).$args; $newpath = substr($newpath, 0, $path_end); //check to see if this new path exists in the path map if(isset($map[$newpath])) { return $map[$newpath].$args; } } } //no alias was found, return the original path return $path; } } jhenry

2 1

[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them
by Eric Scouten 25 Jul '05

25 Jul '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: Eric Scouten Status: patch Attachment: http://drupal.org/files/issues/htaccess-no-session-ids.patch (383 bytes) D'oh! Eric Scouten 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.

1 0

[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them
by clydefrog 25 Jul '05

25 Jul '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: clydefrog Status: patch You forgot the patch, Eric. clydefrog 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.)

1 0

[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them
by Eric Scouten 25 Jul '05

25 Jul '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: Anonymous +Assigned to: Eric Scouten Reported by: Eric Scouten Updated by: Eric Scouten -Status: by design +Status: patch 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.) Eric Scouten 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?

1 0

[drupal-devel] mod auth mysql
by Bèr Kessels 25 Jul '05

25 Jul '05

Hello, For a more advanced webdav/svn system I am looking at a very simple mod_auth_mysql configuration, or even a mod_auth_mysql.module that module would include a permission "has apache access" or so. then the mod_auth_mysql will use such a scheme that it includes only Drupal users with that permission. But before we are that far, I need to know how to get mod_auth_mysql to atuhtenticate against the druapl DB. So, did anyone ever try this? What are the .conf files for that, and what else do I need to look at? Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

4 5

[drupal-devel] [feature] add inline functionaliy to uploads
by Steven 25 Jul '05

25 Jul '05

Issue status update for http://drupal.org/node/26288 Post a follow up: http://drupal.org/project/comments/add/26288 Project: Drupal Version: cvs Component: upload.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Steven Status: patch Overall I like the concept, but I think it at least needs some default styling to make the image appear okay, like floating it. Right now it appears inline between whatever was there... very ugly. Sure you can say "leave it up to the themer" but if the goal is to provide a simple default, we can't expect people to dive into theming if they are going to use this feature instead of img_assist or whatever. Also, I wonder about the classes "upload" and "image". Is there a reason to use two classes? Isn't "image" a bit too generic? Oh and there is a missing XHTML / for the img tag. Steven Previous comments: ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:03:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline.patch (19.05 KB) One of the most often asked features is proper inlnie handling of files. Look at the amount of solutions, the popularity of image_assist, and the amount of peolpe dowloading image.module! That alone should be enough proof that Drupal lacks proper inline image support. This patch adds that to core. In fact, it does little more then appending a link of img tag to the body or the teaser. Off course that is configurable per file. Next to the [] list checkbox, this patch adds an [] inline checkbox. Simplicity is the foundation of this patch. I want no stles for inline editing, no fancy html wrappers, no tokens, just $node->body or teaser appended with a small html string. Another small themable funtion is introduced, (hey, you cannot expect me to develop something without adding more power for themers, now, can you? ;) ), that allows people to theme the string that is appended to the body or the teaser. Oh, and also note hat the biggest part of this patch is some cleaning I had to do in order to be able to develop properly. I dont like Ifs inside cases in foreaches inside swiches. in other words: nodeapi now calls functions instead of executing code directly. ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:25 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot.png (26.68 KB) here is how the form now looks ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:58 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot3.png (30.53 KB) and this is an example of inlined images and a .doc file. ------------------------------------------------------------------------ Sun, 03 Jul 2005 20:44:00 +0000 : sepeck changing to patch per request from berkes ------------------------------------------------------------------------ Tue, 05 Jul 2005 07:46:13 +0000 : Kobus This gets a +1 from me in principle, however, the [inline:xx] tag with inline.module gives you greater freedom as to where the inline image must be displayed. If you can add this functionality (I haven't checked the code, I don't know if it is in there) it would be a great addition for Core. This same strategy can be used for inline blocks, I am sure. Regards, Kobus ------------------------------------------------------------------------ Tue, 05 Jul 2005 08:57:50 +0000 : Bèr Kessels there are a couple of reasons why i did not include the [inline] tags. * I aimed for extreme simplicity: a checkbox shows an image inline: its up to the theme where it appears (if one does not like it before/above the body and teaser.). Simplicity was the main goal. * We don't have any tokens in core. And we should not have them. * Tokens are a very bad substitute for a good interface. They give less power then plain HTLM. Are much worst documented then HTML, but in the mean time, they are still as hard to learn as HTML. (Yes, I know people _think_ they are easier, but there _is_ not difference between [ ] and , only that its a different ascii char. So, no. I don't allow any placement of the image. I leave that that for dedicated modules, or the themer to decide. ------------------------------------------------------------------------ Tue, 05 Jul 2005 09:34:06 +0000 : Kobus So you will provide an API to do this? For example, with perhaps minor modifications, the inline.module will be able to display these files? In that case I am happy. If not, then I can't give my support to this patch (as if that matters...). A themer can't do this task as inline images (and blocks for that matter) is too dynamic for theming; it can be placed anywhere in a node where the user pleases. This means for me that there should be a module for this, such as inline module that allows you to define [inline:xx] tags. If your module emits an array of uploaded files (such as upload.module), inline.module can be, with minor changes, adapted to show these files inline. To show you what I mean with the content is too dynamic for a themer to perform this task, look at this screenshot related to inline blocks (inline images can follow the same pattern): http://drupal.org/files/issues/regions---possibility-3.png ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:26:15 +0000 : Bèr Kessels Kobus, We are dealing with different issues here: You want a method to place images, files or so anywhere in the post. That is fine, but certainly NOT addressed in the patch! I made patch that *only* adds marked files to the body. its really nothing more then <?php $node->body = $filestring . $node->body ?> No APIS, no, dynamic tokens, no filters, nothing. However, what I meant with themers, is that there now is a theme_upload_inline available, so you can theme the abovementioned $filestring. On top of that $node->files[FILEID]->inline is TRUE if a file is flagged for inline. So in node.tpl.php, or wherever you want to theme a node, you can print nice images inline, when that flag is set. And about the comment that a themer cant do this: Simply not true. On most sites images are always placed in the same places. REally, even the sites see which use img_assist or inline, use them to place the images on the exact same places in every node. People /think/ they want the power to place images anywhere, but they hardly ever use that power. Just look at all the big news/publishing sites out there (BBC, CNN, BoigBoing, r even freshmeat) images are all placed acc. to the theme. They are not placed in random places by authors. So if you are one of the few that still want that power, there aer mots of power tools like inline module or img_assist. We should offer a good default, one that is simple. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:41:34 +0000 : Gerhard Killesreiter I fully agree that tags are evil. Kobus: You can always look for tags in $node->body in your theme's node function. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:50:52 +0000 : stefan nagtegaal Ber, the theme-function in your code looks like: <?php +/** + * Theme function for rendering of inline images + * @param $file a file object. + * @param $image a Boolean, indicating whether an img tag (TRUE) or an anchor tag (FALSE) should be used. + * @ingroup themable + */ +function theme_upload_inline($file, $image) { + if ($image) { + return '<img src="'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'" alt="'. check_plain($file->filename) .'" class="upload inline">'; + } + else { + return ''. check_plain($file->filename) .' [1]'; + } + +} ?> After looking at your code it's not clear to me when $image is TRUE or FALSE, can you elaborate on me please? [1] http://drupal.org/'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'\" class=\"upload inline ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:06:39 +0000 : Bèr Kessels The function calling the theme function should decide whether its an image. IMO that is far too hardcore code for a themer ;) <?php $image = ereg('^(image/)', $file->filemime); ?> inside _upload_inline() does the trick. I did find one issue, though, with svgs, which are image/svg so maybe we should limit this to really only inline jpg, png, and gif, by extension? But I am no fan of determining files by extension, and IMO getimgsize is too heavy; ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:13:52 +0000 : stefan nagtegaal Can't you make use of PHP's <?php image_type_to_mime_type(); ?> or <?php image_type_to_extension(); ?> ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:45:43 +0000 : Kobus Well, if not in the patch, I need inline functionality one way or another. inline.module works perfectly with the current upload.module to fulfill my needs, and if there is a way where someone can extend your proposed upload.module, that would get my +1, otherwise I will just remain neutral about this issue. inline.module makes use of $node->files and displays that image. If your patch still uses $node->files, then this is a non-issue. In other words, if I can, with inline.module, or with minor modifications to inline.module still show files inline, I am +1 for this. As for the themability question... I still disagree. You say "Simply not true. On most sites images are always placed in the same places." That is ONLY true because they have NO alternatives. Means the content is in the same places, because they have no other places to put them. I have made tens of static sites where the content does not resemble a fixed pattern or structure. For me, free-flow layout is my expression of my creativity. This is why I still even BOTHER with static sites; when Drupal don't do what I want it to do. If Drupal could do inline display of content properly, I'd never even build another static site. It is a great mistake people make (including myself), and that is they design the site before ANY content is available, and this happens a lot in static sites. But in dynamic sites, you have far less control over this, unless you have a VERY clean structure with limited information that can be added, and only a few people posting content. If you can have your content before you start the design, you will have a better fit. I can't see how you can anticipate every possible posting posted on your site if you have a diversity of users. Especially not if you're using a site such as an designer's showcase site where your creativity is shown by your web sites. Possible, but not easy. If I claim that I have "unique, fresh designs" I can certainly NOT give them a "box-like" site with "left and right side bars only". That's why I need inline content, this includes images AND boxes. Gerhard: Your concern about tags is answered as well above, if I am not mistaken. The patch need not provide the tags, but should provide for someone to develop a module that provide the filters or tags. To summarize: I don't need your patch to do the inline images. I just need your patch to be able to allow someone else to develop a module that can display inline files. Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 09:56:38 +0000 : Bèr Kessels okay, so for all clarity, let me sumarise: * this patch introduces a chackbox "inline". If checked, the file will show up inline. IT will be appended to the teaser and the body. * this patch does *not* allow one to place images of files in a userdefined place in the body. * this patch does *not* do any resizing nor any thumbnailing. * This patch is meant to be simple, clear and transparant. No tokens, no javascript, no nothing. ------------------------------------------------------------------------ Mon, 18 Jul 2005 11:21:54 +0000 : Kobus Then I can't see how this patch could replace the existing upload.module, which allows you to use inline.module to place images inline. I therefore withdraw my +1 and go -1 on this (not that it matters, I believe). I think you didn't properly read my previous message. I said I don't need your patch to do all this, but I can't live without the functionality currently provided by the upload.module and inline.module combination. I agree that your patch don't need to have that functionality, but if your patch takes away this functionality, in other words, I can't (by hook or by crook) manage what I need to do, my vote is -1. Regards, Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:58:34 +0000 : Bèr Kessels Kobus, And all the others looking fofr advanced inline systems: please do not -1 this. It will hep inline module a lot too. allthough not yet in this patch, but can you imagine a perission system for inline module, that comes for free? Or a core system, that makes inline module ten times smaller? it is this path! so, please, if it is not /exactly/ what you are looking for, at least look at the advantages for Joe Average, and even for the possibilties for your favorite inline-module. even imag_assist will gain an anomous usability impcact when usiong this module, for it can then finally use the upload module in full scale. Ber ------------------------------------------------------------------------ Sat, 23 Jul 2005 18:59:10 +0000 : Bèr Kessels Sohodjo jim: " I hope it matters. A big -1 on enforcing over-simplification at the expense of important and existing functionality. If automatic, uncontrollable placement of images becomes the standard, it will mean fewer not more image-rich Drupal sites as site owners/developers get complaints about "Why can't I control my images!" I _strongly_ encourage Ber to provide a "have it both ways" solution. Why not have an admin configuration setting for "allow inline tags" with default off. Change it to on and you get an additional upload checkbox for 'inline at tag' to accommodate the current functionality of the inline module while simultaneously allowing for default placement. " NOOO. people; please; look at the PATCH. Again: and hopefully last time: Simplicity. This patch does NOT replace ANYTHING inline module or img_assist wants to do. This patch hands better data to such modules. It hands a variable over to these modules, $node->file[FID]->inline, which tells these sorts of modules if people wnat that file to appear inline. AND it CAN (by default will) render a file in the most simple way inline. So really, if you want to -1 this patch, fine. But do not -1 it, because it does too little IYO. It still allows MUCH more than what you can do no, without that patch! And any solution, for core, that allows advanced handling of inline images will either require an enourmous amount of work, or it will simply no get in. So, unless you come up with a good core-worthy patch, this is still a big leap forward from what we have now. ------------------------------------------------------------------------ Sat, 23 Jul 2005 19:01:51 +0000 : Bèr Kessels :$ this is an attempt to fix the borken HML in the previous follow up. ------------------------------------------------------------------------ Sun, 24 Jul 2005 04:07:34 +0000 : TDobes Please don't combine unrelated changes together in the same patch. Moving stuff in/out of the _nodeapi hook has absolutely nothing to do with the patch and makes it much harder to read through the patch and see what it's actually doing. I'd appreciate it if you could separate the changes made here which are really relevant and move the other changes into another issue. Also: You change form_group_collapsible(t('File attachments') to form_group_collapsible(t('File Attachments'). A quick glance at some other core code seems to indicate that we've standardized on capitalizing only the first word in multi-word group titles. As for the functionality itself, I don't think this belongs in upload.module. It would be useful to have the functionality in core, but as a separate module which can be switched on and off. (upload_inline.module or something like that) If a site were set up using an inlining system from contrib and the functionality you're proposing could not be switched off, it would be extremely confusing to users that there are two different ways of inlining images. A minor comment: I'm not so sure whether the results of this patch, when inlining non-image attachments, will be the one users expect. A non-web-savvy person may expect his/her Word document (for instance) to appear inline with the node when they click "inline" -- just like their images do. I'd suggest that we limit inlining to images only. I'm not as adamant about this as the other issues, so I could be convinced otherwise if others disagree. ------------------------------------------------------------------------ Sun, 24 Jul 2005 07:58:19 +0000 : Bèr Kessels Thank you for your thoughts Tdobbes. As for the "moving things in and out of nodeapi" This was necessary, because otherwise the patch would have made the code even more unreadable. I agree with you on this point, but I simply had to clean it up a little, in order to be able to work in it. As it stands now, it is simply not possible to make this a separate module. We cannot hook into the files table. In a next stage, I might work out some hook for that table. But first things first. Can Dries or Steven please comment on his. I want to know If i should bother spending this enormous amount of time on commenting and debating this issue. If the chances are small this is accepted, Ill just drop it This ridiculous long thread reminds me again why I try to avoid making patches for core.

1 0

[drupal-devel] [bug] Category selection does not work with Movable Type blogapi
by mrmachine 25 Jul '05

25 Jul '05

Issue status update for http://drupal.org/node/24030 Post a follow up: http://drupal.org/project/comments/add/24030 Project: Drupal Version: 4.6.2 Component: blogapi.module Category: bug reports Priority: normal Assigned to: walkah Reported by: mrmachine Updated by: mrmachine Status: patch has anyone managed to test this patch on 4.6.2? i haven't been able to get it working, so i'm back to a patched 4.6.1 blogapi.module ... i just hope this doesn't mean i'm still open to security vulnerabilities of 4.6.1 as my site was defaced only last week ... though i'm sure the vulnerability was only in the xmlrpc.php file. mrmachine Previous comments: ------------------------------------------------------------------------ Tue, 31 May 2005 22:38:14 +0000 : mrmachine Using a blog client (linux - either Drivel or BlogTK) and the Moveable Type api, you can retrieve categories and select one for your post, but once the post is submitted, it fails to allocate the category - making the use of a blog tool pretty useless. ------------------------------------------------------------------------ Tue, 31 May 2005 22:45:51 +0000 : laura s I use ecto, set to MoveableType API,but so far I'm not able to repeat this problem. Could it be the client? I was also able to set Drupal's BlogAPI to the MetaWeblog setting and it seemed to work fine -- even with ecto set to MoveableType API. You might be able to try that as a workaround. ------------------------------------------------------------------------ Thu, 02 Jun 2005 12:04:12 +0000 : mrmachine I tried ecto on my son's Windows box, and yes - it does set categories correctly ... too bad there's no linux version but anyway, i tried changing Drupal's blogapi to Metaweblog, and kept Drivel and BlogTK set to Moveable Type API. It didn't work for Drivel, but it did for BlogTK ... thanx for the hint! ------------------------------------------------------------------------ Sun, 05 Jun 2005 14:36:44 +0000 : fflewddur I've been trouble-shooting this issue using w.bloggar on Windows and Drivel on Linux. w.bloggar is able to post using the Movable Type API, but the category selection only works if you click "Post", not "Post and Publish". Drivel, by default, publishes all posts, which is why the category never shows up when using Drivel with Drupal. To post entries with categories to an official Movable Type implementation, the client must first post the entry, then call mt.setPostCategories, and then call mt.publishPost. The mt.publishPost call is what seems to be confusing Drupal, as it doesn't appear to differentiate between a post that has been published with one which has. Movable Type does not publicly display posts which have not been published; it considers them as drafts which the author has not yet finished. Thus, Movable Type servers require the mt.publishPost call. I have Ethereal traces of several example posts to Drupal using both w.bloggar in "post" and "post and publish" mode, as well as Drivel. If you think they'd be useful in debugging, let me know and I'll forward them on to you. Cheers, Todd ------------------------------------------------------------------------ Thu, 09 Jun 2005 03:57:11 +0000 : mrmachine has anyone had a chance to look at this since Todd debugged it? ------------------------------------------------------------------------ Mon, 13 Jun 2005 20:56:58 +0000 : mrmachine can someone have a look at this? ------------------------------------------------------------------------ Tue, 14 Jun 2005 00:05:25 +0000 : walkah Attachment: http://drupal.org/files/issues/blogapi-publish-post.patch (634 bytes) having a look - it seems that mt.publishPost may well have been wiping the term info set by setCategory. As I only have ecto available to me currently, I can't test this patch... but if I understand the debugging work correctly - this should fix it. (the difference being ecto and MarsEdit - the two that I have access to currently - don't call publishPost). please confirm this fixes things... thanks. (I'll test more when I'm home again at the end of the week). ------------------------------------------------------------------------ Tue, 14 Jun 2005 23:06:29 +0000 : mrmachine beauty! this has fixed it for me! thanx shayne ------------------------------------------------------------------------ Wed, 15 Jun 2005 04:29:48 +0000 : baudolino This is not fixed until a decision about whether to commit this patch is made. Reverting this to patch status. ------------------------------------------------------------------------ Sun, 19 Jun 2005 20:25:55 +0000 : Dries Actually, this is an annoying property of node_save() ... I guess you can't use node_invoke_nodeapi($node, 'insert') or node_invoke_nodeapi($node, 'update')? ------------------------------------------------------------------------ Thu, 23 Jun 2005 17:53:32 +0000 : walkah i'm not sure that'd make a difference, would it? isn't the issue that $node->taxonomy is unset? ------------------------------------------------------------------------ Wed, 20 Jul 2005 11:56:50 +0000 : mrmachine i upgraded to 4.6.2 (a tad late though - i'd been hacked), and am now back to the original problem (i.e. - using Drivel or BloGTK, i am unable to set the category - i can choose one, but it doesn't stick) ... i'm guessing it's because this is "not fixed" and so wasn't committed with the 4.6.2 release. am i able to use the same patch to "not fix" 4.6.2? in doing so, i won't mess up any 4.6.2 security patches, will i? shayne ------------------------------------------------------------------------ Sat, 23 Jul 2005 21:26:06 +0000 : mrmachine "am i able to use the same patch to "not fix" 4.6.2? " no. no i can't. i'd really like to test any possible fixes. are there any?

1 0

[drupal-devel] Use more constants?
by Adrian Rossouw 24 Jul '05

24 Jul '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Busy doing some menu things, and I was wondering why we are using strings for the properties, when constants would be more readable imo. $items[] = array('path' => 'admin/display/regions/configure', 'title' => t('configure block'), 'access' => user_access('administer blocks'), 'callback' => 'block_admin_configure', 'type' => MENU_CALLBACK ); versus $items[] = array( path => 'admin/display/regions/configure', title => t('configure block'), access => user_access('administer blocks'), callback => 'block_admin_configure', type => MENU_CALLBACK ); The only place I see it being impossible to use constants would be 'callback arguments' , and imo .. arguments => array(1, 2, 3) is far more readable than : 'callback arguments' => array(1, 2, 3) I'm not trying to champion a cause or anything, I was just wondering what the reasoning behind it was. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFC4pQ7gegMqdGlkasRAkR7AKDP81L84gC6NKI/wmyKq4eO8HXgiQCgo4mi P2FUnoK2/9TZruEhOUeyA3o= =1o10 -----END PGP SIGNATURE-----

2 1

[drupal-devel] [task] Introduce Daylight Saving Time for Drupal
by praseodymium 24 Jul '05

24 Jul '05

Issue status update for http://drupal.org/node/11077 Post a follow up: http://drupal.org/project/comments/add/11077 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: crunchywelch Reported by: killes(a)www.drop.org Updated by: praseodymium Status: patch +1 for this feature, it's irritating to change timezones every time DST is set. praseodymium Previous comments: ------------------------------------------------------------------------ Sun, 26 Sep 2004 03:01:53 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/dst.patch (6.04 KB) Many people have wanted to have a Daylight Saving Time setting in the past. If we use the "server time" modell (all times are displayed the same around the world) this isn't all that hard to do. I found a lot of usefull information here: http://webexhibits.org/daylightsaving/g.html The patch introduces a new DST setting and uses it if the "Configurable time zones" setting is switched off. ------------------------------------------------------------------------ Sun, 26 Sep 2004 04:40:56 +0000 : gordon This is a lovely patch, but you do realise that you have opened a can of worms. Daylight saving is a messy business, I had to write the Contestable Electricity billing for a company here in Australia which had multiple installations in multpile timezones, all with different daylight savings rules, which impacted upon the bill. The way that dst is legistated is very messy and here is Australia it is very messy. Daylight savings don't follow state lines, as some towns that are very close to the border may choose to follow the only the daylight saving period of the next state, and when we had the olympics NSW went into daylight savings months before anyone else. There are other examples of weird things like even the 1 hour forward is not also true. I know that in the 1999 change to daylight savings there was a small set of islands north of New Zealand that went ahead by 2 hours as they wanted to be the first into 2000. >From what I can see of your patch it only allows for a single daylight savings period for the entire system. Their can be situations where there can be users from multiple countries and in different timezones/dst. I think that entire timezone system needs to looked at again, and maybe re-implement it so that it will allow for dst. Maybe make it a bit more user friendly so instead of setting up the timezone by name much like how operating systems do it, and then this will automatically work out the timezone. +1 for this is something that would be good, but it still needs work. ------------------------------------------------------------------------ Sun, 26 Sep 2004 14:13:27 +0000 : Anonymous The patch works as it is now. I had good reason to limit its capability to the setting where users cannot chose their own timezone. ;) I also assume that a server administrator knows if he has dst or not. I also didn't (yet) cater for all countries where dst is in use mainly because some insist on not giving a sensible rule for the change dates. ------------------------------------------------------------------------ Sun, 26 Sep 2004 22:54:40 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/dst_0.patch (6.04 KB) The last comment was mine. After a code review by Kjartan I provide a slightly improved patch. I want to stress that solving the DST issue in a "suits everybody" manner isn't the intention of this patch. It solves the problem for people who have chosen to let all times on their site be displayed in the server's time setting. By covering a large portion of the earth's landmass I hope to be able to help most site admins. It would be possible to extend the patch to allow users to chose their DST setting, too. In my experience, however, users tend to not care about time settings at all. This may be EUrocentric though, as we have only one time zone. Feedback is welcome. ------------------------------------------------------------------------ Mon, 27 Sep 2004 21:12:25 +0000 : drumm +1 >From a code review I think this is an excellent solution. Could use a little more comments in the section that sets $node->date to explain the (probably good) reasoning behind that chunk of code. I don't have anything resembling a good set of tests so I did not apply the patch and try it. ------------------------------------------------------------------------ Tue, 25 Jan 2005 20:38:14 +0000 : killes(a)www.drop.org I just want to point out that this patch still applies and would make for a fine feature for Drupal 4.6... ------------------------------------------------------------------------ Wed, 26 Jan 2005 16:46:21 +0000 : alliax wouldn't hurt to have this feature in upcoming drupal. I would use it for sure, my users are from the same place, with dst ------------------------------------------------------------------------ Thu, 28 Apr 2005 16:12:36 +0000 : Sage This is an incredibly useful feature and I would like to see it incorporated into the next release (current release is 4.6.0). ------------------------------------------------------------------------ Wed, 04 May 2005 16:06:51 +0000 : syntaxerror Works beautifully.. I'm going to work on getting this to work with event.module. ------------------------------------------------------------------------ Wed, 04 May 2005 17:53:36 +0000 : crunchywelch I have just discussed with killes and rorris an enhancement to this patch which I will implement. We have proposed putting the ical timezone db (http://cvs.drupal.org/viewcvs/drupal/contributions/modules/ical/ical.sql?re…) in core. We will implement a DST field in that db for each zone which coreesponds with the zones in killes' patch here for dtermining whether a zone is currently in dst or not. Currently, the 5 zones in the drupal_is_dst() function in this patch will be the only regions assigned to timezones. If more regions are desired they can be submitted by the community. To be clear, this must be implemented before additional development on ical/event.module can proceed properly. We would like this to be in core for 4.7, and move one more step with timezone handling in event module to use this as well. Discuss! ------------------------------------------------------------------------ Wed, 04 May 2005 18:13:06 +0000 : tostinni I agree to put more specific region to DST as it's easier for someone to know which city DST he belongs than which DST Zone (Pacific Standard Time...). I like pretty much the way that windows manage this. +1 ------------------------------------------------------------------------ Thu, 05 May 2005 02:45:52 +0000 : Jaza The patch looks good... however, it doesn't take into account the fact that in Australia, DST starts and ends at 2am on Sunday morning. So these lines: case 4: // Australia // start of DST (last Sunday in October) $dststart = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + $timezone; // end of DST (last Sunday in March) $dstend = strtotime("-1 week sunday GMT", strtotime("1 april $year GMT")) + $timezone; break; Should read: case 4: // Australia // start of DST (last Sunday in October at 2am) $dststart = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + 7200 + $timezone; // end of DST (last Sunday in March at 2am) $dstend = strtotime("-1 week sunday GMT", strtotime("1 april $year GMT")) + 7200 + $timezone; break; There are also a whole lot more countries (and their specific DST rules) on http://webexhibits.org/daylightsaving/g.html than are implemented in this patch. I'd ultimately like to see an admin interface to let the webmaster add additional DST rules for whatever country they live in (or are developing for). These rules could be entered in raw PHP, or using a somewhat friendlier interface. Jaza. ------------------------------------------------------------------------ Wed, 25 May 2005 06:11:32 +0000 : Steven +1 on this patch. Catches most cases and at least provides a base for others to work on. ------------------------------------------------------------------------ Wed, 25 May 2005 07:13:36 +0000 : gordon Do not take this the wrong what, but when it comes to dst, this is exemely simplisict. What would be the best method of doing this is to use the Zone Info files from libc. These not only have all the dst splits, but also all the timezones, and would be the most acurate. Have a look at Sources of Time Zone and Daylight Savings Data [1] whcih has pointers to where all this information is. Did you know that Australia has 21 different Timezones and DST areas. If you could enter the same information from tzdata then this would be the altermate dst system [1] http://www.twinsun.com/tz/tz-link.htm ------------------------------------------------------------------------ Wed, 25 May 2005 12:25:32 +0000 : jhriggs There has sure been a lot of talk about DST and time zones lately. All I ask is that we hold off on committing anything for a bit. I am currently working on a project that will hopefully fix this issue completely, correctly, and once and for all. :-) I am in the process of writing a pure PHP library that will be released LGPL that uses the /real/ zoneinfo data files to handle any date (not just Unix timestamps) in any time zone. With this, site admins and/or users will be able to select their real time zone (America/New_York vs. our current GMT -500) and DST will inherently be handled without users having to change their settings. Much of the grunt work is already done. I still have to put all of the pieces together and make sure everything is well documented. As soon as I have tested everything to my satisfaction, I will role a Drupal patch that we can hopefully get tested and committed ASAP. Of course I want to see this get into Drupal first! ;-) I hope to have everything completed in the next couple of weeks, but based on the way things have been going lately, I can't make any promises. It will definitely be done before 4.7, though...whatever it takes! ------------------------------------------------------------------------ Wed, 25 May 2005 12:47:07 +0000 : gordon +1 This sounds great, but I think we will still need a pure php version that will be able to be used on hosted web sites where we will not be able to get you library installed. It doesn't need to be as effient as the php extension, as sites that at that big will be self hosted and be able to install this library. One question. Does you extension run on windows. If it does this is another reason to have a pure php version. This is really the method that should be employed. ------------------------------------------------------------------------ Wed, 25 May 2005 12:53:32 +0000 : jhriggs When I say "library," I just mean a collection of PHP files as opposed to a single file. There is nothing to be installed like an extension. This is pure PHP that will simply be part of the distribution (a handful of .php files placed inside includes/zoneinfo or something like that). As this is pure PHP, it will work anywhere PHP does. This will essentially give us the benefit and functionality of using the TZ variable on Unix without all of the problems associated with that (i.e. not knowing what zones are available and what there names are, not being available on Windows, etc.). ------------------------------------------------------------------------ Wed, 25 May 2005 13:27:05 +0000 : gordon This sounds good. If you would like someone who has done alot of stuff with timezones and dst (mainly in the contestable electricity inductry in australia, which is required for billing), I would be quite happy to take a look. The only problem that I see is that it sounds a little too messy for core. maybe this could be made into a contributed module that can be installed if people need the correct timezones. However this is how the dst and timezones need to be done if we want to get them correct. As I said before and I couldn't believe it, Australia has 21 different timezones and dst areas. The timezone database needs to be maintained. ------------------------------------------------------------------------ Wed, 25 May 2005 14:41:40 +0000 : killes(a)www.drop.org jhriggs, gordon: Please have a look at crunchywelch's dst implementation for event.module (in 4.6 and cvs). We intend to push this into core. ------------------------------------------------------------------------ Tue, 28 Jun 2005 20:11:48 +0000 : mfb Great! event_timezones.inc definitely needs to be in core, as it would be used for both user and site configuration. But it should include everything from the unix zoneinfo libraries, e.g. timezone abbreviations used by strftime(), so you can display "PDT" or "PST" instead of "America/Los_Angeles". so, a complete port of the zoneinfo libraries to PHP is probably what is needed. This would be used for site config, user config and events. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:45:33 +0000 : glen one idea, maybe use mysql timezone tables that are available since mysql 4.1.3? http://www.visionwebhosting.net/mysql-web-hosting/page0403.htm not sure how it's possible with licensing, but original tzdata is GPL (at least according to Fedora Core 2 tzdata.spec) then mysql data table contents should be too GPL. good side is that it should work for windows too http://dev.mysql.com/downloads/timezones.html ------------------------------------------------------------------------ Sat, 23 Jul 2005 02:08:23 +0000 : mfb It would be great to use MySQL 4.1 as the solution but it probably isn't (yet) possible for Drupal to require MySQL 4.1 when many webhosts are still using MySQL 4.0. We'll have to use our own zoneinfo library. Which by the way will need an update if the U.S. changes daylight saving time.

1 0

[drupal-devel] [feature] Use attribute rel=nofollow in comment's link
by Bèr Kessels 24 Jul '05

24 Jul '05

Issue status update for http://drupal.org/node/15835 Post a follow up: http://drupal.org/project/comments/add/15835 Project: Drupal Version: 4.5.0 Component: comment.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: clockwerx(a)www.spreadfirefox.com Updated by: Bèr Kessels Status: patch it is, but not in 4.5.what do we do with these 4.5 issues. 4.5 does not get any new features, so the patch will stay in here forever... can we close it? Bèr Kessels Previous comments: ------------------------------------------------------------------------ Wed, 19 Jan 2005 13:07:28 +0000 : clockwerx(a)www.spreadfirefox.com See this yahoo blog post [1] if you haven't already. " By adding a rel="nofollow" attribute to hyperlinks, webmasters and weblog owners can tell search engines that the links are effectively untrusted. For example, this: buy now [2] Becomes this: buy now [3] " [1] http://www.ysearchblog.com/archives/000069.html [2] http://spammer.example.com/ [3] http://spammer.example.com/\" rel=\"nofollow ------------------------------------------------------------------------ Wed, 19 Jan 2005 13:11:52 +0000 : clockwerx(a)www.spreadfirefox.com 6.12 Link types [4] Authors may use the following recognized link types, listed here with their conventional interpretations. In the DTD, %LinkTypes refers to a space-separated list of link types. White space characters are not permitted within link types. " So, you should perhaps be appending this to any existing comment links with a rel attribute. [4] http://www.w3.org/TR/REC-html40/types.html#type-links ------------------------------------------------------------------------ Wed, 19 Jan 2005 13:56:25 +0000 : chrisada +1 for the feature It seems to me this might be easier accomplished as an input filter? ------------------------------------------------------------------------ Tue, 19 Jul 2005 21:34:58 +0000 : bradtem Attachment: http://drupal.org/files/issues/nofollow.patch (0 bytes) Here's the trivial patch to includes/common.inc to change this. ------------------------------------------------------------------------ Wed, 20 Jul 2005 11:04:12 +0000 : stefan nagtegaal Isn't such a thing already in HEAD? I thought Walkagh brought us such a patch, not sure though.. Can't check atm.

1 0