- Development - lists.drupal.org

[drupal-devel] [bug] Twin problems with comments
by Junyor 25 Mar '05

25 Mar '05

Issue status update for http://drupal.org/node/11366 Project: Drupal Version: cvs Component: database system Category: bug reports Priority: critical Assigned to: Junyor Reported by: pennywit Updated by: Junyor Status: active The problem I mentioned in my last comment is http://drupal.org/node/19432. I've looked at the change that Dries did and I honestly can't figure out why the change was made. I'd be happy to provide a patch for 4.5.x if I could figure out the problem. If anything, I think the query Dries is doing is returning too many matches, not the query I was doing. Junyor Previous comments: ------------------------------------------------------------------------ October 7, 2004 - 15:23 : pennywit I have two problems with my upgrade at http://www.pennywit.com. First is that a number of comments have the body turn to the number 3. It looks like this happens when one of my users tries to edit his comments. The second is that in any nodes submitted before I upgraded, I don't see a count of the comments already submitted. I'm echoing this to the support forum ... ------------------------------------------------------------------------ October 7, 2004 - 16:01 : pennywit It says this has been fixed ... what do I need to do on my side? --|PW|-- ------------------------------------------------------------------------ October 8, 2004 - 09:11 : Bèr Kessels http://drupal.org/node/11316`was the bug. Update commment.module will fix this problem. ------------------------------------------------------------------------ October 17, 2004 - 13:04 : kps This problem remains (in 4.5.0-rc 1/2 hour before this post): " ... any nodes submitted before I upgraded, I don't see a count of the comments already submitted. " The {node_comment_statistics} table is evidently not initialized correctly. Justification for "critical": Since most people who install 4.5.0 will be users of older releases, upgrading really ought to work before the release. ------------------------------------------------------------------------ October 17, 2004 - 13:47 : kps Attachment: http://drupal.org/files/issues/updc.php (1.26 KB) Attached, raw and as-is, the script I used to initialize the {node_comment_statistics} table. ------------------------------------------------------------------------ October 20, 2004 - 18:12 : kps Attachment: http://drupal.org/files/issues/updatecommentcount.php (907 bytes) My above attachment (updc.php) is broken. This one is... better. Visiting this page should at least populate the node_comment_statistics table with something not entirely unreasonable. ------------------------------------------------------------------------ October 25, 2004 - 08:39 : Junyor kps is right, the update won't correctly populate the table. Here's (part of) update_105: "INSERT INTO {node_comment_statistics} (nid, cid, last_comment_timestamp, last_comment_name, last_comment_uid, comment_count) SELECT n.nid, 0, n.created, NULL, n.uid, 0 FROM {node} n" So, it's setting the comment_timestamp = node creation time, forgetting the comment_creator, using the userid that created the node as the last_comment_uid, and setting the comment count to 0. update_105 needs to be redone and I'd recommend a new update be created for 4.5.1 that will correctly initialize the node_comment_statistics table. ------------------------------------------------------------------------ November 12, 2004 - 10:02 : Junyor OK, here's two patches to solve the problem. Issues fixed: - Fixes node_comment_statistics table prefixing for PostGreSQL - Drops CID column from node_comment_statistics and supporting code in comment.module - Initializes comments table with usernames (needed by node_comment_statistics table) - Correctly initializing node_comments_statistics table - Removed duplicate query for last_comment_name in node_comment_statistics query in comment.module Needs checking: - I couldn't test this with PostGreSQL - I'm no database expert, so the updates.inc changes need to be gone over with a fine-toothed comb - Do we need any special handling for comments with no 'name', i.e. truly anonymous comments These patches are for the DRUPAL-4-5-0 branch. ------------------------------------------------------------------------ November 12, 2004 - 13:01 : Junyor Attachment: http://drupal.org/files/issues/node_comment_stats.patch (7.89 KB) ------------------------------------------------------------------------ November 12, 2004 - 13:01 : Junyor Attachment: http://drupal.org/files/issues/node_comment_stats2.patch (3.44 KB) Actually attaching patches. :) ------------------------------------------------------------------------ November 14, 2004 - 21:10 : Dries I'm not 100% sure but isn't the name field of the comments table supposed to be NULL, unless the comment is an /anonymous comment/? Is it really required to initialize the name field? What happens if you don't? I just checked drupal.org's database and only /post Drupal 4.5.0 comments/ have the registered user's name in the comment table. I'm a little nervous about committing database changes to stable branches (DRUPAL-4-5) so please make sure this patch is well-tested. The patches don't apply against HEAD but I can port them once we/you ironed out the last glitches. Otherwise these patches look fine. Good job. ------------------------------------------------------------------------ November 14, 2004 - 23:41 : Junyor I don't know if it's necessary, but I'm just making sure it's consistent. Maybe the author of the node_comment_statistics patch could comment? I'm also concerned about having the name information for registered users outside of the users table. I've tested this on a test site and I'll try testing on my production site once we have this worked out. ------------------------------------------------------------------------ November 15, 2004 - 10:45 : Dries I don't know whether the original author (ccourtne) is still around but it should be easy enough to test whether it is necessary or not. From what I've seen, it isn't necessary. In fact, your current patch might break things: like, what happens when somone changes his or her username? AFAIK, the old username would be shown in the comments. ------------------------------------------------------------------------ November 15, 2004 - 11:03 : Junyor OK, I'll edit that bit and resubmit. You'd like this for HEAD only? ------------------------------------------------------------------------ November 15, 2004 - 18:24 : Junyor Attachment: http://drupal.org/files/issues/node_comment_stats-2.patch (7.24 KB) New patch for database files. ------------------------------------------------------------------------ November 15, 2004 - 18:25 : Junyor Attachment: http://drupal.org/files/issues/node_comment_stats2-2.patch (3.46 KB) New patch for comment.module. ------------------------------------------------------------------------ November 22, 2004 - 11:31 : Junyor Attachment: http://drupal.org/files/issues/node-comment-statistics_head.patch (7.26 KB) Patches for head. ------------------------------------------------------------------------ November 22, 2004 - 11:31 : Junyor Attachment: http://drupal.org/files/issues/node-comment-statistics_head2.patch (3.45 KB) ------------------------------------------------------------------------ November 23, 2004 - 23:24 : Dries I'd like to move forward with this patch and include it in Drupal 4.5.1. I can't reproduce this problem (it seems) so it would be much appreciated if those who can, can test it. ------------------------------------------------------------------------ November 29, 2004 - 00:42 : Junyor It applied and works well on my 4.5.0 site. A lot of nodes were listed as not having comments before, but they're working now. Dries alerted me to a drupal-support message regarding the patch and I'll look into that tomorrow. ------------------------------------------------------------------------ December 8, 2004 - 06:12 : crw After applying the patch, approving new comments still does not update the node_comment_statistics table, therefore the comment_count field is off and the number of new comments does not show up on the main page of my site. I'm currently troubleshooting this and will report my findings here. ------------------------------------------------------------------------ December 8, 2004 - 06:13 : crw I should point out that I applied the following patch: node-comment-statistics_head2.patch And the problem described above still exists. ------------------------------------------------------------------------ December 8, 2004 - 06:25 : crw Ok, headway. Looks like submitting a comment triggers an updating of node_comment_statistics, but editing a comment to publish/unpublish does not. Both should trigger the update, so I just need to find out why it isn't working for the 'update' case. ------------------------------------------------------------------------ December 8, 2004 - 07:22 : crw Ok, I found the problem and came up with a solution. I've been manually approving comments from anonymous users via the admin interface. comment_admin_edit() calls comment_save(), but neither calls _comment_update_node_statistics. I inserted the following two lines around line 952 of comment.module after the call to comment_save(): $nid = db_result(db_query('SELECT nid FROM {comments} WHERE cid = %d',$edit['cid'])); _comment_update_node_statistics($nid); Ideally, there'd be tests for all these. comment_save should produce a return value, and comment_admin_edit() shouldn't go forward unless comment_save returns true. Please excuse my lack of diff/patch-fu. :) ------------------------------------------------------------------------ December 8, 2004 - 09:58 : Junyor Bah, that function should call comment_save(). All comment changes should go through comment_save(). It would make life so much easier. I'll try to come up with an updated patch soon, but probably not before this weekend. ------------------------------------------------------------------------ December 8, 2004 - 10:28 : Dries I agree that all comment editing should go through comment_save(), yet that will require a bit of refactoring. Also, there are two 'edit comment' forms (one for users, one for administrators) that should be merged, much like we merged 'node edit' forms. Anyone? ------------------------------------------------------------------------ December 11, 2004 - 17:19 : Junyor Dries: I see that you made a change to the updating of node_comment_statistics in CVS HEAD. Do I still need to add an updated patch? Are there plans for a 4.5.2 that could use this patch? ------------------------------------------------------------------------ December 11, 2004 - 18:14 : ax i tried upgrading a 4.4 site to 4.5 yesterday and fell into the same trap as pennywit, kps, junyor, and others: the update for the node_comment_statistics table only updates forum comments and inserts num_comments 0 for all other node types. quite cheaty, this. junyors 4.5 patches (node_comment_stats-2.patch, node_comment_stats2-2.patch) seem to solve the problem for me. at least, i see proper "replies" counts in tracker and node views now. i didn't try approving / publishing / unpublishing comments, though, nor did i check other issues mentioned in the thread (user names, postgresql, ...). i applied the 2 patches to a 4.4 database / 4.5 code both before running update.php and afterwards. in the first case, there is a small glitch in that update.php throws an error: user error: Unknown table 'node_comment_statistics' DROP TABLE {node_comment_statistics} because the patch removes "CREATE TABLE {node_comment_statistics}" from update_105. this could be catched by changing to "DROP TABLE IF EXISTS {node_comment_statistics}". this is definitely a critical bug, and these patches should be applied to 4.5 as soon as possible, regardless of the "all comment editing should go through comment_save()" issue. ------------------------------------------------------------------------ December 11, 2004 - 20:53 : Jeremy(a)kerneltrap.org I've just run into this same bug, trying to upgrade from 4.4 to 4.5. It's a show stopper for me. :( Ugh, so close. ------------------------------------------------------------------------ December 11, 2004 - 23:29 : Junyor Attachment: http://drupal.org/files/issues/node_comment_stats-3.patch (7.25 KB) Changed patch for updates.inc based on feedback from ax. For 4.5. ------------------------------------------------------------------------ December 11, 2004 - 23:53 : Junyor Attachment: http://drupal.org/files/issues/node_comment_patch2-3.patch (4.2 KB) And an update for comment.module with additions to comment_save to update the node_comment_statistics table. This should cover all edit cases. For 4.5. Untested. ------------------------------------------------------------------------ December 12, 2004 - 18:40 : Jeremy(a)kerneltrap.org I tested the upgrade process on KernelTrap -- worked perfectly nearest I could tell. I'm also running with your comment.module patch. ------------------------------------------------------------------------ December 15, 2004 - 14:37 : Junyor What needs to be done for this to be included in core? ------------------------------------------------------------------------ December 15, 2004 - 15:26 : Jeremy(a)kerneltrap.org FWIW: In the days following my upgrade, I've found numerous issues with comment statistics. Specifically, many old postings list "x new of x", but clicking "x new" shows that in fact none of them were new. I have not figured out what's different about the nodes for which this is a problem compared to the nodes for which this isn't a problem. ie, it doesn't seem to be a problem with a specific node type, etc. In other words: I retract my earlier comment that the upgrade went perfectly with this patch applied. Sorry I don't have more specifics to offer, perhaps I'll have more time at a future date to help dig into this more. In any case, the patch did improve the process noticeably. ------------------------------------------------------------------------ December 15, 2004 - 15:31 : Junyor So, none of the comments said they were new or you had read them previously despite them being marked new? ------------------------------------------------------------------------ December 15, 2004 - 16:13 : Jeremy(a)kerneltrap.org > or you had read them previously despite them being marked new? Right. Comments I had already read when running 4.4 were suddenly marked as new after the upgrade to 4.5. ------------------------------------------------------------------------ December 15, 2004 - 17:50 : Junyor That sounds like a problem with history more than node_comment_statistics. I'm pretty sure this code doesn't do anything related to marking comments as new or old. ------------------------------------------------------------------------ December 15, 2004 - 21:33 : Dries If possible provide a single patch against DRUPAL-4-5 and a second patch against HEAD. Looks like the patches are no longer in sync. ------------------------------------------------------------------------ December 16, 2004 - 10:57 : Junyor I will do so soon, probably this weekend. ------------------------------------------------------------------------ December 18, 2004 - 01:42 : Jonathan Furness Ah.... that's why I am struggling with my upgrade from 4.4.2 to 4.5.1..... thank goodness I found this page. Is there a case for building a script which looks for all the records in the comments table and updates the node_comment_statistics table... for those of us who are now working in 4.5.1 with inaccurate records in node_comment_statistics table? Looking forward to the fix.... Jonathan ========== Jonathan Furness www.jonathansblog.net ------------------------------------------------------------------------ December 18, 2004 - 10:48 : Junyor Attachment: http://drupal.org/files/issues/node_comment_stats_4-5.patch (11.45 KB) Updating patch to current 4.5.1. Jonathan: Just apply this patch to your installation (from the main Drupal directory, type 'patch -p0 -u < ../node_comment_stats_4-5.patch') and run update.php. ------------------------------------------------------------------------ December 18, 2004 - 10:59 : Junyor Dries: The comment.module in HEAD makes use of the cid column in node_comment_statistics. My patches were removing that column, as it wasn't being used. Should I leave it alone afterall? ------------------------------------------------------------------------ December 20, 2004 - 07:23 : Dries The column seems to get populated though (it's not empty). If it the data is not used, you can remove it. mysql> SELECT COUNT(cid) FROM node_comment_statistics WHERE cid != 0; +------------+ | COUNT(cid) | +------------+ | 3970 | +------------+ ------------------------------------------------------------------------ December 20, 2004 - 09:27 : Anonymous Well, cid wasn't used until the change you made in revision 1.314 of comment.module. It was never set correctly or used anywhere in the code, so I simply removed it. ------------------------------------------------------------------------ December 20, 2004 - 10:40 : Anonymous Attachment: http://drupal.org/files/issues/node_comment_stats_4-5_0.patch (11.64 KB) Slightly updated patch for 4.5.1. ------------------------------------------------------------------------ December 20, 2004 - 10:41 : Junyor Attachment: http://drupal.org/files/issues/node_comment_stats_head.patch (12.08 KB) And patch for HEAD (with all CID stuff removed). ------------------------------------------------------------------------ January 4, 2005 - 10:04 : Junyor Dries: Is there anything else you need here before its commitable? ------------------------------------------------------------------------ January 4, 2005 - 15:31 : ax i too would much appreciate if this *release* *critical* bug could be fixed soon. thanks a lot! ------------------------------------------------------------------------ January 4, 2005 - 23:59 : Dries I look into this patch tomorrow (err, later today). ------------------------------------------------------------------------ January 5, 2005 - 21:37 : Dries I committed the patch to DRUPAL-4-5. I'm putting the HEAD version on hold until the revisions patch landed. Please upgrade your Drupal 4.5 sites to DRUPAL-4-5 in preparation of Drupal 4.5.2. Thanks. ------------------------------------------------------------------------ January 18, 2005 - 14:47 : rooey I hate to be a total baboon - but i'm still seeing a problem after upgrading to 4.5.2 - the "poll" block has no comment options available (stats or otherwise). Have i missed something? (or are these patches not included in the 4.5.2 release?) Thanks! ------------------------------------------------------------------------ January 18, 2005 - 14:54 : Junyor They are included in 4.5.2. Did you run the update script (it has to be run despite what the Drupal 4.5.2 announcement says)? ------------------------------------------------------------------------ January 18, 2005 - 15:38 : rooey Yeah... I did :s (assuming you're talkin' about update.php) ------------------------------------------------------------------------ January 18, 2005 - 15:40 : Junyor I'm not entirely sure what this fix has to do with the poll block, as I don't use that. This fix is to display the correct number of comments for nodes. Could you go into some more details about the problem you're having? ------------------------------------------------------------------------ January 18, 2005 - 15:46 : Jeremy(a)kerneltrap.org I'm having a similar problem. Note that if you look at the poll in a node view, the comments show up: http://kerneltrap.org/node/4536 But if you look at the poll on the front page, it doesn't list any comments: http://kerneltrap.org/ I've not taken any time to try and track this down yet. ------------------------------------------------------------------------ January 18, 2005 - 15:46 : rooey Sure... Since the upgrade from 4.4 to 4.5 the poll block lost all ability to play with comments. For example, there used to be the standard "add new comment" links etc... Now there is not :( The poll module itself *seems* to be calling the various bits of code it's supposed to, but alas, nothing is happening. Take a look at the site if it helps: http://www.lineageone.com I have jury-rigged the "quote" module to at least get people able to comment on stuff for now. ------------------------------------------------------------------------ January 18, 2005 - 15:50 : Morbus Iff Regarding the poll/comment issue, see also: http://drupal.org/node/14936. Not sure if that bug should be closed and wrapped into this Issue, or if we should move over to there as a different issue. ------------------------------------------------------------------------ January 18, 2005 - 16:01 : rooey Thanks :) Dang - and they described it so much better than me too! How do you want to proceed? ------------------------------------------------------------------------ January 18, 2005 - 16:13 : Junyor Let's take discussions to that bug report. I'll take a quick look in a couple hours to see if there's anything glaringly wrong. ------------------------------------------------------------------------ February 11, 2005 - 16:50 : Junyor Attachment: http://drupal.org/files/issues/node_comment_stats_head2.patch (11.92 KB) Synched patch with HEAD. ------------------------------------------------------------------------ February 11, 2005 - 20:01 : Dries Committed to HEAD. ------------------------------------------------------------------------ February 27, 2005 - 11:17 : Dries The upgrade did not work on drupal.org! Marking this both 'active' and 'critical' again. The code does too many queries, and th comment_count is always 1. ------------------------------------------------------------------------ February 28, 2005 - 17:21 : Junyor Dries: It looks like you already made the needed changes. Is there anything else to update? ------------------------------------------------------------------------ March 2, 2005 - 16:17 : ax this was a *4.5* bug originally. so if we don't want to have a broken 4.5, dries' latest patch [1] should be applied to the 4.5 branch, too. looking at the cvs log, this hasn't happened yet. [1] http://cvs.drupal.org/viewcvs/drupal/drupal/database/updates.inc#rev1.93 ------------------------------------------------------------------------ March 16, 2005 - 02:04 : ax does anyone care to fix this *critical* bug (== apply Dries' HEAD fix) in 4.5? maybe setting status to patch will help. ------------------------------------------------------------------------ March 20, 2005 - 17:59 : Junyor There's a further problem that needs to be addressed, too. If the comment name has a single quote, the update will throw SQL errors.

