August 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Patch review queue
by robertDouglass 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/28210 Post a follow up: http://drupal.org/project/comments/add/28210 Project: Drupal Version: cvs Component: base system -Category: feature requests +Category: bug reports Priority: normal Assigned to: Anonymous Reported by: robertDouglass Updated by: robertDouglass -Status: active +Status: patch (code needs review) [dirty trick] I'd like to have better ways of making issues like this show up on the devel-list. robertDouglass Previous comments: ------------------------------------------------------------------------ Thu, 04 Aug 2005 17:48:46 +0000 : robertDouglass I've had some fun clicking the "Play patch bingo!" link repeatedly and think it is a very fine addition to the Contributor links block. One thing that really impressed me was the huge number of patches that seem like a good idea, whose authors assert that the patch is ready to commit, and that have several "+1 I reviewed and liked" comments. All of this made me think a little more about the undead issue of whether we need more core committers and how patches can get reviewed and processed in a more organized manner. Then I had an idea. Here it is. In order to 1) motivate the masses of developers to review patches, 2) guarantee that patches don't get buried in the queue and never get read, 3) have a way to *measure* whether Dries and Steven can keep up on their own, why don't we implement a patch review schedule? I imagine it working something like this: * New patches are put into a first-in-first-out queue. This queue is the order in which committers will review the patch. * Committers must (must is a very flexible word here... more about expectations than rules) review the top patch before reviewing the one right in line behind it, kind of like a judge has to review court cases in a fixed order. * The "up next" patches get well advertised so that developers and those interested in a particular patch know when to do their lobbying and when to make sure that things get reviewed by a critical mass of developers so that the committer has enough support to make a decision. * Every patch review must result in a status change or update comment. This is the history or review trail of a patch. This occurs now anyway, so this is no big change but rather an acknowledgment of the expectation that the committers never "silently" look at a patch and then move it to the back of the queue. * Every patch review results in either a committ, having the patch removed from the queue (won't fix), or being sent to the back of the queue with concrete criteria and expectations for when it gets reviewed next. (I'm not suggesting that if Dries writes "remove this space and send a new patch" and someone does this 5 minutes later that the patch has to wait two weeks until it gets to the top of the list) That's the extent of what I propose to add/change. Here's what I hope that we would gain from it. I expect that the testing efforts of the developer community would become more focused, meaning we would be more likely to be testing the same patch at the same time. Why? Let's say that I have a patch in the queue and it is in place 5. That means very soon, Dries or Steven will be reviewing it. My big chance! Since I know that the opportunity is at hand and that the price of not getting it committed this time around will be high (put back to the end of the queue), I will make sure the patch still applies and then get on IRC and say "hey chx, walkah, killes and amazon, please test this patch today... it is up for review and I need some critical mass". The result will be that more eyes and intentions will be focused on the patch at that moment, which hopefully will give Dries the info he needs and has asked for when it comes to review time. Please note that I am not suggesting that committers should be forbidden from following a patch that they're interested in and committing patches from the middle of the queue. I'm proposing a system for addressing those days when they wake up in the morning and say "well, let's see.... maybe I'll review patches today. Let's take a look at that patch queue." The value of the list is that the whole world will know that very soon, the patch on the top of it will be reviewed and when it is, that is the biggest chance for a while that it will get committed. Furthermore, nobody submitting an issue will have the voice in their head saying "hope Dries is online today so he sees this patch before it gets burried in the queue". Instead you'll know that your patch *is* burried at the end of the queue, but that it will definitely, 100% guaranteed, get reviewed eventually. We can also train the masses to participate more in the review process. If the "up to bat" and "on deck" and "in the hole" issues are visible on drupal.org, and if we provide nice instructions for reviewing patches in such a way that people get the idea "oh, this is something I'm expected to do", I think we'll have a higher review rate. Another thing that such a queue would open the door for is an issue freeze that comes before a code freeze in the development cycle (of course critical bugs will always be handled ASAP and not be put in any queue). Maybe two weeks before a code freeze we can decide that all new issues will go into the queue for the next cycle, and the timing of the code freeze will depend on working through the current queue. As it is, there are dozens of small bugfixes in the queue which will likely not see the light of day before the code freeze or release. This method of organizing the queue might help give us more concrete goals for each stage in the cycle. Finally, and this is the part that is hardest to say since I love Dries and Steven and think they do a bang-up job, a system like this would make it very clear if the system isn't keeping up with demand. If we can't even make it through the whole queue once per development cycle, there is a bottleneck that is restraining our progress. Perhaps we'd decide, for example, to not increase the number of committers, but rather that we need a pre-commit team (5-10 people) who are the ones who review every patch, and only the ones they approve get sent to Dries and Steven. A solution like that would make two similar queues; the one I just described with everything in it which will get reviewed in order by memebers of the pre-committ team, and a queue for Dries and Steven that functions the same way but only contains patches that have passed the pre-commit review phase and was promoted by a member of the pre-commit team (perhaps members of the pre-commit team cannot promote their own patches). Ok - there it is. Flame me! cheers, Robert ------------------------------------------------------------------------ Thu, 04 Aug 2005 19:11:09 +0000 : robertDouglass Another benefit that I forgot to mention is that the price of ignoring crappy issues is higher. Take the case where a really important and really anticipated patch is in place 12 and the 11 issues before it are crap, meaning submitted by bad coders, not addressing important issues and generally unlikely to make core. Anyone interested in the good issue in place 12 will be saying "hey cats, can't we clean the litter box here, I mean, what is all this crap keeping us from getting to the real deal". And *whooosh*, 11 crappy issues are marked to "get a life" or at least "won't fix" and removed from the queue. The price of ignoring issues is high already; our good issues get lost in the crap. The real price we pay for this is delayed and comes in the form of a bloated queue that a core committer won't touch with a ten foot clue-bat. By requiring that we clear the crap to get to the meat the price is moved upfront, which might seem more expensive, but the slim and trim patch queue that will result will be worth it and the overall price of crappy issues will be lower.

