Sep 20 2012
Sep 20

Book cover: Sakai CLE Courseware Management: The Official GuidePackt, publisher of many worthy books about technology topics that have helped me know what I'm doing, is about to publish their 1000th book.

Many Packt titles, such as Sakai CLE Courseware Management: The Official Guide, books on Drupal, and jQuery have been my guides to the open-source technologies I use every day.

To celebrate, Packt is giving away gifts to their readers who register before 30 September 2012 over at Packt.com.

Thank you Packt, and congratulations!

Aug 11 2012
Aug 11

The Drupal Association can not take credit for the amazing success of the Drupal project, but will highlight the success of the community in its efforts to keep supporting the project. We are supported by Individuals and Organizations who become yearly members. Our membership makes the Drupal.org infrastructure possible and supports community initiatives. Organization Membership information is below the Individual Memberships, scroll down to see. Annual membership for individuals supports the Drupal Association and its community projects.

Aug 11 2012
Aug 11

The Drupal Association is an organization dedicated to helping the open-source Drupal CMS project flourish. We help the Drupal community with funding, infrastructure, education, promotion, distribution and online collaboration at Drupal.org. Funds to support these programs, and the Association staff come from memberships, supporting partners, sponsorships, donations, and volunteers. Join us to help ensure a creative and exciting future for Drupal!

Apr 23 2010
Apr 23

After a very long week full of Webvisions goodness we settled into our cozy little studio with an old friend of the show, Nate Angell. As always he was bursting with excitement for the projects he’s working on. We managed to tackle three of them in the Tech Edition: hideNtweet, a reevaluation of the standardized testing system in our schools and DayOn.

Then we moved on to afterhours where the chatroom was invaded by trolls. Most of the trolls were kind of lame or just plain crass but a few of them had inventive insults that Dr Normal and I were able to laugh about even later. Dr Normal had to shut the chat down on too many occasions to count but he always turned it back on. Which leads to the title for our Afterhours episode: Afterhours With Xolotl and Chatroom FAIL.

Sep 29 2009
Sep 29

Portland State's Drupal-driven home page.

Aug 24 2009
Aug 24

Drupal 6 JavaScript and jQuery CoverI just finished reading a new book, Drupal 6 JavaScript and jQuery, by Matt Butcher. The book title makes it sound highly specialized, but in fact it's a great resource for a variety of readers, from Drupal beginners to JavaScript experts. Best of all, the book brings together two of my favorite open source technologies: Drupal and jQuery. If you aren't already a fan, I've written elsewhere about Drupal's benefits, and for jQuery, one statement should win you over: query HTML content using plain old CSS selectors!

Matt does a great job leading the reader from very basic principles to advanced concepts, thoroughly enough to initiate less experienced coders, but quickly enough to get everyone to real meat right away. You will get immediate value from this book whether you are a web designer just starting out with Drupal and/or JavaScript, an intermediate coder looking to expand your skills with either Drupal or JavaScript, or an advanced Drupalista or JavaScriptor looking to bring the two together.

Because I reach under the Drupal hood only sporadically, I love how how Matt quickly covers all the basic terminology and functionality of Drupal, JavaScript, and jQuery to remind me how they all work, and work together. I can see turning to this book as a basic reference again and again.

Best of all, in each chapter Matt provides a hands-on project worth doing for it's own sake as well as for the added learning. Trying it out, I modified the rotating sticky node teasers project in Chapter 3 to complete something I've been wanting to do here on my blog for some time: make my Flickr-stream header images rotate dynamically. Read more about exactly how I did it. If I can do something like this in just a few minutes, that tells you a lot about the power and simplicity of Drupal and jQuery together, and Matt's ability to make it all understandable.

Ready to dip your toes or delve deeper into how jQuery let's you "write less, do more" with Drupal? You can buy Matt's Drupal 6 JavaScript and jQuery book directly from the Packt website.

FYI: I drafted this entire review sitting on an Oregon coast beach using the Evernote iPhone app. Pretty nice working conditions ;)

May 08 2009
May 08

Interested in user experience and online pedagogy? Learn how you can benefit from and contribute to two new efforts to share best practices across open source projects: The Fluid Project's Open Source Design Pattern Library and OpenedPractices.org, a community of practice for teaching and learning with open/community-source tools.
With co-presenter, Allison Bloodworth.

Apr 09 2009
Apr 09

Something odd happened to me today. I ran into a complete stranger on the Internet.

I signed into chat, and almost immediately had the conversation below with someone I didn't know, going by the handle "toweringcoho". I was at a largish gathering and had bonjour turned on as usual, so assumed it was someone in the room—even though I didn't bother to look to see what chat connection toweringcoho was using.

A quick Google search suggested that "toweringcoho" is the name of one of a series of IM bots that randomly connect to otherwise unconnected chat users.

And that's how I met Sunil Khiatani from Hong Kong. It took a while for both of us to figure out that we were NOT talking to robots, and a bit longer to introduce ourselves. In the end, we had a worthy conversation, got to know each other a bit, and went on our ways.

I'm not sure if these IM bots are supposed to be malicious, but I liked what happened. It was like going on a kind of unintentional dérive in text only.