1 0

[drupal-devel] Searching of Stefan.
by Gordon Heydon 25 Mar '05

25 Mar '05

Hello, I am looking to get in contact with Stefan, user http://drupal.org/user/132 He has been doing some stuff with the image tool kits that are going in a similar direction that I want to go, but I can't seem to find his email address, or anything. Can someone please help me get in contact with him. Thanks. -- Gordon Heydon <gordon(a)heydon.com.au>

3 3

[drupal-devel] [bug] Comment Block for Anonymous Users
by timothy bennett 25 Mar '05

25 Mar '05

Issue status update for http://drupal.org/node/19405 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: timothy bennett Updated by: timothy bennett Status: active I'm running the latest CVS update of Drupal 4.6 RC (as of 23 MAR 2005), and I'm getting the following database error when an Anonymous user access my site, and the comment block is NOT populated with the latest comment links. user error: Unknown table 'n' in on clause query: SELECT DISTINCT(c.nid), c.* FROM comments c INNER JOIN node_access na ON na.nid = n.nid WHERE (na.grant_view = 1 AND CONCAT(na.realm, na.gid) IN ('all0','node_privacy_byrole_role1','node_privacy_byrole_user0')) AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 10 in /opt/lampp/htdocs/includes/database.mysql.inc on line 66. Once a user is authenticated, everything works fine. I've poked around the code some, and I'm pretty sure that "n.nid" should be "c.nid", but that is not getting built by the sql query builder (possibly in node.module). The comment block generation function in comment.module is passing a 'c' argument to the query builder, but whatever is building the query seems to be ignoring that argument and using 'n' instead. I'm trying to dig and understand how this code works, but I need a little help. Thanks! timothy bennett