1 0

[drupal-devel] [feature] Sort logs by ID instead of timestamp
by njivy 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/23560 Project: Drupal Version: cvs Component: watchdog.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: njivy Updated by: njivy Status: patch In watchdog.module I propose changing the key used to sort logs chronologically. Instead of using the timestamp, which is accurate only to the nearest second, we could use the log entry id ("wid" in the database). As I understand it, the IDs are assigned sequentially, so this is a good approximation to the correct order in which the events are recorded. Also, I don't know of any events that are recorded after a delay. The problem with the current sorting key arises when logged events come within 1 second of each other. The order of events is not always preserved when viewing the log because the timestamp is identical for several events. In "modules/watchdog.module" neard line 91, the word "timestamp" is replaced with "wid": $header = array( ' ', array('data' => t('Type'), 'field' => 'w.type'), array('data' => t('Date'), 'field' => 'w.wid', 'sort' => 'desc'), array('data' => t('Message'), 'field' => 'w.message'), array('data' => t('User'), 'field' => 'u.name'), array('data' => t('Operations'), 'colspan' => '2') ); Preliminary testing suggests this is a good tweak. njivy

7 7

[drupal-devel] [bug] too much information stored during a profile edit
by killes 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/21515 Post a follow up: http://drupal.org/project/comments/add/21515 Project: Drupal -Version: 4.6.0 +Version: cvs Component: user.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: fago Updated by: killes(a)www.drop.org Status: patch (code needs review) We are currently addressing this issue through a more general rewrite of the form subsystem. For discussion about it see here: http://lists.drupal.org/archives/drupal-devel/2005-06/msg00091.html killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Thu, 28 Apr 2005 16:07:26 +0000 : fago as i already mentioned in this post [1] some time ago, arbitrary data can be stored in the serialized data field of the user table. example: go to my account, save the page local, edit it to send the "post" data to the website and edit an form name to edit[somethingnew] und press save -> $somethingnew will be saved serialized in the data field i think the fault is in user_edit (on line 1145) where user_save() is called without checking $edit completely. however, i 've felt like that's known and tolerated, so i did, the a little bit missunderstood, post above first. but i think, it's not acceptable to save just everything, what is coming in with the form data... what's if a bad guy saves 1GB of nonesense in my database? furthermore it will be loaded into the memory everytime user_save is called - seems to me to be a nice possibilty for a DOS. [1] http://drupal.org/node/17744 ------------------------------------------------------------------------ Thu, 28 Apr 2005 18:13:51 +0000 : moshe weitzman i think apache/php have limits on how much can be posted. if you are worried, perhaps use those settings. ------------------------------------------------------------------------ Thu, 28 Apr 2005 19:53:36 +0000 : fago yes, but then it's still possible to inject data in little pieces by using a new name every time. further you can't limit the size too much, because file uploading should also work. ------------------------------------------------------------------------ Sun, 01 May 2005 20:30:51 +0000 : fago Attachment: http://drupal.org/files/issues/saveform.patch (4.38 KB) i've written a patch, so that $edit is checked before. unfortunately i couldn't see a better method than introducing a new hook type for hook_user 'saveform' for which each module has to return an array of values, which it wants to be saved. as an affect some modules have to be changed to work correctly after applying this patch :( my patch (for the 4.6 branch) includes the changes for profile.module and contact.module and for the user.module of course. what do you think about this? i think something like this is necessary. consider a module, which introduces profile fields, which can only be edited by administrative users. and yes of course, i don't like it, if users are able to fill up there user object with additional variables ;) ------------------------------------------------------------------------ Sat, 07 May 2005 00:08:18 +0000 : fago Attachment: http://drupal.org/files/issues/saveform_0.patch (4.52 KB) unfortunately i noticed some mistakes in the previous patch. (module_invoke doesn't reference $edit, but then i patched profile.module to use the saveform hook for saving.) i've attached a new patch.

