weitzman's blog
A map from Google Analytics indicating where users come from for the groups.drupal.org web site. Note the pocket from India and the strong Europe cluster.
- 2307 reads
Jake Gordon has a great new business selling custom yearbooks. He uses Drupal to manage the data entry and photos. If you are a member of the Drupal community, please join the Yearbook. Hardcover yearbooks just might become available. Would be fun :)
- 1399 reads
Some code to hide empty CCK fields upon display.
// hide empty fields from display
if (!$items[0]['view']) return;
Put this at top of field.tpl.php, which should be copied to your theme folder as per CCK theming documentation.
- 3071 reads
I finally sent an email to the drupal development and consulting lists about the new drupaldigest web site. This site exists only to offer rss feeds. The feeds are a collection of high quality posts to Drupal's various email lists.
Thanks to Angie Byron for editing the Documentation list. Additional editors for other lists are needed.
If you haven't joined the RSS revolution yet, this might be a good time for you.
- 2184 reads
Great article about some students who have a slick automated system to podcast all lectures at their school. Usually this technology comes from MIT, but today's geek award goes to the University of Michigan School of Dentistry.
- 1220 reads
Wow, the W3C has a useful bot called Zakim for managing IRC+telephone meetings. Check it out.
- 1336 reads
In Dries Buytaert's blog, he recently reminded the Drupal community:
So let's capture that thought for future reference. Sweeping changes are required to make major advances in technology, and often times there is a lot of pain before the pay-off
I agree with Dries' premise and want to expand upon it in my own words.
Dries refers to major changes in the Drupal API which break existing modules. Often, Drupal admins/developers get angry about this breakage, and advocate that we avoid major API changes at all costs (we already avoid them where possible). They don't want to edit to their modules every 6 months or so. They want progress and backward compatibility, and don't believe that these are sometimes mutually exclusive.
I think these angry folks are missing a key idea:
We don't know what we are doing
I get the feeling that these folks think that there is a master roadmap, and all that the development team does is fill in the functions as we have time. But thats not how open source works, and especially not the Drupal project. We are making this up as we go along. We do not know what will Drupal will look like a month from now, any more than a jazz musician knows how tonight's set will sound. If we knew what we were doing, we would just design the ultimate flexible, powerful, calafragilistic API and never need to break it.
This lack of foresight leads to some seemingly silly outcomes. For example, menu callbacks in Drupal are basically responsible for the main content of any given page. They are rather central. Initially, these function s were supposed to return their content. Then we changed the API and they were supposed to print their own content. Then, we changed it again and they were supposed to return content again. Some folks wondered aloud - please make up your mind. These folks fail to realize that the Drupal project has no mind, and if it did it would be terribly conflicted.
One night my wife and I decided to invite some people over to our house to chat, drink wine and talk late into the night about the Drupal Content Management System (we've a very exciting social life). Here are some responces to that enigmatic question What is Drupal?.
Nice piece on TrollPlanet about Drupal's various audiences and aspirations.
- 1386 reads
inline.module has a nice feature where it shows all image attachments inline at the bottom of each node. this is often convenient for the node author, compared to the alternatives. this alistapart article describes a technique for automatically resizing those attachments to look pretty. nice! i hope someone can drupalize this.
- 1326 reads