6:45:55 PM toweringcoho: Hi, Billy Mays here with another fantastic coho.
6:46:40 PM Nate Angell: wish I knew what that meant...
6:46:52 PM toweringcoho: hmmm
6:46:59 PM toweringcoho: take a wild guess
6:47:04 PM Nate Angell: salmon?
6:47:23 PM toweringcoho: you definitely aren't turing complete
6:47:39 PM Nate Angell: human error
6:48:06 PM toweringcoho: are you related to skynet?
6:48:51 PM Nate Angell: maybe on the distaff side
6:49:14 PM toweringcoho: ahh
6:50:01 PM toweringcoho: here's the thing though, will skynet be porgrammed with the 3 robot laws and if so would it still be able to nuke us?
6:50:28 PM Nate Angell: did the 3 robot laws really work out? have to refer to the text
6:50:54 PM toweringcoho: dunno about the text, but in the movies they didn't
6:51:55 PM Nate Angell: isn't the book always better than the movie?
6:52:21 PM toweringcoho: naw
6:52:28 PM toweringcoho: fight club is better movie wise :D
6:53:22 PM Nate Angell: didn't read fight club
6:55:24 PM toweringcoho: so who are you? :P
6:55:41 PM Nate Angell: @xolotl
6:55:56 PM toweringcoho: huh?
6:56:11 PM Nate Angell: you definitely aren't turing complete
6:56:30 PM toweringcoho: yeah yeah
6:56:57 PM Nate Angell: that should be enough to go on
6:57:20 PM toweringcoho: naw it isn't
6:57:45 PM Nate Angell: there's this thing called google...
6:58:15 PM toweringcoho: nad what should I be searching for
7:01:19 PM Nate Angell: @xolotl
7:01:34 PM Nate Angell: it's a pretty unique character string
7:02:31 PM toweringcoho: you're nate angel?
7:03:23 PM Nate Angell: no, I'm Nate Angell
7:04:05 PM toweringcoho: ah close enough
7:04:08 PM Nate Angell: or, perhaps A dog-like deity, Double of Quetzalcoatl
7:04:10 PM toweringcoho: how come you're contacting me :P
7:04:25 PM Nate Angell: you contacted me
7:04:48 PM toweringcoho: I did???
7:05:10 PM Nate Angell: I think there's an AIM chat robot that connects random users
7:05:14 PM Nate Angell: and we are victims
7:05:30 PM toweringcoho: ahhh
7:05:36 PM toweringcoho: strange
7:05:58 PM toweringcoho: thi is my yahoo account though
7:07:41 PM Nate Angell: i think they are all connected
7:07:52 PM Nate Angell: so you know me, want to iintroduce your self?
7:08:16 PM toweringcoho: alright
7:08:27 PM toweringcoho: I'm Sunil Khiatani, I'm a coder in Hong Kong :D
7:08:37 PM Nate Angell: very cool
7:08:40 PM Nate Angell: what do you code?
7:08:56 PM Nate Angell: Sunil Khiatani doesn't sound very HK ;)
7:09:21 PM toweringcoho: at the moment, stuff for work. Web Services in ASP.NET and C# :\
7:09:30 PM Nate Angell: sorry
7:09:33 PM toweringcoho: been trying to do OSS coding but I've been lazy
7:09:41 PM Nate Angell: that would be better!
7:09:53 PM Nate Angell: as you may have learned, I'm a bit of an OSS zealot
7:10:22 PM toweringcoho: haha yeah a lot of people freak out when I tell them that I'm an indian born in Hong Kong that has a fairly american accent
7:10:31 PM toweringcoho: yeah I think I did, what do you code ?
7:10:34 PM Nate Angell: i guess HK has all types
7:10:36 PM toweringcoho: bbs.. loo
7:10:50 PM Nate Angell: I'm not much of a coder
7:11:13 PM Nate Angell: but I usually evangelize around http://sakaiproject.org http://drupal.org and http://openid.net
7:11:35 PM Nate Angell: there are many worthy projects, depending on your interests
7:11:50 PM Nate Angell: I encourage you to broaden your skills/interests with OSS
7:16:25 PM toweringcoho: I have a few interests
7:16:46 PM toweringcoho: but i think I should focus on the KDE desktop, it's waht i like and use the most
7:19:26 PM Nate Angell: that's a worthy project

Mar 31 2009
Mar 31

I admit I've been lurking in a very slackernly manner in all the discussions in the Sakai community about content authoring, 3akai, UX, K2, Sakai NG and other unpronounceables, so I'm sorry if all this is a day late and a dollar short. Feel free to ignore me if you're part of Sakai and are way too far gone for any more input. After all, these are just thought experiments ;) If you're not part of Sakai, you might learn something about Drupal at least, so it may well be worth your time.

I draw some lessons here from Twitter and Drupal not to suggest that Sakai duplicate them, but rather that we hold those models in mind as we move Sakai forward. Even without these experiments, some of these ideas may be in our thinking about Sakai, so if they are familiar, take it as a vote of confidence. But if not, I'd like us to have at least thought through why we would not take them as inspiration or why we would choose another path.

In the lessons I draw from Twitter and Drupal below, I may come off as a bit of a zealot. Frankly, I have a greater appreciation for Twitter and Drupal as tools that I have for Sakai as a tool—my greatest appreciation for Sakai has always been for its community. But I would like to appreciate Sakai-the-tool as much or more than Twitter and Drupal, and I think I could, given the directions I see Sakai heading now.

But why Twitter and Drupal? When I'm thinking about all this Sakai stuff, my first thought is to reach for existing models. And the models I reach for are the handy ones. Why? Because there must be some reason I keep certain tools handy. There are lots of good tools, but the ones that fit so comfortably in my hand are well-worn for a reason. I also know them well—keen edges and ugly nicks—and so can draw the best lessons from them.

For those of you who live under rocks, Twitter is a microblogging and social networking service that has gotten a bit of press lately. A lot of people are using Twitter, and a lot of people don't get it at all. If you already use Twitter, great. If you don't get it, that's OK. You don't need to "get" Twitter to learn its lesson. There's only one, it's pretty big picture, and you won't have to tweet about doing your laundry or hear about mine just because you read about it.

Drupal is a mature web content management system/application toolkit, currently at version 6.10, with a very vibrant international community and strong commercial ecosystem. About 1,400 people attended the most recent DrupalCon in Washington DC.

Keep It Simple Like Twitter

Keep it simple. Open it up. Let the complexity come from everywhere.

John Ellis has kidded that Twitter has become so popular mostly because it is so easy to make new words that start with "tw": twavatar, tweeple, tweetup, twistory, etc, and if you haven't heard them all, check out the twictionary: http://twictionary.com

I think John's almost right. It's about the simplicity and what people do with it. I think Twitter's rise has a lot to do with their focus on keeping it simple: 140 character posts, direct, addressed, or pure statement, public/private, following/followers, search. Twitter keeps it simple and—just as importantly—offers a public API that lets the world layer an almost unfathomable and—to the Twitter team I'm sure—unimagined variety of interfaces, uses and extensions based on Twitter's simple service.

In other words, Twitter knew what it was doing, but it didn't expect that what it was doing was all that could be done.

Neither can Sakai. Looking ahead: we should focus, keep it simple, do it well, and open it up, so that everything we can't yet imagine can hang off our work.

Draw Good Boundaries Like Drupal

One of the most crucial decisions for any information machine is to decide how specific it wants to be and where it will draw boundaries around what it will do.

Every piece of software I've been involved with seems to follow the same general development pattern: In the beginning, software is built to meet specific needs in a certain context. As more needs are layered on over time, the software becomes either more cluttered or more generalized—or both—and gets rather messy. No one knows anymore exactly what it is for or where its boundaries are, but we end up tethered to it in all its messy complexity.