1 0

[drupal-devel] Release critical bugs for August 04, 2005
by drupal-devel＠drupal.org 04 Aug '05

04 Aug '05

/ bug reports email spam filtering does not "see" email addresses when they are NOT preceded by a word age: 28 weeks 4 days url: http://drupal.org/node/15654 / bug reports Very serious bug in node display age: 15 hours 38 min url: http://drupal.org/node/28116 / bug reports Blank page when doing user login directly by using user/login URL age: 2 days 8 hours url: http://drupal.org/node/27996 404 sites shown twice age: 2 days 8 hours url: http://drupal.org/node/27990 js addLoadEvent not working. age: 4 days 1 hour url: http://drupal.org/node/27884 Bug in forum.module with postgresql (?) age: 6 days 21 hours url: http://drupal.org/node/27665 Forum bug with drupal 462 age: 6 days 21 hours url: http://drupal.org/node/27663 enable MySQL client side for UTF8 age: 2 weeks 2 days url: http://drupal.org/node/26990 Drupal 4.6.2 Doesn't allow login (IIS 5.1, PHP 5.0.4) assigned: bigeye age: 2 weeks 5 days url: http://drupal.org/node/26780 Problem in the 4.6.2 upgrade - node.module age: 4 weeks 2 days url: http://drupal.org/node/26342 postgresql autocomplete code age: 5 weeks 8 hours url: http://drupal.org/node/26027 Accidentally Deleting Forums Vocabulary in Categories Breaks Forums? age: 8 weeks 5 days url: http://drupal.org/node/24274 Taxonomy Multiple Hierarchy doesn't display children for all its parent age: 9 weeks 1 day url: http://drupal.org/node/24023 PG_QUERY ERROR - LOCK TABLES - IMPLEMENTATION FAULT. age: 11 weeks 3 days url: http://drupal.org/node/22911 UTF-8 node title gets truncated at wrong position age: 15 weeks 6 days url: http://drupal.org/node/20537 database table "term_node" not updated when removing a term from a node under editing and submitting age: 16 weeks 2 days url: http://drupal.org/node/20315 Reassigning a node to a different term does not work properly age: 16 weeks 3 days url: http://drupal.org/node/20278 4.6 aggregator showing/not interpreting HTML tags age: 17 weeks 4 days url: http://drupal.org/node/19874 New submit error, non-admin user, postgresql database assigned: adrian age: 21 weeks 1 day url: http://drupal.org/node/18552 When I delete a user, any forum in which s/he has commented also disappears. assigned: Jill6q age: 24 weeks 13 hours url: http://drupal.org/node/17428 Change to sesssion.inc violates UID database constraint age: 28 weeks 4 days url: http://drupal.org/node/15666 forum.module problem with postgresql v7.4.1 age: 29 weeks 2 days url: http://drupal.org/node/15411 PHP 5 gives error when session table has no session assigned: adschar age: 29 weeks 2 days url: http://drupal.org/node/15399 Argument NOT must be type boolean age: 37 weeks 2 days url: http://drupal.org/node/12950 Comments in approval queue still show up in tracker age: 41 weeks 4 days url: http://drupal.org/node/11647 Twin problems with comments assigned: Junyor age: 42 weeks 6 days url: http://drupal.org/node/11366 Fatal error: Call to undefined function: drupal_set_html_head() age: 49 weeks 1 day url: http://drupal.org/node/10317 user error: Duplicate entry assigned: Kjartan age: 1 year 34 weeks url: http://drupal.org/node/4428 / feature requests Filter the title to allow HTML comments age: 1 week 6 days url: http://drupal.org/node/27205 Novel Module Creation Request age: 7 weeks 3 days url: http://drupal.org/node/24856 moving pages en masse age: 17 weeks 6 days url: http://drupal.org/node/19754 Taxonomy module should use nodeapi 'load' age: 21 weeks 12 hours url: http://drupal.org/node/18631 Auto PHP memory maximisation age: 23 weeks 2 days url: http://drupal.org/node/17663 Allow named anchors to work without specifying full path to node age: 1 year 36 weeks url: http://drupal.org/node/4213 / support requests blocks age: 6 weeks 2 days url: http://drupal.org/node/25378 Problem with Forums age: 29 weeks 5 days url: http://drupal.org/node/15299 / bug reports search over fields.inc fields conceptual error age: 39 weeks 6 days url: http://drupal.org/node/12259 fields.inc screws up with multible multiselect fields age: 39 weeks 6 days url: http://drupal.org/node/12257 / feature requests event.module support of repeating/recurring events? assigned: thehunmonkgroup age: 1 year 37 weeks url: http://drupal.org/node/4122 / bug reports Menu item not showing age: 43 weeks 5 days url: http://drupal.org/node/11210 / bug reports segmentation fault related to filestore age: 1 year 44 weeks url: http://drupal.org/node/3001 / bug reports file size bug age: 7 weeks 5 days url: http://drupal.org/node/24728 / bug reports gallery.module doesn't synch passwords when they're changed age: 6 days 13 hours url: http://drupal.org/node/27702 Full screen slideshow in Gallery module is not working (erroring out on the wrong URL) age: 4 weeks 8 hours url: http://drupal.org/node/26479 Drupal session being logged out each time gallery module is called age: 5 weeks 6 days url: http://drupal.org/node/25614 Gallery error age: 14 weeks 2 days url: http://drupal.org/node/21290 Fatal Error: variable_get() age: 19 weeks 3 days url: http://drupal.org/node/19189 No Gallery Image Block age: 19 weeks 6 days url: http://drupal.org/node/19045 Mini applet can't find gallery at url / age: 20 weeks 4 days url: http://drupal.org/node/18785 Fatal error: Undefined class name 'galleryembed' age: 23 weeks 1 day url: http://drupal.org/node/17746 / support requests Can't Embed Gallery into Drupal age: 22 weeks 4 days url: http://drupal.org/node/18029 / bug reports Drupal-4.4-rc breaks registration setups and groups.module age: 1 year 20 weeks url: http://drupal.org/node/6392 / bug reports Term not created age: 5 days 19 hours url: http://drupal.org/node/27756 image module fails on dual site configuration age: 3 weeks 5 hours url: http://drupal.org/node/26657 Editing a previously uploaded and thumnailed image loses the thumbnail. age: 6 weeks 1 day url: http://drupal.org/node/25465 Cannot upload .jpgs age: 22 weeks 3 days url: http://drupal.org/node/18076 Image.Module does not know the correct filename age: 37 weeks 1 day url: http://drupal.org/node/13032 / support requests Images are there but not showing assigned: Stepfordtwit age: 1 week 12 hours url: http://drupal.org/node/27615 Image Module Permissions age: 4 weeks 3 days url: http://drupal.org/node/26280 path problems on upgrading... age: 13 weeks 3 days url: http://drupal.org/node/21725 / bug reports RSS "no element found at line 1" age: 4 weeks 5 days url: http://drupal.org/node/26185 Outdated help texts age: 1 year 1 day url: http://drupal.org/node/9692 Import doesn't like XML/RSS feeds with no Title element age: 1 year 9 weeks url: http://drupal.org/node/8128 / tasks move XML-parser into an inclde file. age: 6 weeks 1 day url: http://drupal.org/node/25439 / feature requests Notify exposes Group creation age: 1 day 3 hours url: http://drupal.org/node/28084 Notify.module ignores the true submission queue age: 1 year 40 weeks url: http://drupal.org/node/3765 / feature requests Internationalization support for PDF assigned: TheLibrarian age: 1 year 18 weeks url: http://drupal.org/node/6795 / bug reports Reminder email links don't work age: 5 weeks 5 days url: http://drupal.org/node/25677 / bug reports access control problems age: 1 week 5 days url: http://drupal.org/node/27273 Download link is wrong age: 6 weeks 2 days url: http://drupal.org/node/25363 Projects not listed and page not complete age: 9 weeks 2 days url: http://drupal.org/node/23956 Date for latest is incorrect age: 16 weeks 14 sec url: http://drupal.org/node/20485 Invalid link to release files age: 23 weeks 3 days url: http://drupal.org/node/17625 Node body not complete w/o releases age: 25 weeks 5 days url: http://drupal.org/node/16733 blank page after install age: 26 weeks 1 day url: http://drupal.org/node/16575 / support requests Help with everything - nothing seems to work in the latest build age: 36 weeks 2 days url: http://drupal.org/node/13310 / bug reports Can't get the inline tag to show series age: 12 weeks 1 day url: http://drupal.org/node/22520 / feature requests Request to generate email for all content changes/additions, including comments age: 2 weeks 4 days url: http://drupal.org/node/26824 / bug reports javascrip downloads square.gif for every category age: 24 weeks 1 day url: http://drupal.org/node/17366

