September 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Css fix: highlighted block regions on top
by fajerstarter 01 Sep '05

01 Sep '05

Issue status update for http://drupal.org/node/30094 Post a follow up: http://drupal.org/project/comments/add/30094 Project: Drupal Version: 4.6.0 Component: block.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: fajerstarter Updated by: fajerstarter Status: patch (code needs review) Attachment: http://drupal.org/files/issues/drupal_css_svn.diff (397 bytes) The highlighted block regions on the block configuration page appears below some objects on custom themes. This two rows fixes that. Hopefully a z-index of 99 is enough for most themes... fajerstarter

2 2

[drupal-devel] [bug] call by reference
by chx 01 Sep '05

01 Sep '05

Issue status update for http://drupal.org/node/30128 Post a follow up: http://drupal.org/project/comments/add/30128 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: chx Reported by: chx Updated by: chx Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/boom.patch (1.21 KB) Due to some miscommunication with killes, call by reference slipped into the revisions patch at the last minute. chx

3 5

[drupal-devel] An idea for Drupal in disaster relief efforts
by Syscrusher 01 Sep '05

01 Sep '05

Good evening, Drupalites! My brother, who is a mechanical engineer but not a computer geek, approached me with an idea for a web application that could be of help to the victims of Hurricane Katrina and other natural disasters in the future. As he was describing the idea to me, I kept thinking, "Hmmmm.....Drupal can do that. Hmmmm....Drupal can do *that*, too. And...yeah, it can do *that* as well. And...well, it could do *that* also, with just a little code tweaking." I don't have the server resources to host this, but it occurs to me that someone on the Drupal list just might be able and willing to do so. Todd (my brother) said it was fine to post the idea to the list, and if someone else wants to implement it, he's okay with that. It's not about ego or credit, it's about helping people. This isn't totally a "development" idea, because I think Drupal already has most of the features that are needed, but I'm posting to the developer list because it needs the help of people with that level of technical skill to evaluate the idea and implement it if it's found to be feasible. Apologies if this offends anyone. Since this is slightly off-topic for the list, I do suggest that responses be sent off-list to me, scott(a)4th.com. If there is enough interest, I'll set up a dedicated email list on my own server. Here's the idea... In almost any major disaster, one of the worst losses for families is the kind of irreplaceable property that represents memories. That would include things like photo albums, school ribbons, certificates and placques, kids' art work from school, and so on. Many times these items are destroyed, but not always. Sometimes wind or water carries lightweight items for many kilometers and deposits them somewhere. They end up getting thrown away because whoever finds them has no way at all to locate the owner, since the items seldom have any identifying names or addresses on them -- and that's a tragedy. It's bad enough that families lose their homes and tangible property, but to have family memorabilia survive the disaster itself but then be thrown away is a heartbreak in its own right. What Todd proposes is an Internet-based web site to unite people who find photos or other memory-items after a disaster, with the people who lost them. In essence what's needed is a large, keyword-indexed image database. Ideally, one would use some kind of image-recognition software to automatically catalog images -- especially faces -- based on visual characteristics and provide a search facility akin to Google's image-search function. But given volunteer workers, this could be done using the human brain's old-fashioned but very sophisticated image recognition capabilities. Imagine a web site where anyone could upload an image and assign taxonomy keywords to describe it. For example, you could have vocabularies for: * Item type Photograph, digital picture of an object (and different types of that, etc.), drawing, painting, color, monochrome, album or boxed collection of photos, placque or certificate, .... * Type of image (for photos only) Individual portrait, group portrait, candid activity snapshot, scenic ... * Description of main living subject(s), if applicable (multiple select) Female, male, child, senior citizen, teen, adult, infant, animals, African, Caucasian, Asian, Hispanic, couple, family with children, school class * Description of setting, if applicable Outdoors, indoors, religious setting, at home, at work, museum or exhibit, school or college, daytime, nighttime, twilight, crowded scene, city, rural * Non-living items prominent in photo, if applicable Ocean, river or lake, mountains, trees, large building, house or apartment, motor vehicles, aircraft * Descriptive items for objects (if entry is a photo of a found object) Use a free-tagging vocabulary for this * Location where found Use the "location" module to support this * General keywords not covered above Use a free-tagging vocabulary for this * Description of item in the body of the node -- searchable in the usual Drupal search index Even if you had 100K photos in the system, this level of detail would narrow most searches down to a few hundred items, which may be a bit tedious but *is* feasible for family members searching for their lost memories. How do you enable people to reclaim their items? To a certain degree, you would have to rely on trust. Maybe you simply use the "contact" module to enable them to send an email to the person who uploaded the image, and you leave it up to those individuals to work out the trust issues and arrange return of the item. Or you could use an e-commerce module with a micropayment that simply establishes the identity record for the person who reclaims an item, without actually "charging" them any substantive amount. I'm not sure how you would approach this, but there are smarter people than me on this list! To prevent inappropriate posting, you would need to have images go into a moderation queue where a team of editors could verify that they aren't porn or commercial ad banners or other icky stuff, then approve them for publication. Obviously, this would need to be hosted on a fairly beefy server, because it has the potential to get a lot of hits in a short period of time. Among the spinoff benefits something like this could bring: * Family members with an RSS reader could actually "syndicate" a search that matches a particular item type in which they have a special interest, and they would be notified when a new item of that type was posted by someone. (You'd need an "and" rather than an "or" search, probably.) * Eventually the system could be expanded to other found-belongings categories. Maybe one would even want to have subdomains, on different hosts, for various major categories, e.g., "photos.somedomain.org" and "objects.somedomain.org", with "www.somedomain.org" simply being an overview page and links to the other two servers. * At worst case, at least with photos, if someone accidentally or intentionally claims an original that isn't theirs, and the real owner later asks for it, you still at least have the scanned image uploaded to Drupal. That's better than nothing, which was what they would have had if the system were not in place. Drupal has taxonomies that make the categorization very powerful. Drupal scales well to a large number of nodes. Drupal has an embedded search engine. Drupal intrinsically organizes images along taxonomy lines. In other words, Drupal has a lot of the features that this system would need. I'm not sure if this is feasible or not. My inclination is to think that it is, given the proper server resources. It would certainly be a fantastic service for the Open Source community to provide to the real world, and it would be a project that could be re-used for future disasters that might occur anywhere in the world. This would have the incidental benefit of being *very* good public relations for the Drupal project, if it were implemented by a coalition of Drupal developers or consultants. If anyone is interested in pursuing this, and has the time and resources to devote, please feel free to take the idea and run with it. I'd appreciate an email from anyone who decides to take this on, because I'd like to be involved in helping to build or moderate the site, but there's no feeling of "ownership" of the idea. For all practical purposes, the idea is released into the Open Source community in a Creative Commons sort of way, in hopes that it can be used by someone to benefit other human beings. Kind regards, and thanks for reading. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher

1 0

Re: [drupal-devel] [wanted] mail queue
by Pat Collins 01 Sep '05

01 Sep '05

On Thu, 25 Aug 2005 08:37:57 +0200, Dries Buytaert <dries(a)buytaert.net> wrote : > > On 17 Aug 2005, at 10:46, Dries Buytaert wrote: > > Anyone with a mail background that would like to investigate http:// > > drupal.org/node/28604 ? > > > > The idea is to create a mail.inc for core that implements a mail > > queue, as well as provides common functionality such as converting > > HTML to text. > > > > It would be a centralized building block for modules like > > notify.module, project.module, subscription.module, > > simplenews.module, etc. > > Lots of people showed interest in working on this, though as far as I > know no one stepped forward to take a lead. I suggest someone > creates a _minimal_ mail.inc first. As soon that is in place, > everyone can submit patches to extend the mail queue functionality. > I've built a working mail.inc. Mail can be queued or processed currently. Mail can be of the variable type (user.module) or can be a node. Mail can be throttled per module or globally (still working out details). > A minimal mail.inc implements a mail queue, an mail-function, a cron- > function, and a setting to throttle the rate of outgoing mails. The > mail-function' should have two modes: 'send mail later', 'send mail > now'. Regardless of this mode, the accounting should be correct. We > can worry about HTML-mail, embedding images, bounces in subsequent > rounds. > The only feature from the above I haven't built is the cron-function. My coding time is limited until this weekend (job/wife/kids) so will send some code for review by Monday. Pat

1 0

[drupal-devel] [wanted] mail queue
by Dries Buytaert 01 Sep '05

01 Sep '05

Anyone with a mail background that would like to investigate http:// drupal.org/node/28604 ? The idea is to create a mail.inc for core that implements a mail queue, as well as provides common functionality such as converting HTML to text. It would be a centralized building block for modules like notify.module, project.module, subscription.module, simplenews.module, etc. -- Dries Buytaert :: http://www.buytaert.net/

9 14