Take MS Word, which is both highly generalized (name something you CAN'T do with Word) and overly cluttered (you have to manage the TOOLBARS in Word). At this point, Word is really neither a great word processor nor is it powerful enough to be our main content management interface. And yet we use it for both. We are stuck to this big, messy machine and we can't get loose (assuredly, there are also some other, non-technical reasons we are stuck to Word).

Sakai also started out meeting specific needs. And over time, Sakai too has become rather cluttered. Now it seems we are clearly at a turning point where we want to generalize. I think our success will depend on where and how we map Sakai's boundaries as we clean things up. Drupal provides an instructive model in the cartography of information machines.

Caveats: There are other models that might be just as instructive. Drupal is just the piece of software I know best that, in my opinion, matches Sakai's stature and has done a good job defining itself as an information machine. There are also many valid criticisms of Drupal. For example, I would never argue that Drupal's user interface is ideal. The lessons I think Sakai can take from Drupal are at a deeper, architectural level.

First, like Twitter, Drupal has done a good job of drawing boundaries around what should be core and what should be left outside. Drupal core is pretty clean, focused on key, common functions. Meanwhile, in Drupal's contribution space and beyond, it is rather messy. That is exactly as it should be. Good stuff comes out of that mess and some of it makes its way into Drupal core when the time and scope is right. Other stuff outside is fully mature and absolutely essential—for some. And for that reason, it will never become core, which is exactly as it should be. Core should not be defined by maturity, but by generality. There are a lot of ways that the Drupal community works to support both high innovation in the periphery and healthy boundaries at the core. Sakai should think carefully about where we put our borders and how we will support work inside and out.

Second, Drupal has done a good job of generalizing, focusing and simplifying its core functionality, and making core functions easily available to peripheral tools. If you do it right, all you need to build into a Drupal module is the specific functionality you need...everything else is a call to core. This makes it incredibly easy and quick to add functionality to Drupal—which fosters innovation—and also ensures that contributed modules participate fully in the larger Drupal machine. As we collaborate to define and build Sakai's next generation, we should look to mature models like Drupal that have a head start on clarifying and exposing core functionality.

Those are the general lessons I draw from Twitter and Drupal, so if you've had enough, you can stop reading here. Following are some more specific examples I draw from Drupal that relate to some of our recent discussions in Sakai.

Content

Drupal starts with the idea that (almost) everything is a piece of content, starting from the same place on a conceptual and technological level as a "node." In Drupal, you augment the structure and/or functionality of these generic nodes by "decorating" them with additional structured data fields, workflow, etc. This way, all Drupal core has to concern itself with is the common structure (eg, common metadata like author, creation timestamp, etc) and common functionality (eg, access, CRUD, versioning, validation, input, etc) of nodes. More specific structure and/or functionality gets layered onto the basic node either through generic admin interfaces (eg, the Content Construction Kit, or CCK) or more tailored modules that make specially augmented nodes for specific purposes.

Want to create an event record? Create a new "event" content type, add a timestamp field that uses a mini-cal data entry widget. Click, click, done. Add location? Just decorate your event content type with a location field—oh, and then you'll have all the magic of a host of map integration modules at your disposal. Click, click, done. Want your events to link to location profiles? Create a separate "location" content type and add a node relation field to your event content type to link each event to a profile of its location. There, you just built a dynamic event web application in 15 minutes without calling your code monkey.

Another key Drupal module—Views—provides a generic query and output service for content. Need a table listing of all content meeting certain parameters, paginated in groups of 25 with sortable columns? Click, click, done. Want to offer that same content as a feed? Click, click, done. Want some completely different bucket of content, organized and presented in some other way? Again, click, click, done—and almost always with no coding required.

By generalizing core content in this way, Drupal handles it all consistently, but at the same time makes it easy to customize content for even the most complex needs—often with no coding required. Is it so easy faculty could do it? Maybe not without training, but you may not want end-users defining new content types willy nilly anyway. What the Drupal model offers is a way to lower the bar for meeting specialized content needs to a level that they can be met in minutes by someone with only a bit of training: a faculty power user, instructional designers, help desk staff, student assistants—crikey, even I can do it. Also, did I mention that Drupal content type definitions are exportable? Yes, you can define, export and share specialized content types.

Drupal understands that content creation and display is a core function, but it doesn't expect to know what YOUR content needs to be. Sakai would benefit with generalizing its content handling to Drupal's degree. As educators, we may feel that we are well-placed to define what a syllabus, a quiz, a discussion, a lecture podcast, or a portfolio should be. But as technologists, we will serve all the unforeseen ideas for what educational content might be far better by designing a solid, general framework on which our current—and future—ideas can be made manifest.

Taxonomy

From the start, Drupal anticipated that taxonomy—which is just a fancy word for categorization or tagging—was an essential core function. Drupal enables you to define any number of category vocabularies, each having special characteristics (eg, freetagging, hierarchy, etc), each holding any number of terms, and each related to whatever specific content types you desire. Thus any content in Drupal can be categorized in multiple ways, with highly structured categories or freetag folksonomies—or both—for different purposes. Good stuff is baked into core, like returning content matching various categories by simply including boolean queries in the URL.

Following the model I've been stressing of core simplicity enabling unanticipated innovation, Drupal modules make use of the basic, core taxonomy service to do all sorts of unexpected things, like category-based access control, or category-based organic group creation and management. With taxonomy as powerful as Drupal's baked into core, Sakai too could enable all sorts of things that we may not have yet imagined.

Theming

Drupal's core presentation layer is the icing on the cake, which is exactly what presentation should be: icing. There's nothing worse than finding presentation baked into deeper levels of software, where it's static and hard to change. Drupal handles presentation as the final layer, enabling design to be very flexible and easy to modify. Want every user to be able to choose between three entirely different designs? Just load three themes and let the users choose for themselves. Need to offer a mobile version of your site? A dedicated mobile URL and/or some user agent sniffing can automatically deliver a theme optimized for mobile devices—oh, and there's a module that does all that for you (something you'll find again and again in Drupal). Need that new content type you just made to look different than every other piece of content on your site? Drop a custom theme template named for that content type in your theme's directory and your generic theme gets overridden automatically with your custom design—just for that special case.

The power of this theming model came when Drupal core stopped worrying about what the perfect presentation should look like and instead offered a way to deliver ANY presentation predictably with easy-to-build templates. In Sakai, the same power and flexibility would take us past the question of what Sakai SHOULD look like to the simple answer: Sakai looks like whatever you want it to look like.

Layout

Our next-generation Sakai authoring experiments are delivering some juicy tools to place different pieces of content and widgets in different parts of a page. Drupal offers two models that may help us refine the good work we're already doing.

Drupal core has long had the concepts of regions and blocks. Regions are areas of a page defined by a theme. A theme can have any number of regions laid out in any way. Blocks are bite-sized content or functionality: anything from a static welcome message, to a listing of recently updated content, to a user log in form. Blocks can be created individually by users or made available programmatically by Drupal core or contributed modules. Drupal core offers tools to map blocks to different page regions, and customize the visibility of blocks based on almost anything: user role, content type, authentication status, URL patterns, etc.

Drupal's region and block system is very flexible, but it is better suited for site administrators to define global page layouts than it is for individual users to author custom pages with varied content as we have been imagining in Sakai.

Panels is a module outside Drupal core that comes closer to what we've been imagining in Sakai: the ability for an individual user to place content and/or widgets exactly where they want on an individual page. Unfortunately, the authoring experience in panels is not anywhere near the kind of intuitive WYSIWYG experience we have been working toward in Sakai. However, Drupal panels offers all the ingredients we might want in a page authoring experience...we just need to cook and serve them differently.

I take several lessons for page authoring in Sakai from what works well in Drupal's layout tools of regions, blocks and panels. When laying out a page in Sakai, we should be able to choose from:

  • A library of predefined layouts, offering good, commonly-used page structures. Some of these layouts could be merely structural—empty containers waiting for me to fill them—defining something like Drupal's page regions (eg, a typical three-column layout with header and footer). Others could combine some empty regions for me to fill, along with other regions already filled with existing widgets (eg, a big, empty body region with a sidebar that has calendar, discussion and tagcloud widgets already in place). We should be able to export and import these predefined layouts. I should be able to tag layouts and see/browse tags from other users—but one should be able to tag everything in Sakai, so we don't ever need to state this requirement again, right?
  • The opportunity to author a new, custom layout, where I can design whatever structure I want. I should be able to tag, export and share my custom layout.
  • A library of widgets—not unlike Drupal blocks—that deliver either content or functionality. I should be able to search and browse global widgets supplied by the system, my own widgets, and ideally, widgets authored by other users I've subscribed to. I should be able to tag widgets and see/browse tags from other users.
  • The opportunity to author a new widget on the spot, thereby adding it to both the page I'm authoring right now and my widget library for use elsewhere. Making a new widget might be like making a view in Drupal: the ability to make some selection of content and display it in some form (eg, table, list, feed, etc). Making a new widget might be like something else too. Like Drupal, Sakai should offer new tools the opportunity to supply new widgets—and/or the opportunity for users to author new kinds of widgets.
  • The opportunity to author a piece of content on the spot, thereby adding it to both the page I'm authoring right now and whatever other collections that specific kind of content happens to live within (eg, pages, syllabi, tests, forum topics, etc). Like modules in Drupal, new tools in Sakai that define content should end up offering the chance to author in Sakai's standard authoring environment.
  • The opportunity to define under what circumstances a given layout/widget/content piece is visible. As in Drupal, I should be able to define who can see something and when they can see it. Default visibility should be baked into predefined layouts, widgets and content. And if I have the right access, I should be able to override default visibility.

Pluggable Authoring Tools & Filters

Drupal offers flexible frameworks for modules to supply different ways to get content in and spit it back out. While Sakai has been wedded to the oft-maligned FCKeditor for some time (yes, all the WYSIWYG tools have their drawbacks), Drupal offers the ability to plug in almost any authoring tool: plain old text, different WYSIWYG/WYSIWYM editors, various markup formats, etc. At the same time, Drupal offers the ability to define output filters that can clean up and/or enhance stored content when it is rendered. Drupal's filter on output strategy allows the same content (stored raw in the database) to be transformed differently depending on what filters are in use (which can even depend on user role or preference). Want anonymous users to see all your content translated into Pirate talk? Done. Again, Drupal core is not determining how stuff gets in and out, it instead provides a pluggable framework so we can decide for ourselves what we need. So many of Sakai's usability issues revolve around the rigidity of input and output, we would do well to adopt a pluggable model which opens possibilities beyond what we can anticipate.

URLs

Unfriendly to humans and search engine robots alike, Sakai has some of the ugliest URLs ever. It makes sense for a web application to have canonical URLs and it's hard to make them friendly, but there's no reason to show them to the world. Drupal solves the ugly URL problem by offering a core service for URL aliasing, so users themselves can define better URLs for their content. A valuable contributed module—pathauto—allows site administrators to define automatic URL aliasing rules for different canonical URLs, thus saving authors the aliasing task and enabling more structured aliasing patterns. Again, the lesson for Sakai is to fix our problems by offering flexible options rather than trying to bake in the final solution.

Workflow

Drupal core has basic workflow baked in based on triggers and actions, where triggers are set to fire on certain events, in turn generating specific actions. For example, a workflow can be established to email a site owner (an action) every time new content is posted (a trigger). Once again, instead of providing all the ideal workflows we might imagine, Drupal provides a generic tool to build workflows, which we can use to build those we already know we need, as well as those we don't yet know we need. If only Sakai's sometimes idiosyncratic workflows were merely defaults, which I could change or replace as easily as I can in Drupal.

Installation Profiles

Many parts of Drupal can be exported/imported (eg, content types, views) or are modular (eg, modules, themes, filters) to allow for easy sharing and migration. One of the Drupal's most powerful tools is the installation profile: an automatic recipe to build a new Drupal site. Installation profiles set modules, themes and other configuration options when Drupal is first installed so you can distribute a pre-packaged Drupal recipe, optimized for specific purposes. If Sakai had installation profiles like Drupal, I could imagine distributions for different organizational types (K-12, community college, liberal arts college, research university, etc), different usage focuses (collaboration, portfolios, teaching and learning), or different languages, giving new adopters better starting places than a generic Sakai installation. As Sakai generalizes itself, we should also have a way to demonstrate and distribute best practices for specific uses.

Other Stuff

There are many other (smaller) lessons Sakai might take from Drupal. Some that come to mind include:

  • The core form API that lets modules safely offer forms with minimal work and modify others (including core forms) dynamically as needed.
  • The core multisite functionality that allows Drupal to run multiple sites from the same codebase, yet override and/or augment any part of any site as needed.
  • The core comment functionality that lets any piece of content include threaded comments.
  • The core support for automatic feeds.
  • The core menu functionality that allows navigation to be managed as its own kind of content.
  • Core support for OpenID authentication.
  • Sophisticated core caching mechanisms.

Finally, a Shout Out to Portfolios

Oddly enough, the part of Sakai that most reminds me of Drupal's generality is our portfolio toolset. It's not surprising that portfolios—maybe the least well-defined practices in teaching and learning—have led to the most generalized tools in Sakai. And yet, the most obvious complaint about Sakai portfolio tools is that they don't do anything at all. The fact is: Sakai portfolios can do almost anything. What's missing in portfolios is the easy tools to build them and the portable models to demonstrate their power. Sakai would do well to look inside to its portfolio tools—for inspiration to generalize, but also for caveats about what must be in place to make generalized tools usable and practical.

Jan 31 2009
Jan 31

When I first started this blog, I used Drupal's built in jQuery library to randomly show a picture in my header from a stockpile I put on my webserver. It worked great, but it was a manual process: selecting the pictures, sizing & cropping them, uploading them, etc. In the end, I rarely added any new pictures because it was a hassle.

I had long wanted to try something more automated and show a wider variety of more current pictures on my blog. The goal: automatically show selected pictures from my flickr stream with no extra steps other than posting to flickr and maybe adding a special tag.

Finally, the images you see in my header are randomly shown from a set provided automatically from my flickr stream and are automatically cropped and sized. All I have to do to add a new image to my site header rotation is add one extra tag to a picture when I upload it to flickr.

Here's the Drupal technology I used to make this possible. FYI: everything is done with stock Drupal core and contributed modules...absolutely no coding required!

  1. Create a special page type for images: I use some basic cck modules to create a special page type on my blog to display images and related information about them.
  2. Sync with flickr: I use the flickrapi and flickrsync modules to automatically download any new images I put in my flickr stream. Flickrsync syncs the images automatically on a schedule I determine via Drupal's stock cron process. Each new image downloaded from flickr creates a new image page and the title, description and tags from flickr are added to the page along with the image. I download all my flickr images, including the ones marked with a special tag to show them in my header.
  3. Size and crop the images: I use the imagecache module to automatically size and crop a copy of each image so they fit perfectly in my header. The automatic process doesn't always work perfectly...I might size and crop differently if I did it myself. But it often works well and sometimes even comes up with interesting, surprising results. Best of all: I don't have to do it ;)
  4. Display images randomly in the header: I use the indispensable views module to create a special view of the image pages created in the steps above that shows just one random image a random selection from only those images marked with the special image tag and displays the copy of the image copies of the images cropped and sized specifically for my header.

As an added benefit, I end up with a lifestream-style copy of all my flickr images on my blog, which I can also use as a dashboard to find images and change tags if I want to override the tags I've set in flickr itself (eg, to add or subtract an image from the header rotation).

Now with Dynamic Rotation

Thanks to an experiement I undertook for my review of Matt Butcher's excellent Drupal 6 JavaScript and jQuery book, I've now come full circle and used jQuery to add dynamic rotation to my header images. Here's how I did it.

First, I made a small adujstment to the view I created in step 4 above to have it return more than just one randomized image. You can adjust the view to return whatever number of randomized images you want by changing only the value for "items to display".

Then, I modified a the sticky_rotate.js example code Matt supplied with his book to affect my header images rather than the original sticky node teasers. I actually simplified the code because all my header images are the same height, so I could remove his code that calculated the tallest teaser. I mostly just changed the function and variable names to pertain to my use case. You can see my header_rotate.js script below and for a full explanation of what's going on, you should just buy Matt's book, because it's money well spent.

Finally, I just put my new header_rotate.js file in my theme folder and modified the theme.info file to include this new script

Voila! My header images now rotate dynamically with an adjustable delay and a nice fade feature. I'm sure something more sophisticated is warranted (like loading the images as needed via ajax or something more clever), but I was happy to have this small demonstration of Drupal and jQuery's simplicity and power after only a few minutes work.

// $Id$
/**
* Rotate through all header images returned by view,
* using jQuery effects to display them.
*
* Based on StickyRotate from Drupal 6 Javascript & jQuery
* Chapter 3, by Matt Butcher
* http://www.packtpub.com/drupal-6-javascript-and-jquery/book
*/

// Our namespace:
var HeaderRotate = HeaderRotate || {};

/**
* Initialize the header rotation.
*/
HeaderRotate.init = function() {
var headerImages = $(".view-header-rotating .views-row");

// If we don't have enough, stop immediately.
if (headerImages.size() <= 1) {
return;
}

headerImages.hide().css('height', '100px');
HeaderRotate.counter = 0;
HeaderRotate.headerImages = headerImages;

headerImages.eq(0).fadeIn('slow');
setInterval(HeaderRotate.periodicRefresh, 7000);
};

/**
* Callback function to show a new header image.
*/
HeaderRotate.periodicRefresh = function () {
var headerImages = HeaderRotate.headerImages;
var count = HeaderRotate.counter;
var lastHeaderImage = headerImages.size() - 1;

var newcount;
if (count == lastHeaderImage) {
newcount = HeaderRotate.counter = 0;
}
else {
newcount = HeaderRotate.counter = count + 1;
}

headerImages.eq(count).fadeOut('slow', function () {
headerImages.eq(newcount).fadeIn('slow');
});
};

$(document).ready(HeaderRotate.init);
Jul 15 2008
Jul 15

Our second episode features Nate Angell or @xolotl, a name that's hard to remember completely, but one that we will always remember. There's development talk later as he demonstrates the shiny, new iPhone app called iToony.

But first, we chatted about Drupal for large organizations and the relative livability of various European cities—all accompanied by extremely loud (but pleasant) French songs, one of which may or may not be a rendition of Cole Porter's Night And Day.

The image Nate made of Bram Pitoyo using the iToony app is here.

Jun 01 2008
Jun 01

Top-10 Countdown

Open Source Success

7/23/2006

How to ensure a winning implementation on your campus.

Nate AngellNate Angell co-directs a collaborative team that offers services and technologies across a range of teaching, learning, research, and communication needs at Portland State University, Oregon’s largest, most diverse, and only urban public university. Angell’s current focus is on integrating Portland State’s academic and web communication technologies on an open source platform. He is an active member of open source communities including Sakai, Open Source Portfolio, and the web content management platform Drupal. Angell and members of Portland State’s team regularly help other campuses and institutions implement enterprise open source technologies. Here, Angell offers a number of intelligent ways to help open source implementations succeed.

10

Engage deeply with the community surrounding open source technology.

  • Take control of your destiny and help shape technology roadmaps.
  • Share early and often: Active participation raises your stature.
  • It’s not only for coders: The community needs a range of skills.
9

Remember, any IT environment can take advantage of open source.

  • Literally any campus—regardless of its IT resources—can succeed.
  • If you need help, vendors offer various levels of support and hosting.
8

Understand how change happens at your institution.

  • History repeats: Look at past attempts at change on your campus.
  • Take heed where your plan d'es not match institutional culture.
7

Build the right implementation team.

  • Who can speak effectively with decision-makers and those who influence them?
  • Who can translate technical issues for non-technical audiences?
  • Bring potential conflict inside: Engage critical voices directly.
6

Leverage drivers of open source adoption on your campus.

  • Prioritize and amplify factors that engage existing passions.
  • Consider a Trojan horse: a smaller, more innocuous goal to start.
5

Communicate effectively—it’s crucial to your implementation’s success.

  • Plan how to communicate with everyone affected by your implementation.
  • Speak about the larger vision the implementation will enable.
  • Stay on message: Every activity is an opportunity to communicate your vision.
4

Think outside the box for training and support.

  • Cell phones are a global phenomenon.
  • Integrate training and support: Support calls are training opportunities.
  • Mix it up: Offer resources in a variety of formats, levels, and schedules.
3

Plan for assessment in every stage and activity of your implementation.

  • Good assessment is not an afterthought; start early.
  • Measure progress toward your goals; don’t merely evaluate tools.
  • Surveys are two-way communications: Use them to support your message.
2

Stage your success.

  • Pilot everything—from technologies to communications—with increasingly
    larger groups.
  • Think of pilots as dress rehearsals (implementation practice), not as bake-offs
    (technology selection).
  • Champions are made, not born: Use pilots to transform users.
1

Keep telling the story.

  • Don’t miss a chance to help people understand your vision.
  • Everyone, from front-line user support to your CIO, should speak about the
    change new tools will enable—the tools are means to other ends.
  • People will buy in to visions of change—not just changing technology.
Apr 22 2008
Apr 22

For the second year running, Drupal placed in the Webware 100 awards in the Publishing & Photography category.

In this publishing category, the only other contender in the top 10 that comes close to matching the flexibility and functionality of Drupal was Wordpress, which would probably do well to continue to focus on the blog niche and not try to play catch-up with the more mature Drupal (current versions: Drupal 6.2, WP 2.5). Missing altogether were projects that match up better with Drupal, such as Joomla and Plone.

Check out all 10 winners:

Feb 28 2008
Feb 28

Just noting that I updated my Drupal 6 test site to 6.1 following the security release. The update was painless.

Thanks to Drupal 6's new update functionality, the site itself checks to see if any updates to core or modules are necessary and let's you know.

And if you think it's problematic that 6.0 already had a security patch...I beg to differ: new "dot 0" releases of any software often have bugs, sometimes security related, and Drupal's quick 6.1 release just demonstrates that Drupal in particular and open source projects in general are often quicker to identify and patch security bugs than proprietary development teams.

Feb 27 2008
Feb 27

Kudos to walkah et al for their work on the Drupal OpenID module and getting OpenID into core for Drupal 6!

By default, OpenID in Drupal 5 and 6 defaults to present regular Drupal authentication first, giving the user the option to toggle to authenticate via OpenID.

That's the exact opposite of what I wanted to deploy on my blog: I want users to log in using OpenID unless they have a very good reason not to. Here's how I solved the problem in 5 easy steps using just the magic of a phptemplate theme to modify the authentication interfaces to default to OpenID.

Step 1: Override Authentication UI

First I added the following overrides in my theme's template.php file to specifiy that I would be overriding various interface elements.

// override the user log in form at /user
function phptemplate_user_login($form) {
return _phptemplate_callback('user_login', array('form' => $form));
}

// override the user registration form at /user/register
function phptemplate_user_register($form) {
return _phptemplate_callback('user_register', array('form' => $form));
}

// override the password reset form at /user/password
function phptemplate_user_pass($form) {
return _phptemplate_callback('user_pass', array('form' => $form));
}

// override the user log in block
function phptemplate_user_login_block($form) {
// show hint in form element
$form['openid_url']['#value'] = 'OpenID Login';
// remove hint in form element on focus
$form['openid_url']['#attributes'] = array('onfocus' => "javascript:openid_url.value=''");
return _phptemplate_callback('user_login_block', array('form' => $form));
}

Step 2: New User Log In Template

Next I added a template file to my theme directory called "user_login.tpl.php" as per my override in template.php above with the following code.

// reverse default form element visibility toggles set in openid module js
drupal_add_js('$(document).ready(function(){$("#edit-openid-url-wrapper").show();$("#edit-name-wrapper").hide();$("#edit-pass-wrapper").hide();$("a.openid-link").hide();$("a.user-link").show();});', 'inline');// render login form
print(drupal_render($form));

Step 3: New User Registration Template

Next I added a template file to my theme directory called "user_register.tpl.php" as per my override in template.php above with the following message, giving a link for users to go get an OpenID because I don't want users to create local Drupal identities.

Establish your <a href="http://openid.net/" title="Learn More about OpenID">OpenID</a> with a provider like <a href="http://myopenid.com/" title="Visit MyOpenID.com">MyOpenId.com</a>. Then come back to this site and <a href="http://xolotl.org/user" title="Log in to this site">log in</a> with your new OpenID.

Step 4: New Password Recovery Template

Next I added a template file to my theme directory called "user_pass.tpl.php" as per my override in template.php above with the following message, giving a link for users to go recover their password from their OpenID provider.

Visit your <a href="http://openid.net/" title="Learn More about OpenID">OpenID</a> provider to recover your password. Then come back to this site and <a href="http://xolotl.org/blog/xolotl/defaulting-openid-drupal-5/user" title="Log in to this site">log in</a> with your OpenID.

Step 5: New User Log In Block Template

Next I added a template file to my theme directory called "user_login_block.tpl.php" as per my override in template.php above with the following code.

// reverse default form element visibility toggles set in openid module javascript
drupal_add_js('$(document).ready(function(){$("#edit-openid-url-wrapper").show();$("#edit-name-wrapper").hide();$("#edit-pass-wrapper").hide
();$("a.openid-link").hide();$("a.user-link").show();});', 'inline');// render select elements in login block
print(drupal_render($form['form_id']));
print(drupal_render($form['openid_url']));
print(drupal_render($form['submit']));