1 0

[drupal-devel] [feature] Themeable profile list patch for profile.module
by ejort 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/20479 Post a follow up: http://drupal.org/project/comments/add/20479 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal Assigned to: vfilby Reported by: vfilby Updated by: ejort -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/profile.module.theme_profile_list.patch (2.17 KB) Hi, This is a patch providing the same thing, but without taking the database code into the theme_profile_list function. I've had this running on one of my sites [1] for a while and found it necessary to output a table listing member contact details (note: there aren't many profile fields accessible by anonymous users in that example, but you get the idea). Unfortunately I never got around to separating it from my other profile.module modifications until now. Let me know what you think. Cheers, Eric [1] http://www.renegades.com.au/?q=members/contact-lists/all-men ejort Previous comments: ------------------------------------------------------------------------ Thu, 14 Apr 2005 03:16:04 +0000 : vfilby Attachment: http://drupal.org/files/issues/profile-themeable-user-list.patch (2.08 KB) Here is a patch for the profile module that provides a way to theme user lists. I simply took the last part of the giant if in profile_browse, moved it to a new function called theme_profile_list and mde profile_browse call the new function. ------------------------------------------------------------------------ Thu, 30 Jun 2005 04:52:17 +0000 : moshe weitzman looka useful ... please provide unified diff format. as per http://drupal.org/handbook ------------------------------------------------------------------------ Thu, 07 Jul 2005 10:39:32 +0000 : robertDouglass It doesn't really look suitable for theming, though, due to all the database logic. To make this really a theme function, you'd have to prepare the data into some variables that you can get by calling function A, and make a theme function B that outputs the variables. Things that can't be in theme functions include SQL and user access logic.

