- Development - lists.drupal.org

[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

[drupal-devel] [bug] UI allows longer role name than database
by Cvbge 06 Aug '05

06 Aug '05

Issue status update for http://drupal.org/node/18616 Post a follow up: http://drupal.org/project/comments/add/18616 Project: Drupal -Version: 4.6.1 +Version: 4.6.2 Component: database system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: plj Updated by: Cvbge -Status: patch (code needs review) +Status: patch (code needs work) There should be also a patch for database/updates.inc Cvbge Previous comments: ------------------------------------------------------------------------ Wed, 09 Mar 2005 13:38:12 +0000 : plj The Postgresql database script shipped with Drupal 4.5.2 has a 32 characters long varchar value for role name. The relevant UI form field, however, has attribute maxlength="64". This naturally causes an SQL error, if too long name is entered. The SQL part is still same in CVS version, but I don't know if the UI part has been fixed. Related SQL: CREATE TABLE role ( rid SERIAL, name varchar(32) NOT NULL default '', PRIMARY KEY (rid), UNIQUE (name) ); ------------------------------------------------------------------------ Tue, 28 Jun 2005 16:51:15 +0000 : plj Changing version to 4.6.1, and component to database system (perhaps more relevant than user system), as the problem still exists. It also seems that the length of the field in question is only 32 in both database.mysql and database.pgsql, even though the UI allows 64. Either UI or the database scripts should be fixed. ------------------------------------------------------------------------ Tue, 28 Jun 2005 17:06:18 +0000 : plj Attachment: http://drupal.org/files/issues/database_1.patch (660 bytes) On a second thought, here is a patch against both DBs. Both are untested, but the change is tiny.

1 0

[drupal-devel] [feature] move check_query() into the database interface files
by Cvbge 06 Aug '05

06 Aug '05

Issue status update for http://drupal.org/node/13180 Post a follow up: http://drupal.org/project/comments/add/13180 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: Cvbge Status: patch (code needs work) First, we require PHP >= 4.3.3 so mysql_real_escape_string() is allways available, so the version check can be skipped. Second, I don't understand Steven's remark about UTF. There is no mention of UTF in the function's documentation. It should work for any encoding. Cvbge Previous comments: ------------------------------------------------------------------------ Fri, 19 Nov 2004 19:35:06 +0000 : chx Attachment: http://drupal.org/files/issues/check_output_patch.txt (1.54 KB) The check_query documentation says 'Prepare user input for use in a database query, preventing SQL injection attacks.' But the code itself is a simple addslashes. This is simply not correct -- for mysql, yes, but the world is not just mysql. There are _escape_string functions for that: mysql_escape_string, pg_escape_string, sqlite_escape_string... Read the manual for pg_escape_string: "Use of this function is recommended instead of addslashes()." Or read sqlite_escape_string: "addslashes() should NOT be used to quote your strings for SQLite queries; it will lead to strange results when retrieving your data." Ooooops. So I propose moving check_query() declaration from bootstrap.inc to database.*.inc. I've already written a letter to the devel list about this, but drumm said "code is better than talk" so here is a patch. At this moment, this does absolutely nothing, only opens the possibility to use the aforementioned escape_string functions. But database.sqlite.inc simply will not work without this change. ------------------------------------------------------------------------ Fri, 19 Nov 2004 19:42:04 +0000 : drumm Looks straightfoward enough. Is there any reason to not put in pg_escape_string() now? ------------------------------------------------------------------------ Fri, 19 Nov 2004 19:47:07 +0000 : chx Actually, yes. Read on the mentioned manual page: "Note: This function requires PostgreSQL 7.2 or later." I have no idea how the check it. There is a pg_version() but I will leave this postgres business to someone who has a working postgres install to code and check this thing. ------------------------------------------------------------------------ Fri, 19 Nov 2004 20:58:27 +0000 : Chris Johnson PostgreSQL 7.2 was released February 4, 2002. Major production releases 73. and 7.4, along with many point releases, have been issued since then. Current production is 7.4.6 and 8.0 is in the 4th revision of beta. It seems pretty safe to assume that any Drupal installation using PostgreSQL would have version 7.2 or later. Document if a user encounters errors with PostgreSQL that they need to check the version is 7.2 or later. ------------------------------------------------------------------------ Sat, 20 Nov 2004 13:42:37 +0000 : Dries +1 I suggest creating a db_escape_string() function, and removing check_query() all together. ------------------------------------------------------------------------ Sat, 20 Nov 2004 13:55:44 +0000 : Goba +1 on Dries ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:32:09 +0000 : chx Attachment: http://drupal.org/files/issues/check_output_patch_0.txt (1.6 KB) db_escape_string sounds find to me, it's really a better name, thanks Dries. But removing check_query? I'd suggest deprecating it and removing it later. I am afraid It would break a lot of custom modules. Here is a slightly modified patch with pg_escape_string included and documented. ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:43:37 +0000 : killes(a)www.drop.org We were never afraid of breakign things for the good of the project. Please don't change this policy. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:26:10 +0000 : chx Attachment: http://drupal.org/files/issues/db_escape_string.txt (20.87 KB) Let's do it. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:29:33 +0000 : chx Attachment: http://drupal.org/files/issues/db_escape_string_0.txt (20.88 KB) Something funny happened to the PostgreSQL db_escape_string comment and I have missed it, sorry. Reposting the patch. ------------------------------------------------------------------------ Sun, 21 Nov 2004 08:29:22 +0000 : Dries I committed the patch. Thanks chx. Keep it coming. I've also updated the upgrade notes at http://drupal.org/node/12347. I'll update some contributed modules unless someone objects. ------------------------------------------------------------------------ Sun, 21 Nov 2004 11:27:27 +0000 : chx Attachment: http://drupal.org/files/issues/mysql_escape_patch.txt (572 bytes) Keep it coming? Well, let's see the MySQL case... It's far from being trivial, and I expect some controversy over it. ------------------------------------------------------------------------ Wed, 09 Mar 2005 23:36:30 +0000 : chx Attachment: http://drupal.org/files/issues/mysql_escape_patch_0.txt (573 bytes) OK, here is mysql version a bit corrected, this should get into 4.6 -- addslashes is not a correct way any more. ------------------------------------------------------------------------ Thu, 10 Mar 2005 18:29:16 +0000 : Dries Can we read up on that somewhere? ------------------------------------------------------------------------ Thu, 10 Mar 2005 18:37:41 +0000 : Goba Dries, sure: http://php.net/mysql_escape_string [1] and http://php.net/mysql_real_escape_string [2]. The latter also uses the connections charset settings to properly escape, so it is the best (but is not available in old PHP versions). The addslashes page user notes also have more information [3]. [1] http://php.net/mysql_escape_string [2] http://php.net/mysql_real_escape_string [3] http://hu.php.net/addslashes#20013 ------------------------------------------------------------------------ Sat, 12 Mar 2005 08:50:26 +0000 : Dries addslashes() has been working for ages (and is simpler code-wise). I guess the mysql_ functions are slightly more secure or not even that? That aside, I'm not really a big fan of version_compare()s. Also note that the patch violates Drupal's coding standards (again) but that's easy enough to fix. ------------------------------------------------------------------------ Sun, 13 Mar 2005 19:49:48 +0000 : chx I can only repeat what Goba said: . mysql_real_escape_string uses the connections charset settings to properly escape, so it is the best (but is not available in old PHP versions). ------------------------------------------------------------------------ Wed, 01 Jun 2005 03:40:04 +0000 : Steven Actually, Drupal does nothing to ensure the database character set is set to UTF-8 (can it?). Thus, escaping with mysql_real_escape_string() is not advised. ------------------------------------------------------------------------ Mon, 01 Aug 2005 01:34:58 +0000 : killes(a)www.drop.org Accordign to Steven's last comment we should not use the mysql specific functions.

1 0

[drupal-devel] [bug] Undefined variable: authmaps
by kubaZygmunt 06 Aug '05

06 Aug '05

Issue status update for http://drupal.org/node/27897 Post a follow up: http://drupal.org/project/comments/add/27897 Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: kubaZygmunt Updated by: kubaZygmunt Status: patch (code needs review) Attachment: http://drupal.org/files/issues/user.module.authmaps.patch.txt (461 bytes) During testing uploading file I've got exception message: Unexpected PHP error [Undefined variable: authmaps] severity [E_NOTICE] in [****\modules\user.module] line [201] My patch changes: if ($authmaps) => if (isset($authmaps)) I don't know if this condition is sufficient so please review (but for my testing error message disappeared ) thank you kubaZygmunt

3 2