2 4

[drupal-devel] [feature] new status for comments should be tracked separately from status for node
by leafish_dylan 25 Mar '05

25 Mar '05

Issue status update for http://drupal.org/node/6371 Project: Drupal Version: cvs Component: comment.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jik Updated by: leafish_dylan Status: active This is still causing problems for my users, as only comments on the first page are flagged as new. Has anybody tried to fix this? leafish_dylan Previous comments: ------------------------------------------------------------------------ March 11, 2004 - 02:46 : jik Right now, when you view a node all of its new comments are suddenly treated as no longer new. This makes it essentially impossible to keep track of which comments on a node you've already seen. The status of a comment, i.e., whether you've seen it or not, should be independent of the status of the node. ------------------------------------------------------------------------ March 11, 2004 - 05:32 : jik Attachment: http://drupal.org/files/issues/diff_3 (7.79 KB) The attached patch for your evaluation implements this functionality. The one aspect of the patch that I'm concerned about is that I chose to implement the "read comments" table using ranges rather than recording a single comment in each row, to keep the size of the table small. My concern is that since I'm using ranges, hashes can't be used directly to search the table, so performance will be bad when it gets large. ------------------------------------------------------------------------ March 11, 2004 - 06:14 : jik Attachment: http://drupal.org/files/issues/diff_4 (6.06 KB) Here's a better patch for comment.module. The rest of my last patch remains unchanged. ------------------------------------------------------------------------ March 15, 2004 - 02:57 : jik Attachment: http://drupal.org/files/issues/diff2_5 (15.13 KB) Here's a new patch against 4.4.0-rc, which also incorporates my patches for forums list should show new comments [1] and add new \"new expanded\" comment display modes [2], since they are all interrelated and it's too hard to separate them now that I've ported all my patches to 4.4.0-rc. [1] http://drupal.org//node/view/6370 [2] http://drupal.org//node/view/6376 ------------------------------------------------------------------------ March 15, 2004 - 15:10 : jik Attachment: http://drupal.org/files/issues/diff_14 (482 bytes) Found a bug. Here's an additional patch on top of the last one. ------------------------------------------------------------------------ March 15, 2004 - 16:41 : jik Attachment: http://drupal.org/files/issues/diff_15 (1.05 KB) Another bug. When I added code for purging old entries from comments_history, I forgot to take that into account in comment_num_new and comment_is_new. Patch attached. ------------------------------------------------------------------------ March 17, 2004 - 18:36 : jik Attachment: http://drupal.org/files/issues/diff_19 (1.41 KB) Another patch, to make it possible to view a comment without marking it read. We use this to display unpublished comments for moderators so that they can approve comments without changing the system's indication of whether they've read them (so they can easily read them in context later). ------------------------------------------------------------------------ March 17, 2004 - 18:37 : jik Attachment: http://drupal.org/files/issues/diff_20 (532 bytes) Another patch. This is just a bit of paranoia in the code that removes old entries from the comment history. ------------------------------------------------------------------------ March 17, 2004 - 18:45 : jik Attachment: http://drupal.org/files/issues/diff_21 (234 bytes) Yet another patch. Shouldn't try to mark a comment read if the comment ID is 0 (i.e., we're previewing a comment that doesn't exist yet!) ------------------------------------------------------------------------ March 17, 2004 - 19:05 : jik Attachment: http://drupal.org/files/issues/diff_22 (678 bytes) Yet another patch to fix a precedence error in an SQL statement. ------------------------------------------------------------------------ March 18, 2004 - 04:04 : moshe weitzman The policy here is that the latest patch in the issue should be complete. A reviewer will not look at all the patches posted and figure out which ones add up to the functionality desired. Furthermore, when one posts more than a few patches for the same issue, he may give the reviewer the impression that he is not properly testing his code before upload. reputation is key in getting the attention/trust of the review team.