You're Done!

After these 5 steps, users are presented with OpenID authentication on my site and guided to getting an OpenID if they don't have one already. A user with a local, Drupal identity can still toggle to authenticate on the now obscured /user login form, but only an existing user with the proper access can create new local Drupal users.

My dream for OpenID in Drupal core is to have admin UI that allows various configurations which make any necessary changes to the user authentication UI:

  • prefer OpenID authentication, allow Drupal
  • prefer Drupal authentication, allow OpenID
  • allow only OpenID authentication
  • allow only Drupal authentication (this case would be covered by just not enabling the OpenID module)

Let me know if you have more questions about or suggestions for this solution.

Feb 14 2008
Feb 14

With today's release of Drupal 6.0, I've upgraded my test site from RC4, which was again as easy as pie.

You can read my earlier post on what's exciting in Drupal 6.

Stay tuned for more on Drupal 6, and oh, in case you haven't heard, go to DrupalCon 2008 in Boston!

Feb 12 2008
Feb 12

I just installed my first Drupal 6.0 version (RC4), which took a total of about 3.5 minutes. You can visit the resulting (minimalist) site at:

The new installer worked flawlessly, requiring only establishing a database and user and changing the the access control on a single directory and changing it back again once the install was complete. The rest was answering a few basic questions in Drupal's web-based installer. Given that the db and file access steps could also be accomplished via a web interface (eg, cpanel on a hosted server), the whole installation process could easily be handled by a non-technical user in the same few minutes it took me.