1 0

[drupal-devel] Drupal Installer? I have done some similar work
by NSK 04 Aug '05

04 Aug '05

Hi How's the Drupal Installer project going? If you haven't started on it you could use a small installer I made. It is available from http://nsk.wikinerds.org/won/ Just download the tar gz and look inside the setup directory. The tar gz is licensed under GPL2 (no later versions) but for the purposes of merging it with Drupal you can consider all the code in the tar gz to be licensed under GPL2 and later versions. Some screenshots are available at http://www.wikinerds.org/download/ If you use it, just add my name somewhere, like a CONTRIBUTORS.txt file and the source code. Basically what the installer does is writing any SQL to a database, without code changes. You provide the SQL in ASCII files. It supports database prefix, and it can create a MySQL user. My code is undocumented, but I can answer questions if you have any and you wish to use it. -- NSK http://portal.wikinerds.org

1 0

[drupal-devel] [feature] Parse atom feeds
by Prometheus6 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/13941 Post a follow up: http://drupal.org/project/comments/add/13941 Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: Prometheus6 Reported by: Capnj Updated by: Prometheus6 Status: patch (code needs review) Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_CVS.txt (2.35 KB) Because the aggregator would always gather enough information todownload an Atom feed, the previous patch focused on parsing items/entries correctly. This patch adds more complete parsing of the feed's channel data (site link, subtitle/description, logo). Now all the feed and item fields will be properly updated. Prometheus6 Previous comments: ------------------------------------------------------------------------ Sun, 05 Dec 2004 23:26:00 +0000 : Capnj I've seen mention elsewhere on drupal.org but don't see a feature request, so here goes. The news aggregator is a great piece of Drupal as far as I'm concerned and I'd sure like to see it read all the sources out there, have the 'blog this' function, and also have a tool for browsers to generate a blog entry from a web page (like MT had). Is that a big enough request? LOL Thanks for all that everyone does here. Great stuff! gil ------------------------------------------------------------------------ Tue, 07 Dec 2004 17:38:31 +0000 : drumm RSS 2.0 feeds should work in 4.5.0 and earlier. ------------------------------------------------------------------------ Mon, 14 Feb 2005 16:04:32 +0000 : georgehotelling I've hacked Magpie [1] support into the Drupal aggregator, so it can support Atom. If you have a Drupal site and want the code, you can get it from http://george.hotelling.net/projects/magpie-aggregator-4.5.2.tgz [2] I'm not sure if I'm supposed to create a patch or what, but I needed this for ArborBlogs.com [3] and figured some other people would benefit from it. [1] http://magpierss.sourceforge.net/ [2] http://george.hotelling.net/projects/magpie-aggregator-4.5.2.tgz [3] http://www.arborblogs.com/ ------------------------------------------------------------------------ Tue, 15 Mar 2005 04:04:42 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD.txt (5.46 KB) Very nice. I hacked aggregator.module for 4.6 using your module as a guide...well, frankly by ripping out great chunks of code for my use. ------------------------------------------------------------------------ Thu, 28 Jul 2005 22:21:11 +0000 : Boris Mann Can someone roll a patch for this? Would be a good addition for 4.7 now that Atom is at 1.0. ------------------------------------------------------------------------ Fri, 29 Jul 2005 01:49:42 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/magpie_aggregator.zip (7.87 KB) A patch would require the Magpie include files and wholly restructures the way the feeds are parsed...the Magpie code would handle all the feeds, not just Atom. That said, the attached zip file has the necessary includes and a patch to CVS. ------------------------------------------------------------------------ Fri, 29 Jul 2005 03:36:59 +0000 : Steven Magpie RSS duplicates a lot of functionality that is already in Drupal. We decided a long time ago that we would not use it. Porting Atom parsing into the current aggregator can't be that hard. ------------------------------------------------------------------------ Mon, 01 Aug 2005 16:38:53 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD_0.txt (1.93 KB) Since I'm messing around with the aggregator module anyway... I developed this around Atom 0.3 feeds this weekend, but I don't see anything in Atom 1.0 that should break it. ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:00:50 +0000 : Eaton +1 on that patch. Running it now on my test site and everything looks great. ------------------------------------------------------------------------ Tue, 02 Aug 2005 16:24:54 +0000 : Bèr Kessels a small issue, whe do not use if ($data) $items[$item][$tag] .= $data; please just use if ($data) { $items[$item][$tag] .= $data; } ------------------------------------------------------------------------ Wed, 03 Aug 2005 02:18:54 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD_1.txt (1.99 KB) Not a problem. Here's the corrections. ------------------------------------------------------------------------ Wed, 03 Aug 2005 16:14:14 +0000 : Dries If this is all it takes to parse Atom feeds (to some extend), I'm all for it. Code looks OK. Set to 'ready to be committed' after some testing. ------------------------------------------------------------------------ Wed, 03 Aug 2005 18:59:20 +0000 : kika anybody up for a testing suite tests? http://intertwingly.net/wiki/pie/FormatTests ------------------------------------------------------------------------ Wed, 03 Aug 2005 20:07:37 +0000 : Prometheus6 That would be for the Atom module.

