August 2005 - Development - lists.drupal.org

[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

[drupal-devel] [bug] node created timestamp changes on node edit
by killes 06 Aug '05

06 Aug '05

Issue status update for http://drupal.org/node/24002 Post a follow up: http://drupal.org/project/comments/add/24002 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: adrinux Updated by: killes(a)www.drop.org Status: patch (ready to be committed) The previous review was brought to you by Patch Bingo! http://drupal.org/patchbingo killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Tue, 31 May 2005 16:57:22 +0000 : adrinux When an image node is edited it changes position in the gallery, and in image taxonomy listings. This is not the usual 'most recently edited' item floating to the top. The edited image simply shifts to a different place in the gallery with no apparent logic. As far as I can tell this happens because image module sorts the images in a gallery by the node creation timestamp, and for some reason the creation timestamp is being incremented a little on editing the node. (Of course the changed timestamp also changes as expected.) Here's and example. Lets take this gallery http://sphop.perlucida.com/image/tid/62 And change the title from *sphp_2002_061_henk.jpg* to *Seagulls* on this image: http://sphop.perlucida.com/node/322 Prior to the change we have the following (info extracted from the db): nid: 322 title: sphp_2002_061_henk.jpg created: 1117550744 changed: 1117550744 And the image is listed between *sphp_2002_062_henk.jpg* and *sphp_2002_060_henk.jpg* as you'd expect. We change the title and image moves to appear between *sphp_2002_067_henk.jpg* and *sphp_2002_066_henk.jpg* as you can see: http://sphop.perlucida.com/image/tid/62?from=12 The db now gives: nid: 322 title: Seagulls created: 1117550756 changed: 1117558316 So, why does the *created* timestamp change at all, and can I stop that happening? I should say that the images in the gallery were initially imported using import_image.module - but I don't see what this could have to do with that. ------------------------------------------------------------------------ Thu, 30 Jun 2005 00:59:08 +0000 : dtan Attachment: http://drupal.org/files/issues/node.module.created.patch (591 bytes) You'll notice that there is an authored on text box. . .it doesn't provide seconds, so when the timestamp is created, it picks up the current minutes seconds. Thus if you edit a node (any type) and view its created field in the db, and continuously repeat over 60 seconds, you will see the created loop back down. Here is the patch. . .which is actually applied to the *node.module*. ------------------------------------------------------------------------ Thu, 30 Jun 2005 01:42:51 +0000 : clydefrog dtan, your patch contains html. ------------------------------------------------------------------------ Thu, 30 Jun 2005 03:40:03 +0000 : dtan Attachment: http://drupal.org/files/issues/node_module_created.patch (591 bytes) another one :) ------------------------------------------------------------------------ Thu, 30 Jun 2005 15:13:57 +0000 : Jose A Reyero Hey dtan, I'd say very good catch :-) , tested the patch and seems to be ok. Anyway, I think this bugfix needs to be posted to Drupal core. ------------------------------------------------------------------------ Thu, 30 Jun 2005 19:22:49 +0000 : mfb +1 ------------------------------------------------------------------------ Fri, 01 Jul 2005 07:31:10 +0000 : adrinux No time to test this until next week myself, but It's already got two +'s so I'm moving it to core and re-titleing. Thanks to dtan for hunting this one down :) ------------------------------------------------------------------------ Mon, 18 Jul 2005 15:01:28 +0000 : adrinux Had time to test dtan's patch properly and can now say definitively that it does fix this problem. That is, without this patch the node created timestamp changes on a node edit. With this patch applied only the node changed timestamp changes, as you'd expect. So +1 on this getting applied ASAP. ------------------------------------------------------------------------ Mon, 18 Jul 2005 15:17:19 +0000 : adrinux I made a version of this patch for CVS HEAD: http://drupal.org/node/26960 ------------------------------------------------------------------------ Sat, 06 Aug 2005 13:34:33 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/created.patch (602 bytes) Ok, it is a bit difficult to see why this fixes the problem, but yes it does. The incorrect data format causes node->created to change by up to 59 seconds which can cause time ordered nodes eg from uploads to change position. I've re-roles the patch for cvs from http://drupal.org/node/26960 and attach it here.

1 0

[drupal-devel] [bug] node created timestamp changes on node edit
by killes 06 Aug '05

06 Aug '05

Issue status update for http://drupal.org/node/24002 Post a follow up: http://drupal.org/project/comments/add/24002 Project: Drupal -Version: 4.6.0 +Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: adrinux Updated by: killes(a)www.drop.org -Status: patch (code needs review) +Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/created.patch (602 bytes) Ok, it is a bit difficult to see why this fixes the problem, but yes it does. The incorrect data format causes node->created to change by up to 59 seconds which can cause time ordered nodes eg from uploads to change position. I've re-roles the patch for cvs from http://drupal.org/node/26960 and attach it here. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Tue, 31 May 2005 16:57:22 +0000 : adrinux When an image node is edited it changes position in the gallery, and in image taxonomy listings. This is not the usual 'most recently edited' item floating to the top. The edited image simply shifts to a different place in the gallery with no apparent logic. As far as I can tell this happens because image module sorts the images in a gallery by the node creation timestamp, and for some reason the creation timestamp is being incremented a little on editing the node. (Of course the changed timestamp also changes as expected.) Here's and example. Lets take this gallery http://sphop.perlucida.com/image/tid/62 And change the title from *sphp_2002_061_henk.jpg* to *Seagulls* on this image: http://sphop.perlucida.com/node/322 Prior to the change we have the following (info extracted from the db): nid: 322 title: sphp_2002_061_henk.jpg created: 1117550744 changed: 1117550744 And the image is listed between *sphp_2002_062_henk.jpg* and *sphp_2002_060_henk.jpg* as you'd expect. We change the title and image moves to appear between *sphp_2002_067_henk.jpg* and *sphp_2002_066_henk.jpg* as you can see: http://sphop.perlucida.com/image/tid/62?from=12 The db now gives: nid: 322 title: Seagulls created: 1117550756 changed: 1117558316 So, why does the *created* timestamp change at all, and can I stop that happening? I should say that the images in the gallery were initially imported using import_image.module - but I don't see what this could have to do with that. ------------------------------------------------------------------------ Thu, 30 Jun 2005 00:59:08 +0000 : dtan Attachment: http://drupal.org/files/issues/node.module.created.patch (591 bytes) You'll notice that there is an authored on text box. . .it doesn't provide seconds, so when the timestamp is created, it picks up the current minutes seconds. Thus if you edit a node (any type) and view its created field in the db, and continuously repeat over 60 seconds, you will see the created loop back down. Here is the patch. . .which is actually applied to the *node.module*. ------------------------------------------------------------------------ Thu, 30 Jun 2005 01:42:51 +0000 : clydefrog dtan, your patch contains html. ------------------------------------------------------------------------ Thu, 30 Jun 2005 03:40:03 +0000 : dtan Attachment: http://drupal.org/files/issues/node_module_created.patch (591 bytes) another one :) ------------------------------------------------------------------------ Thu, 30 Jun 2005 15:13:57 +0000 : Jose A Reyero Hey dtan, I'd say very good catch :-) , tested the patch and seems to be ok. Anyway, I think this bugfix needs to be posted to Drupal core. ------------------------------------------------------------------------ Thu, 30 Jun 2005 19:22:49 +0000 : mfb +1 ------------------------------------------------------------------------ Fri, 01 Jul 2005 07:31:10 +0000 : adrinux No time to test this until next week myself, but It's already got two +'s so I'm moving it to core and re-titleing. Thanks to dtan for hunting this one down :) ------------------------------------------------------------------------ Mon, 18 Jul 2005 15:01:28 +0000 : adrinux Had time to test dtan's patch properly and can now say definitively that it does fix this problem. That is, without this patch the node created timestamp changes on a node edit. With this patch applied only the node changed timestamp changes, as you'd expect. So +1 on this getting applied ASAP. ------------------------------------------------------------------------ Mon, 18 Jul 2005 15:17:19 +0000 : adrinux I made a version of this patch for CVS HEAD: http://drupal.org/node/26960

1 0

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

06 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 Component: aggregator.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Gunnar Langemark(a)www.langemark.com Updated by: Prometheus6 Status: patch (code needs review) 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. Prometheus6 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.

1 0

[drupal-devel] [feature] "blog it" link lost in aggregator
by Boris Mann 06 Aug '05

06 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: cvs +Version: 4.6.0 Component: aggregator.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Gunnar Langemark(a)www.langemark.com Updated by: Boris Mann -Status: active +Status: patch (code needs review) 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. Boris Mann 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.

1 0

[drupal-devel] [bug] conf_init should strip out port numbers in bootstrap.inc
by Boris Mann 06 Aug '05

06 Aug '05

Issue status update for http://drupal.org/node/19934 Post a follow up: http://drupal.org/project/comments/add/19934 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: chx Reported by: bwooster47 Updated by: Boris Mann Status: patch (code needs work) I like the period (".") character as the delimiter for ports. If people really do tack on :80, then site admins can symlink domain.com.80 to domain.com (much as you would need to symlink www.domain.com to domain.com as well). I think this is largely a documentation issue. Boris Mann Previous comments: ------------------------------------------------------------------------ Sun, 03 Apr 2005 23:07:58 +0000 : bwooster47 The latest Drupal from CVS (4.6.0) offers multisite configuration files, but currently the conf_init function in includes/bootstrap.inc will also include the :portnum URL specification in the directory name, which does not seem right (and the colon character may cause problems on Mac/Windows). Snippet from bootstrap.inc: * Example for a fictitious site installed at * http://www.drupal.org/mysite/test/ the 'settings.php' is * searched in the following directories: ..... If the site is: http://www.drupal.org:8080/mysite/test/ the same list of directories should be searched as listed in the example in the file, and the :8080 should not be added to the directory name (I think...) I don't know enough PHP to submit a patch, but this is probably easy for those who know this stuff :-) ------------------------------------------------------------------------ Fri, 08 Apr 2005 07:08:53 +0000 : chx Attachment: http://drupal.org/files/issues/conf_init_ports.patch (768 bytes) Here you are. ------------------------------------------------------------------------ Fri, 08 Apr 2005 11:16:52 +0000 : Dries Won't commit. Removing the port seems like a bad idea (I could have two drupal sites at two different ports but otherwise identical URLs) and adding regex' all over the map isn't advised. If ":" is an invalid character, then there might be more such characters. I suggest we replace them with '.' and that we document this behavior much like we do with $db_url. ------------------------------------------------------------------------ Mon, 11 Apr 2005 23:25:51 +0000 : chx Attachment: http://drupal.org/files/issues/conf_init_ports_0.patch (1.35 KB) ------------------------------------------------------------------------ Tue, 19 Apr 2005 17:03:46 +0000 : bwooster47 Regarding update #3 - does this mean the code has made it in, and will be available in the next release? Secondly: I follow the logic for the update, and it makes sense for non-standard HTTP port numbers, but not sure if the logic is valid when port 80 is used. For example, http://yourdomain.com/ and http://yourdomain.com:80/ both will go to the exact same page, but looks like the search for the conf.php will be different. Not sure if this matters... ------------------------------------------------------------------------ Mon, 01 Aug 2005 01:23:28 +0000 : killes(a)www.drop.org patch still applies, my testsite kept working (is not on a non-standard port, though). ------------------------------------------------------------------------ Mon, 01 Aug 2005 05:31:56 +0000 : Dries I think the PHPdoc is confusing. The second example URL is non-existing/invalid. Did you meant showing a configuration file? I agree with bwooster that this gets tricky with the default port '80'. Do we need to discuss this some more?

1 0

[drupal-devel] [task] Remove a div tag
by drumm 06 Aug '05

06 Aug '05

Issue status update for http://drupal.org/node/28320 Post a follow up: http://drupal.org/project/comments/add/28320 Project: Drupal Version: cvs Component: user.module Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (code needs review) Attachment: http://drupal.org/files/issues/user.module_17.diff (1.56 KB) We don't really need this div since the block has a standardized id. drumm

1 1

[drupal-devel] [bug] Handle full URLs in url() and l()
by jsloan 05 Aug '05

05 Aug '05

Issue status update for http://drupal.org/node/10888 Post a follow up: http://drupal.org/project/comments/add/10888 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Bèr Kessels Reported by: jhriggs Updated by: jsloan Status: patch (code needs work) I've come to this party late but would like to see a patch soon... I've used the patch from Adrian (#15) but this did not work correctly in my setup (IIS 5.0 / no clean urls) I applied it against 4.6.2 and cvs. Where is the latest patch that I can test ... I'll throw some time at this because I need it for a module used within our Intranet. jsloan Previous comments: ------------------------------------------------------------------------ Thu, 16 Sep 2004 15:01:24 +0000 : jhriggs Attachment: http://drupal.org/files/issues/full_url.patch (1.97 KB) This little patch allows full URLs to be used for the url() and l() functions, giving modules a single interface for creating links. Currently, modules must use l() for drupal links and raw HTML for external links. This patch changes url() to handle -- basically pass through -- full URLs while still doing the proper handling of internal paths and works with clean URLs enabled or disabled. It also shortens (and hopefully simplifies) the url() code a bit. Some examples of calls that now work: <?php l('a link', 'some/path'); // same as before l('an external link', 'http://drupal.org/'); l('full with query', 'http://google.com/search?q=define:foo'); l('full with separate query', 'http://google.com/search', array(), 'q=define:foo'); // same link as above l('full with fragment', 'http://drupal.org/node/5942#comment-12374'); l('full with separate fragment', 'http://drupal.org/node/5942', array(), NULL, 'comment-12374'); // same link as above ?> ------------------------------------------------------------------------ Thu, 30 Sep 2004 11:09:30 +0000 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ Mon, 24 Jan 2005 20:06:26 +0000 : mathias Attachment: http://drupal.org/files/issues/external_urls.patch (838 bytes) Revisiting this issue one year later shows we're almost there. The only thing that's left is the ability to handle external urls when clean_urls is disabled. Once implemented, menu.module can happily accept external urls and not just Drupal paths, making the menu system much more attractive to end users. I'll update the menu.module docs if this patch (or an alternative solution) is accepted. ------------------------------------------------------------------------ Sun, 13 Mar 2005 22:36:34 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ Mon, 14 Mar 2005 00:05:17 +0000 : gordon +1 This is a good thing for people who can't using clean urls. ------------------------------------------------------------------------ Sat, 02 Apr 2005 06:23:10 +0000 : TDobes This patch seems like a good idea, but does not apply anymore. Also, shouldn't the comments for l() and url() be updated to indicate that the functions will work with both internal and external URL's? ------------------------------------------------------------------------ Sat, 02 Apr 2005 07:25:13 +0000 : asimmonds Attachment: http://drupal.org/files/issues/external_urls_1.patch (897 bytes) The &'s had been changed to & amp; , here's a valid patch ------------------------------------------------------------------------ Thu, 12 May 2005 14:57:07 +0000 : adrian This is a new patch against cvs that allows url() to create external links, with the side-effect that menu can now be used to make external links. Also closes http://drupal.org/node/10177 This will be even more important with the primary links menu integration. (This patch already cleans up a special case in phptemplate for that). Killes benchmarked this, and it turns out the difference is negligible. Requests per second: 1.33 [#/sec] (mean) = with patch Requests per second: 1.31 [#/sec] (mean) = without patch. ------------------------------------------------------------------------ Thu, 12 May 2005 14:59:57 +0000 : killes(a)www.drop.org I had benchmarked /node as anon user without cache. ------------------------------------------------------------------------ Wed, 25 May 2005 04:50:08 +0000 : Steven +1 on the idea of this patch. It allows people to use l() for external links. However, I don't like the implementation. Running that complicated regexp for every url() call is simply wasteful. 95% or more of url() calls have a fixed string as parameter and point to Drupal's own paths. I suggest we create an url_external() wrapper around url() which allows external URLs. Any path which we want to allow external URLs in can use url_external() instead. The places where we use it will not be many anyway. ------------------------------------------------------------------------ Wed, 25 May 2005 05:05:55 +0000 : gordon splitting into url() url_external is not a good idea. The main reason for this patch that I see is for putting external urls into the navigation menu using the menu.module, and if all goes to plan, the primary and secondary menus. ------------------------------------------------------------------------ Wed, 25 May 2005 06:00:01 +0000 : Steven gordon: I still think this is a bit excessive. Perhaps instead of valid_url() we could use a simpler regexp !^[a-z]://!i or even strpos('://'). ------------------------------------------------------------------------ Wed, 25 May 2005 06:15:36 +0000 : gordon I am not says that it is or is not excessive. I was just saying that this is where it is going to be used, so creating url() and url_external() is not really an option ------------------------------------------------------------------------ Wed, 25 May 2005 06:57:53 +0000 : Bèr Kessels we /do/ need an external_url() thing. The links bundle (handling weblinks and the likes) willprovide this /and/ need this. People will get all sorts of tools to do /stuff/ with external links, like add permissions, track clicks etc. depending on the modules they have and the settings. All outgoing weblinks, should somehow respect those. Patches for core are coming, though. On top of that, a external_l() finction is simple. And if people want them in primary links they can do the regexping /before/ the function, not /in/ the function. The calling code can decide whether to call l() or external_l(), instead of putting logic in l() that is unneded 95% of the times. But i hereby promise to introduce such a function tbefore the end of this week :) ------------------------------------------------------------------------ Wed, 25 May 2005 07:17:47 +0000 : gordon The only thing I do not see in this plan is how with this work with the menu module and the navigation menu. ------------------------------------------------------------------------ Wed, 25 May 2005 10:04:12 +0000 : adrian Attachment: http://drupal.org/files/issues/url_external_links.patch (1.75 KB) What happened to the patch i uploaded ? It doesn't use a complex regexp, but uses strpos($url, '://') < 5. ------------------------------------------------------------------------ Thu, 26 May 2005 06:19:32 +0000 : Bèr Kessels Allthough this works, is clean AND does what it should do, I still am in favour of a better nitegrated solution. So please do not yet commit this, untill I upload my patch. We can then discuss what solution to take. It will not differ a big lot though. ------------------------------------------------------------------------ Thu, 26 May 2005 08:39:32 +0000 : adrian is this the patch where you want to introduce an el() to allow for counting of external links ? That's a different patch altogether. This is primarily about stopping url() from not handling external links when there is no good reason for it to do so. Your el() has a very specific use in the weblinks api, and should probably be included with it. ------------------------------------------------------------------------ Thu, 26 May 2005 16:18:31 +0000 : Bèr Kessels Yes, that el() But let me explain why i am anxious for my solution: el(), by default will not do much, in fact it will just be an URL()-clone but one that allows outgoing links. But it has a hook-caller. Again: by default it does nothing much, for there will not be any hooks around in core. It will allow, for example, weblinks, to track clicks, or to look up a permission and allow or disallow users to follow a link. Now, the whole issue, IMO is, that we should *not* provide two ways for handling external URLS, but rather a single one, that is weblink-safe. If we would introduce URL() with outgoing links-capabilities, we can no longer track any outgoing URLs trough them. We will then have two ways for handling outgoing URLs, resulting in inconsistencies, and confused users. (hey, my anonymous users can follow link foo, while i have "follow outgig links" permission disabled for them). (BTW weblink will soon be renamed into links, just for reference) ------------------------------------------------------------------------ Thu, 30 Jun 2005 11:06:11 +0000 : adrian Attachment: http://drupal.org/files/issues/url_external_links_0.patch (824 bytes) I've updated the patch. ------------------------------------------------------------------------ Mon, 18 Jul 2005 14:12:36 +0000 : adrian spoke to dries about this patch, and apart from the incomplete patch I uploaded, there are about a dozen instances where in-line html is used were l() would suffice. I will be cleaning them up and submitting a new patch soon. ------------------------------------------------------------------------ Fri, 05 Aug 2005 18:44:03 +0000 : moshe weitzman hopefully adrian or someone else will chase down the remaining urls which should use this function.

1 0