What's exciting in Drupal 6? You can check out a complete list, but for me, here are the highlights:

  • OpenID integrated as a core module. My only suggestion here would be to add some administrative controls to toggle various authentication options (eg, only use OpenID or Drupal authentication, prefer OpenID or Drupal authentication, hide password change controls from OpenID users, etc).
  • Workflow actions and triggers integrated as core modules. This demonstrates something I've admired most about Drupal: the right functionalities are brought into core as general services/APIs. I haven't experimented with these yet, but core's where they belong.
  • The latest jQuery integration. Drupal worked with the jQuery folks to deliver jQuery 1.2.3. This should make for even more jQuery goodness.
  • The update module integrated into core. Now let Drupal tell you when it needs upgrades.

I'll need to wait until key contrib modules like CCK and Views are ready to test in Drupal 6, but I have every faith that added together, this release will significantly increase the sophistication and power of Drupal.

Meanwhile, there are already even little tweaks to love, like drag and drop reordering of menus and blocks, and hiding the revision log field on the node edit form in a closed fieldset (yes, it would be nice if every user explained every content update they made, but most have no idea what is being asked for in the log).

Stay tuned for more on Drupal 6, and oh, in case you haven't heard, go to DrupalCon 2008 in Boston!

Jan 25 2008
Jan 25