1 0

[drupal-devel] Spam module 2.0, Looking for beta testers
by Lists 04 Aug '05

04 Aug '05

Hello, I have re-written the spam module, and now have a new version that is available for anyone willing to beta test. In re-writing the module, I have also changed the license from the GPL to the Modified BSD license. Because of this licensing change, the module can't (currently) be distributed from the spam project page [1]. Instead, find it here [2]. New Features: - supports spam expiration (aka auto-deletion of old spam content) - detects the same identical content being posted repeatedly - can display message to users when content is blocked by filters - logging, allows you trace how the spam filter is weighing your content Other improvements: - major code cleanup, moving redundant code into functions - heavily commented - uses one database table for tracking all spam content types - simplified tokenizer - numerous major and minor bug fixes Left to be done (patches welcome): - create upgrade script from old spam module - update README.txt and INSTALL.txt - port spam_surbl.module - update trackback.module patch to support new api Many bugs have been fixed in this new version, but as it is a rewrite it is possible that I've also introduced new bugs. As for upgrading from the old version, right now your best bet is to drop your old tables and start over. The module no longer attempts to collect generic statistics as they weren't remotely accurate anyway. Feedback is welcome. Patches are even more welcome. Thanks, -Jeremy [1] http://drupal.org/project/spam [2] http://kerneltrap.org/jeremy/drupal/spam/