1 0

[drupal-devel] [bug] Can't apply database update_128
by timothy bennett 24 Mar '05

24 Mar '05

Issue status update for http://drupal.org/node/19399 Project: Drupal Version: cvs Component: database system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: timothy bennett Updated by: timothy bennett Status: active Commit# 14491 modifies the term_node table to make both tid and nid primary keys. That is, ALTER TABLE term_node ADD PRIMARY KEY (tid,nid); However, I've got nodes (as referenced by nid) that have multiple taxonomy terms associated with them (as reference by tid). As such, the node_term table with have duplicate entries of nid, one for each term (tid) that the node is associated with. I don't believe you can make a column a primary key if the values are not unique can you? (Ref: http://drupal.org/node/19275) -- timothy timothy bennett

3 3

[drupal-devel] [support] List of bloggers
by Bèr Kessels 24 Mar '05

24 Mar '05

Issue status update for http://drupal.org/node/17030 Project: Drupal Version: cvs Component: blog.module Category: support requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch look in the menu admin. Bèr Kessels Previous comments: ------------------------------------------------------------------------ February 9, 2005 - 00:27 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.patch (1.66 KB) Small patch to show a list of bloggers. We all should know that blog.module is not meant for personal blogging, but that set aside, we do not have a way to show all bloggers, on a site as a list. This patch ads a few lines that will allow you to show that overview of blogging users. It ads a menu item, disabled by default that shows such a list. ------------------------------------------------------------------------ February 9, 2005 - 00:31 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.png (4.02 KB) Here is a small screeny that shows what this is about. ------------------------------------------------------------------------ February 9, 2005 - 00:34 : Bèr Kessels Attachment: http://drupal.org/files/issues/list_bloggers_2.png (2.25 KB) hmm. error in my png file. Here is a correct one. ------------------------------------------------------------------------ February 19, 2005 - 21:13 : Emiliano Hi Bèr Kessels! Thanks for the patch! It's really useful! :-) I just noticed what I think is a little mistake in this line: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url('blog/'.$row->uid.'/feed'), TRUE); Which I believe should end like: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url*('blog/feed/'.$row->uid)*, TRUE); Ah, and BTW, "db_rewrite_sql" didn't work for me... I just cut it off... ;-) Cheers, Emiliano. ------------------------------------------------------------------------ March 17, 2005 - 23:17 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2.patch (1.81 KB) and here is the actual patch. (i think i really need some script that tells me i did not attach a patch ;) ) ------------------------------------------------------------------------ March 17, 2005 - 23:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2_0.patch (1.71 KB) sigh. something tells me i should stop working.... a silly "F" sneaked into the previous patch. ------------------------------------------------------------------------ March 24, 2005 - 21:25 : Anonymous I applied the patch, reuploaded the blog.module and then deactivated and reactivated it. I cannot see a difference. How do I access the blog users page? Drupal 4.6rc thanks for the help.