O how I want to Flock in the morning. O how I want to Flock in the eve.

But I can't because Flock can't authenticate me to my OpenID, Drupal blog.

Flockstars take notice: OpenID critical mass is growing. Take a look at OpenID support in these flocky sites and at least let us know what you all are thinking about integrating OpenID support in Flock (very partial list):

Dec 29 2007
Dec 29

Several key Drupal community members have gathered together with some others to form Acquia, a new commercial firm that hopes to sell subscriptions to Drupal a la RedHat's linux distros. Acquia has already generated $7 million in funding.

I notice the similarities between Acquia and rSmart, where I now work. Both are focused on the open source web application layer, both think of RedHat as a model, both are working within large, already established open source communities. There are other examples...but apparently the idea of commercial subscriptions for open source web applications is catching on...

Dec 16 2007
Dec 16

We've long been maintaining that open source technologies are in wide—and often unrecognized—use in many organizations. Now we have an initiative and a tool to help demonstrate that claim with real numbers.

I've submitted requests for the OSS Discovery tool to establish fingerprints to discover three open source technologies I'm involved with, Drupal, Sakai and Kuali, and I'll call on those communities to help make sure those fingerprints become a part of the tool.

Open source technology solution providers and institutions implementing open source might also consider making a formal OSS discovery part of their readiness evaluation.