1 0

[drupal-devel] [feature] Put all throttle settings in the same place
by drumm 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/27818 Post a follow up: http://drupal.org/project/comments/add/27818 Project: Drupal Version: cvs Component: throttle.module Category: feature requests Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (code needs review) Attachment: http://drupal.org/files/issues/throttle-modules_0.patch (9.54 KB) drumm Previous comments: ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:21:16 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_12.png (37.86 KB) Screenshot 1/2. The modules admin page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:24:10 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_13.png (15.81 KB) Screenshot 2/2. The throttle modules page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:29:32 +0000 : drumm Attachment: http://drupal.org/files/issues/throttle-modules.patch (9.73 KB) This patch needs http://drupal.org/node/27804. The throttle configuration is currently spread out on the modules page and the block configuration page. This patch moves the module throttling to a local task next to the throttle settings page. I have not worked on moving block throttling yet since I want to see what the reaction to this first part is. If this is comitted I plan to move the block throttle checkboxes and continue improving the modules page. With less interface elements the modules page can be made even simpler that is it now. ------------------------------------------------------------------------ Sat, 30 Jul 2005 19:48:47 +0000 : drumm forgot to label it as a patch ------------------------------------------------------------------------ Mon, 01 Aug 2005 20:21:27 +0000 : factoryjoe +1 for moving throttle/performance settings to it's own page/tab -1 for showing disabled modules; only list those that can be disabled Issues: * "turning on" throttling seems counter intuitive... like, all the modules should be checked as given priority... then you DESELECT in order to take it off the priority list. I guess the current UI is opposite of most conventions... where you start with everything enabled and then take things /off/ the list. * The list is not a scalable UI. If I have 60 modules (*cough cough*) I'll see the first 10-15 and ignore the rest. If you could sort by processing weight ("these modules suck up tonnes of memory! disable these first!") or by functionality, the list would be much more manageable. * I still think "throttle" is a terrible name. Like "taxonomy" people don't readily know what it means and avoid it like the plague. From a marketing perspective, this is bad news for Drupal since it may appears that Drupal is slow when it really just needs to have its *performance* settings tweaked. ------------------------------------------------------------------------ Mon, 01 Aug 2005 20:52:00 +0000 : killes(a)www.drop.org -1 for adding yet another config page. teh throttle setting is fine where it is. ------------------------------------------------------------------------ Wed, 03 Aug 2005 23:05:03 +0000 : drumm Here is an updated patch which has all of the modules checked and may be unchecked to disable them while throttled. It removes all disabled modules and required modules from the list. The page name 'throttle' is generated directly from the module's name. Changing the module name or changing the mechanism which sets that title is out of the scope of this patch. Ordering by processing time or functionality can be done given a decent algorithm to do that. Figuring out such an algorithm would be out of the scope of this patch too since it would need some sort of monitoring functionality as well. I think alphabetical is fine. Does anyone have more feedback on creation of this local task page or keeping it in the modules page?