1 0

[drupal-devel] template.php of phptemplate engine is not gpl
by Karoly Negyesi 24 Mar '05

24 Mar '05

Hi! I just checked and I see that this small but important file is not GPL. I say we shall rewrite it, in a non-OOP manner while at that. Regards NK

3 2

[drupal-devel] [support] List of bloggers
by Anonymous 24 Mar '05

24 Mar '05

Issue status update for http://drupal.org/node/17030 Project: Drupal Version: cvs Component: blog.module -Category: bug reports +Category: support requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Anonymous Status: patch I applied the patch, reuploaded the blog.module and then deactivated and reactivated it. I cannot see a difference. How do I access the blog users page? Drupal 4.6rc thanks for the help. Anonymous Previous comments: ------------------------------------------------------------------------ February 8, 2005 - 23:27 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.patch (1.66 KB) Small patch to show a list of bloggers. We all should know that blog.module is not meant for personal blogging, but that set aside, we do not have a way to show all bloggers, on a site as a list. This patch ads a few lines that will allow you to show that overview of blogging users. It ads a menu item, disabled by default that shows such a list. ------------------------------------------------------------------------ February 8, 2005 - 23:31 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.png (4.02 KB) Here is a small screeny that shows what this is about. ------------------------------------------------------------------------ February 8, 2005 - 23:34 : Bèr Kessels Attachment: http://drupal.org/files/issues/list_bloggers_2.png (2.25 KB) hmm. error in my png file. Here is a correct one. ------------------------------------------------------------------------ February 19, 2005 - 20:13 : Emiliano Hi Bèr Kessels! Thanks for the patch! It's really useful! :-) I just noticed what I think is a little mistake in this line: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url('blog/'.$row->uid.'/feed'), TRUE); Which I believe should end like: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url*('blog/feed/'.$row->uid)*, TRUE); Ah, and BTW, "db_rewrite_sql" didn't work for me... I just cut it off... ;-) Cheers, Emiliano. ------------------------------------------------------------------------ March 17, 2005 - 22:17 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2.patch (1.81 KB) and here is the actual patch. (i think i really need some script that tells me i did not attach a patch ;) ) ------------------------------------------------------------------------ March 17, 2005 - 22:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2_0.patch (1.71 KB) sigh. something tells me i should stop working.... a silly "F" sneaked into the previous patch.