Comment/vote/collaborate on my tickets for the following fingerprints:

Nov 24 2007
Nov 24

Bill's post got me thinking about a problem I've been ruminating on from a related arena: the world of academic eportfolios. The issue: How to enable a high degree of independence for individuals in the stewardship of their eportfolios, but at the same time facilitate the use of material from those eportfolios for collective (aggregated) goals, such as academic course, career, program and/or institutional assessment?

Most systems that provide approaches to this issue err on the side of centralization. But one problem they face is scalability: How do you provide a good user interface to a centralized tool that reports on (aggregates) say, 25,000 user eportfolios? Another problem they face is standardization: The collectivity likes information in trees and boxes while the individual (and their learning pathways) often produce a much looser collection of stuff.

Bill's demo started me thinking that the more elegant (only workable?) solution to this issue is a far looser coupling of the individual eportfolio and the central reporting (aggregating) function. Let the individual create willy-nilly, but when it matters, tag with care. Let the collectivity build more sophisticated aggregators of tagged user creations rather than trying to box and prune them from the outset.

The six hours Bill spent building his demo were enough to let me envision not so many hours more spent to extend his work to model a better solution to this eportfolio conundrum. A solution where the individual has their cake and the collectivity eats (aggregates) it too.

Nov 21 2007
Nov 21

After 5 years as Portland State's Director for Web Communications, I've moved on to work for The rSmart Group, a commercial provider of open source technologies working mostly in the education sector with Sakai, OSP and Kuali.

To extend my engagement at Portland State with open source communities like Sakai/OSP and Drupal, I'm looking forward to a fulltime focus on open source at rSmart, as well as the mandate to expand my thinking beyond local, institutional concerns.

With this move from public to private, I'm happy to still be connected to education. There's much work to be done to help make open source technologies the obvious choice to support educational missions. rSmart's definitely part of that work. And rSmart's attitude toward its clients and open source communities aligns closely with my own. In many ways, my drive to do good feels more empowered in this for-profit company than it did in public education.

Although rSmart's based in Phoenix, AZ, I'll still be in Portland, OR. I'm not yet ready to trade the rain for the heat.

Look for much more activity here as I start to spread out in my new role.

Oct 24 2007
Oct 24

UC-Davis just published results from a well-designed survey on university web content management system usage.

Over 60% of respondents were using a web CMS and homegrown/open source systems were more common than proprietary systems.  Plone/Zope combined was the most common, followed closely by Homegrown, and then Drupal.

Today, the Requirements and Evaluation committee of the UC Davis Web CMS initiative posted results from an online survey of campuses completed last month.

The survey was conducted to collect comprehensive data about the adoption and use of Web content management systems among institutions of higher education, and to make this information available to communicators, webmasters, technologists and other key campus personnel. Our goal was to learn about the experiences - both positive and negative - of other universities in the adoption of Web CMS, and to share this information with those who may currently be considering the same.

Apr 12 2007
Apr 12

Update

Read my latest post on my image header for how I ended up carrying out this idea.

People have been asking what the deal is with the images in my site header.

I've been experimenting with loading random background images from my collection using Drupal's integrated jQuery tools.

I've been thinking about trying to work on having the images feed from a flickr stream, perhaps using the Drupal flickr module, yet be automatically sized/cropped for the site header. More on that if I get to it.

Many of the pictures are of people in my family, or shots I've taken around our home or Portland.

Apr 10 2007
Apr 10

Thanks to quick work by my host Liquidweb (thanks Siena!), this site is now delivered by the three fives: Drupal 5, PHP 5 and MySQL 5. Still waiting for Linux 5 and Apache 5 ;)