1 0

[drupal-devel] [feature] Put all throttle settings in the same place
by drumm 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/27818 Post a follow up: http://drupal.org/project/comments/add/27818 Project: Drupal Version: cvs Component: throttle.module Category: feature requests Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (code needs review) Here is an updated patch which has all of the modules checked and may be unchecked to disable them while throttled. It removes all disabled modules and required modules from the list. The page name 'throttle' is generated directly from the module's name. Changing the module name or changing the mechanism which sets that title is out of the scope of this patch. Ordering by processing time or functionality can be done given a decent algorithm to do that. Figuring out such an algorithm would be out of the scope of this patch too since it would need some sort of monitoring functionality as well. I think alphabetical is fine. Does anyone have more feedback on creation of this local task page or keeping it in the modules page? drumm Previous comments: ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:21:16 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_12.png (37.86 KB) Screenshot 1/2. The modules admin page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:24:10 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_13.png (15.81 KB) Screenshot 2/2. The throttle modules page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:29:32 +0000 : drumm Attachment: http://drupal.org/files/issues/throttle-modules.patch (9.73 KB) This patch needs http://drupal.org/node/27804. The throttle configuration is currently spread out on the modules page and the block configuration page. This patch moves the module throttling to a local task next to the throttle settings page. I have not worked on moving block throttling yet since I want to see what the reaction to this first part is. If this is comitted I plan to move the block throttle checkboxes and continue improving the modules page. With less interface elements the modules page can be made even simpler that is it now. ------------------------------------------------------------------------ Sat, 30 Jul 2005 19:48:47 +0000 : drumm forgot to label it as a patch ------------------------------------------------------------------------ Mon, 01 Aug 2005 20:21:27 +0000 : factoryjoe +1 for moving throttle/performance settings to it's own page/tab -1 for showing disabled modules; only list those that can be disabled Issues: * "turning on" throttling seems counter intuitive... like, all the modules should be checked as given priority... then you DESELECT in order to take it off the priority list. I guess the current UI is opposite of most conventions... where you start with everything enabled and then take things /off/ the list. * The list is not a scalable UI. If I have 60 modules (*cough cough*) I'll see the first 10-15 and ignore the rest. If you could sort by processing weight ("these modules suck up tonnes of memory! disable these first!") or by functionality, the list would be much more manageable. * I still think "throttle" is a terrible name. Like "taxonomy" people don't readily know what it means and avoid it like the plague. From a marketing perspective, this is bad news for Drupal since it may appears that Drupal is slow when it really just needs to have its *performance* settings tweaked. ------------------------------------------------------------------------ Mon, 01 Aug 2005 20:52:00 +0000 : killes(a)www.drop.org -1 for adding yet another config page. teh throttle setting is fine where it is.

1 0