1 0

[drupal-devel] Taxonomy Cleanup > Hit Me With Your Best Shot (Fire AwwWWaaYyy!)
by Morbus Iff 24 Mar '05

24 Mar '05

Song lyrics in subject lines rule. I'm tellin' ya. With the recent 98%ing of my folksonomy patch, I'm finding some time to do something that a lot of folks seem to murmur everytime taxonomy comes up: clean up taxonomy.module. While implementing free tagging, I could certainly see some of the areas responsible for the murmur, but I'd be a fool to say I saw everything. So, what I'd like to hear is every annoyance, disgust, cleanup on aisle 3, and fatal flaw of the existing taxonomy.module. My very early gameplan: First patch: * add doxygen to everything. * use menu callbacks and get rid of taxonomy_admin. * remove/condense duplicitous and useless functions. Additionally: * rewrite _save so that the term_data deletion is smarter. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

1 0

[drupal-devel] [feature] Pass include and exclude parameters to cron.php for fine grained cron timing
by robertDouglass 24 Mar '05

24 Mar '05

Issue status update for http://drupal.org/node/19173 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: robertDouglass Status: patch I think I am leaning in favor of extending cron.php in the following way: 1) Add admin screen which scans all modules for existence of cron hook 2) set a cron_interval variable for each one 3) allow admin to set an interval 4) check whether the current cron run falls outside of each module's interval before invoking its cron hook 5) before a module's cron hook gets called a {module_name}_cron_busy variable gets set. This would function like the current cron_busy now, just at a modular level. The admin would then set one cron tab to run at the smallest needed interval and could then decide on a module-by-module basis how often each is to run. How does this sound to people? robertDouglass Previous comments: ------------------------------------------------------------------------ March 20, 2005 - 11:08 : robertDouglass Attachment: http://drupal.org/files/issues/cronpatch.txt (1.99 KB) Some sites need fine grained timing for cron runs. For example, a site that relies heavily on moblogging, mailhandler or any other email based function would want to connect with the email server pretty often, say ever 2-5 minutes. On another site I'm working on we generate flat files for all of a certain node type on a regular basis, though not every 2-5 minutes. Thus the need for cron tasks on different schedules. This patch allows you to make a list of modules to either include or exclude when running cron, so that several cron tasks for one site can be defined. The default behavior in the absence of both parameters is to run all, so the patch preserves backwards compatibility. * Examples: * * runs all hooks * http://mysite.com/cron.php * * runs all hooks except the search and aggregator modules * http://mysite.com/cron.php?exclude=search,aggregator * * runs only search, archive and aggregator modules * http://mysite.com/cron.php?includ=search,archive,aggregator ------------------------------------------------------------------------ March 23, 2005 - 22:23 : Dries Isn't it possible to run all cron functions every 2-5 minutes? The impact of that should be minimal. ------------------------------------------------------------------------ March 23, 2005 - 22:33 : moshe weitzman an alternative approach is to make a quick PHP page which simply calls mailhandler_cron and any others that need to be called more frequently than normal. then call that php page from cron every couple minutes ... not so sure this complexity is worth having. ------------------------------------------------------------------------ March 24, 2005 - 08:32 : robertDouglass Whether or not this "complexity" is needed depends a lot on what you expect to do with cron. As soon as one starts aggregating not tens but several hundred RSS feeds or more, it is impossible to run cron every 2 minutes. Yet if the site depends on mailhandler keeping user moblog submissions current, 2 minutes is already about the maximum latency time acceptable. Thus the need for crons on different schedules. In terms of usage, writing ?include=mailhandler,search,event isn't so complex. On the code level, splitting that list on comma and looping over the resultant array also isn't really that complex. The patch defaults to normal behavior for people who don't need the feature, and I've seen more than one site that had to solve this problem. ------------------------------------------------------------------------ March 24, 2005 - 11:48 : Robert Castelo Could different cron runs be set to run different tasks based on a cron ID number.... For instance, set up 3 separate cron to run every hour, each one calls the cron.php page including a number variable which runs a certain set of tasks. An Admin control panel would list all cron tasks and allow administrators to split them into separate cron runs based on the number variable passed to the script when calling cron.php. ------------------------------------------------------------------------ March 24, 2005 - 12:24 : robertDouglass Robert, the id parameter is already a practical necessity for this patch if cron_busy is to be effective. I'm open to suggestions as to how we would track various cron tasks and whether they are busy. First things first, though: does anyone except me need this? I'm not going to program an admin-configurable cron mechanism unless there is demand for it. Furthermore, such a system would really be incomplete unless there were some actual mechanism for setting these cron runs up from the admin interface as well. This wouldn't be such a bad idea, I know a lot of people who still type /cron.php into their browser every day or so to updated thier sites (yes I've mentioned poormanscron). Anyway, first reactions to this patch have been cold, so maybe nobody wants it. ------------------------------------------------------------------------ March 24, 2005 - 12:39 : Robert Castelo +1 from me. I'll be needing something like this once my email newsletter is released and starts hogging cron runs. ------------------------------------------------------------------------ March 24, 2005 - 17:06 : Chris Johnson It does seem like a good idea to allow running different cron tasks at different intervals, so as to be efficient and reduce web server loads. There is little point in running tasks that do not need to be run. Many cron tasks only need to be run once to a few times per day. Note also that cron job scheduling on most Unix-variants is only within a +/- 1 minute range, so trying to run a cron program every 2 minutes is approaching the crumbling edge of being "on time."

1 0