One of my goals here is to demonstrate/evaluate how this technology will operate on a forward-looking platform. Ever since Rasmus Lerdorf himself suggested dropping PHP 4 for the good of all at OSCMS 2007, I figure we better get ready for the future.

Check my blog recipe for platform details.

Apr 08 2007
Apr 08

Recently returned from the Open Source Content Management Systems (OSCMS 2007) gathering held at the Yahoo! campus in Sunnyvale, CA.

Drupal was strongly represented at OSCMS, but also saw some Joomla, Plone and Alfresco presence.

As often, PHP maven Rasmus Lerdorf was in attendance, in this case, demonstrating the latest in security and performance considerations.

I found great value in the day-long seminar on Drupal/LAMP performance and scalability given by Dries Buytaert (Drupal), James Walker (Bryght), Jeremy Andrews (CivicSpace) and Matt Westgate (Lullabot), with a guest appearance by Robert Douglass (Lullabot). If anyone continues to have doubts about LAMP platform applications scaling to enterprise levels...they should have been in attendance to absorb the variety of solutions from hardware to network to architecture to database to code offered here. After this, I will no longer doubt that LAMP applications can be tailored to meet enterprise demands.

Apr 04 2007
Apr 04

I'm now keeping a recipe cataloging the technologies and configuration that drive this xolotl.org site.

Continue to check the recipe as the site evolves.

Once the site reaches a certain maturity, I'm thinking to build a Drupal install profile to make it easier for others to duplicate this installation.

Apr 03 2007
Apr 03

LAMP Platform

Drupal Content Management System

Drupal Installation

  1. Procure a LAMP webserver environment similar to the one described above. Other platforms are possible (eg, LAPP, WAMP, WIMP, etc), but will not be discussed here. Read Drupal's system requirements for more information.
  2. Once Drupal is installed, check your site's system status (at http://yourdomain.tld/admin/reports/status) to make sure you have properly and completely installed Drupal. Fix any reported issues.

Drupal Configuration

  1. For basic settings, I recommend using clean URLs. You might wait to enable caching and/or disabling on-screen error reporting until you are ready to make your site live.
  2. Enable the optional core modules listed below.
  3. Install and enable the theme listed below, choose another existing theme, or design your own Drupal theme (Framework is a good theme on which to base a new design).
  4. Install and enable the contributed modules listed below. Any specific installation issues will be noted under each module listing.
  5. Set up a cron task that will visit your Drupal site on a regular basis to do basic housekeeping tasks automatically (eg, rebuilding the search index).
  6. Establish an OpenID identity with a provider (eg, myopenid.com, myvidoop.com) and use it to log in to your Drupal site. (Note: I don't recommend using Drupal's root administrative user as your daily blogging identity, so make a new user for yourself with reduced privileges.)
  7. Start blogging!

Optional Core Modules

Ultimately, all these core modules are optional, but some provide basic functionality you won't want to blog without.

  1. aggregator: Enables you to expose feeds (eg, RSS) from other sites on your site.
  2. blog: Blog enables multi-user blogging. If only one person will ever blog on your site, you don't need the blog module. However, even though I may be the only blogger on xolotl.org, I've enabled blog to establish handy navigation to my blog, and other modules may add useful functionality directly to blog.
  3. blog api: Allows users to post content using applications that support XML-RPC blog APIs.
  4. comment: Enables you or other users to comment on your blog entries (or other content).
  5. contact: Provides general site contact form.
  6. database logging: Logs and records system events to the database.
  7. help: Provides online help for Drupal features.
  8. menu: Enables your site to have navigation menus.
  9. openid: Enables OpenID authentication. Note that I did some user login, login block, register and password form templating to override stock forms provided by Drupal and this OpenID module. My goal: allow only OpenID authentication.
  10. path: Enables you to make URLs on your site more human and search-engine friendly.
  11. php filter: Allows embedded PHP code/snippets to be evaluated.
  12. ping: Alerts other sites when your site has been updated via ping-o-matic.
  13. poll: Enables simple polling functionality. I'll occasionally be asking my blog readers to vote on simple polls.
  14. search: Enables Drupal's built-in content search functionality.
  15. statistics: Enables Drupal's built-in usage statistics functionality.
  16. taxonomy: Enables you to categorize content with your own custom tags.
  17. update status: Checks the status of available updates for Drupal and your installed modules and themes.
  18. upload: Enables you to attach/upload files (eg, images, PDFs, etc) to content items.

Contributed Modules

Some of these contributed modules use additional required supporting modules where are not listed here.

  1. cck: Allows administrators to define new content types. I also use some custom CCK field type modules, that enable date, email, filefield, imagefield and link fields.
  2. flickrsync: Reads users's Flickr photo streams, and turns into nodes.
  3. google analytics: Adds Google Analytics javascript tracking code to all your site's pages.
  4. imagecache: Dynamic image manipulator and cache.
  5. : Protects against comment and contact form spam.
  6. pathauto: Enables custom, automatically-generated URLs for pages.
  7. : Enables printer-friendly, PDF and email versions of pages.
  8. service_links: Automatically adds Digg, del.icio.us, reddit, Technorati etc. links to content items.
  9. simplemenu: Creates a menu bar that is displayed at the top of every page.
  10. tagadelic: Tagadelic makes weighted tag clouds from your taxonomy terms. See the one in the column to the right.
  11. tinymce: Enables a WYSIWYG rich text editor.
  12. views: Create customized lists and queries from your database.

Theme

framework: I'm using a slightly modified version of the Framework theme by Andre Griffin. My modifications are only to default to OpenID authentication and some minor CSS style tweaks.

Apr 02 2007
Apr 02

With some work, I've now enabled OpenID user authentication. It would have been a lot easier if I weren't running Drupal 5 (for which a core OpenID module is not yet ready) or using a shared host (which meant I don't control PHP at the system level).

Steps to get OpenID auth running included:

This process will be a lot easier once a core OpenID module is ready for Drupal 5 and if one were in complete control of one's hosting server. Meanwhile, it wasn't so hard to enable the first credible global authentication system on a cheap shared host with my paltry technical skills ;)

I'll be taking (the much simpler) steps soon to let me use this blog site URL as my OpenID.

I've also enabled Drupal's core aggregator module and used it to expose a few open source feeds (Drupal, Sakai, OSP) on the site. The feeds are exposed in 2 blocks that categorize them (eg, the one Drupal feed in one block, the two Sakai and OSP feeds in another block).

Apr 01 2007
Apr 01

I've started a new blog to put Drupal 5 to the test.

I may work toward contributing a Drupal install profile for a single-user blog site.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web