Apr 27 2009
Apr 27

"RDFa in Drupal: Bringing Cheese to the Web of Data" is the title of our short paper which was recently accepted at the 5th Workshop on Scripting and Development for the Semantic Web. It seems that the topic of food on the semantic web is the new black as this paper comes out at the same time as Boris Mann's announcement about the Open Restaurants aka "BaconPatioBeer".

This paper illustrates how a CMS like Drupal can be used on the Semantic Web and make every Drupal site part of the growing Web of Data. We created a cheese review site as a use case. It relies on the RDF API and the RDF CCK modules.

The good news is that we are working to get this RDF goodness into Drupal core! We are organizing an RDF code sprint. This sprint builds on Dries' ideas expressed in his recent posts Drupal, the semantic web and search and RDFa and Drupal. With RDF in the core of Drupal and RDFa output by default, it's dozens of thousands of websites which will all of a sudden start publishing their data as RDF.

So far, Stéphane Corlosquet, Florian Loretan, Benjamin Melançon and Rolf Guescini have signed up. How about you?

Some others are willing to come but cannot afford the trip until some funding is secured. To help us fund the sprint and bring more Drupal rockstars on board, please consider making a donation using the ChipIn widget on this page. The money will be used to cover flight, food and hotel costs for the sprinters. All sprinters are generously donating their time to make this happen. It would also be great to fly in a few additional people with extensive testing and Fields experience. Any excess money will be used to add more people, or will be donated to the Drupal Association.

AttachmentSize rdfa_drupal_cheese_sfsw09.pdf406.67 KB


Apr 27 2009
Apr 27

I have found myself attempting to contribute to Drupal core more and more lately. So I wrote a shell script that gets me a fresh copy of head and applies a patch to it.

Essentially I will be looking through a Drupal issue, such as http://drupal.org/node/229778 and I'll want to add to a patch on there. I simply grab the URL of the patch file and run my gethead.sh

./gethead.sh http://drupal.org/files/issues/229778-log-changes-to-offline-mode.patch

This will create a directory based on the filename of the patch, check out head into that directory. Fetch the patch and apply it.

if [ "$1" = "" ]; then
echo "I need a \$1 URL to a patch file"
FILEVAR=`echo "$1" | awk -F"/" '{print $NF}'`
mkdir $FILEVAR
cvs -z6 -d :pserver:anonymous:[email protected]:/cvs/drupal checkout drupal
wget $1 --output-document=$FILEVAR
cd drupal
patch -p0 <../$FILEVAR

p.s. If I was to extend this, which I may, I would create a db and fix the settings file straight away to point at it. I'd probably use mysqlhotcopy.

AttachmentSize 320 bytes
Apr 26 2009
Apr 26

FileField and ImageField 3.0 have just been released and bring with them the ability to display an upload progress meter in the FileField widget while a file is being uploaded. As ImageField uses the FileField widget this works for ImageFields too.

The original article FileField and ImageField 3.0 for Drupal 6 Released points out:

Probably the most exciting improvement is the addition of upload progress indication. This enhancement requires the PECL uploadprogress PHP extension, but adds a real asset to sites that use FileField for podcasts, videos, or other large files.

It took me a while to figure out how to install this extension so I thought I'd do a quick post about it. These instructions are probably valid for other PECL extensions but since this is the only one I have installed I wouldn't like to say for sure.

Please note: These instructions are only valid if you have problems running pecl install uploadprogress

  1. Download the PECL uploadprogress extension

  2. Extract the uploadprogress-1.x.x.tgz archive, cd into the extracted folder and run these commands in Terminal:

    phpize            # prepares the PHP extension for compiling
    sudo make install

  3. Check that the directory for the extensions is correct. The last line of the output returned from the make install command (on my system) is:

    Installing shared extensions: /usr/lib/php/extensions/no-debug-non-zts-20060613/

Open php.ini and edit the extension_dir directive, replacing it with this path.

  1. Add the extension to php.ini by adding this line extension=uploadprogress.so
  2. Restart apache

You should now have the PECL uploadprogress extension installed.

It's very simple to install on Windows:

  1. Copy the uploadprogress.dll file from pecl4win into the path set for extension_dir in php.ini.
  2. Add the following to php.ini:


  1. Restart apache.

The pecl4win site was down for maintenance at time of writing so you could try here in the meantime (thanks to chriscohen for the link).

If you're using using WampServer 2 then it already comes with php_uploadprogress.dll installed (thanks again to chriscohen for pointing this out and testing that both methods work).

To increase the maximum filesize you need to set 2 directives:

Generally you should set post_max_size to double what you set upload_max_filesize to. This means you can upload 2 files of your maximum limit for each POST and seems like a good middle ground.

The memory_limit directive should also be set above the value of post_max_size so your server can handle the uploads.

There are 2 ways you can set this directive:


Edit php.ini and modify these directives:

upload_max_filesize = 128M
post_max_size = 256M


Edit .htaccess and add:

php_value upload_max_filesize 128M
php_value post_max_size 256M

Adjust 128M and 256M with the sizes you require.

You could edit the memory_limit directive in php.ini but I personally like to set that directive on a site-by-site basis. This helps to keep sites that don't need such a large memory_limit nice and efficient.

Instead you can set the directive in settings.php by adding this line just below the other ini_set lines:

ini_set('memory_limit', '256M');

Posted by psynaptic

Apr 26 2009
Apr 26

Finally upgraded this site from Drupal 5 to 6. There's nothing special in that, it all went very smoothly and I just changed the theme again. But on the way I thought I'd get a bit of RDFa into the site - so the most interesting stuff on this, and other pages, you probably can't see.

RDFa has always made a huge amount of sense to me, and there's a push to get it into core for 7, which is brilliant, so testing a bit more in here seemed a sensible thing.

Central to implementing a bit more RDF of any sort into Drupal at the moment is the rdf module. Here it's making some nice changes to the header, and adding the name spaces. It's easy to add more that the default too - I certainly wanted Creative Commons and Web of Trust that weren't there already, for example.

Also pretty important, and I guess the way it's going to go with fields in core, is RDF CCK module. This is a lovely module, which when installed with its dependencies, will auto suggest as you type mappings from the imported vocabularies (excellent stuff :) The module's at work here on the profile nodes. However as the rest of the site is based on pretty simple nodes (title, body, with a user and taxonomy) and comments (same but without taxonomy) and no extra fields most of the rest of the RDFa magic's in the template.php and a bit in the appropriate *.tpl.php for now.


First off with nodes just to make sure the subject is usually set I changed the first <div> in the node.tpl.php to include an about="/path/to/node":

<div about="<?php print $node_url; ?>" id="node-<?php print $node->nid; ?>" class="<?php print $classes; ?>"><div class="node-inner">

This means even when it's on a page with multiple nodes the content inside will have correct subject

Next I wanted the dc:subject. I'll get round to integrating with some controlled topic vocabulary, but for now it's referenced on my site. Anyway for this in the THEMENAME_preprocess_node it's just a case of redoing the terms variable:

  $terms = taxonomy_link('taxonomy terms', $vars['node']);
  foreach($terms as &$term) {
    $term['attributes']['property'] = 'dc:subject';
  $vars['terms'] = theme('links', $terms);

Next up the node author. For this I've overridden the theme_username to accept a $options for the link. It's not always the case that the username is an author obviously, so this you choose on pulling the display.

-function theme_username($object) {
+function THEMENAME_username($object, $options = array()) {
   if ($object->uid && $object->name) {
     // Shorten the name when it is too long or it will break many tables.
@@ -8,9 +8,10 @@
     else {
       $name = $object->name;
-    if (user_access('access user profiles')) {
-      $output = l($name, 'user/'. $object->uid, array('attributes' => array('title' => t('View user profile.'))));
+    $profile = content_profile_load('profile', $object->uid);
+    if ($profile && node_access('view', $profile)) {
+      $options['attributes']['title'] = t('View @title', array('@title' => $profile->title));
+      $output = l($name, 'node/'. $profile->nid, $options);
     else {
       $output = check_plain($name);

This needs a bit of thinking about for those occasions when a non-registered, anonymous, user is allowed post and enter their name and url, but it should be as easy to do the same thing on these occasions too if it were so desired (not sure if it makes sense with 'nofollow'?). After making the theme override it's then simple enough to call from the THEMENAME_preprocess_node as:

  // node author link
  $vars['author'] = theme('username', user_load(array('uid' => $vars['node']->uid)), array('attributes' => array('property' => 'dc:creator cc:attributionName', 'rel' => 'foaf:maker sioc:has_creator cc:attributionURL')));

There are lots of predicates here, for most it's clear if their object should be the URL for the user or the literal value of the name string. I'm not 100% sure over the dc:creator though, it's going to the plain text name which seemed to be the best practice suggestion when used with so many others. But, hey, I might be wrong, in which case it wants to be in 'rel'.

I'll deal with the created, updated, stuff below with the comments, because I did a bit of user display side stuff with THEME_node_submitted that complicates it more than I have with THEME_comment_submitted. The logic works the same in both.

Now this all works, except of course that if the nodes are show on the page itself the title isn't displayed by the node.tpl.php but by the page.tpl.php.


I'm guessing there's a whole lot more that can be done here for site wide metadata, but so far I've just gone for the general licence, which is actually in a block, and the title. The line for the title in the page.tpl.php is as simple as:

           <?php if ($title): ?>
              <?php print $title; ?>
            <?php endif; ?>

With the empty about it's related to the page itself, and with pages with other objects on them they will only be related if their about object is the same.


The object for this can just be the url fragment, so I've make this available as $comment_url in THEMENAME_preprocess_comment and then popped it in the <div> just as above.

The title and the user are much as the node, as is the date which I'll describe here. The wish is to add the dcterms:created (and for some nodes the dcterms:modified) both of which best have an object value as a W3C datetime. So for the comment date I've just made a THEMENAME_comment_submitted theme function overrride.

function THEMENAME_comment_submitted($comment) {
  return t('Submitted by !username on !datetime.',
      # note the additional theme() param here for THEMENAME_username() as above
      '!username' => theme('username', $comment, array('attributes' => array('property' => 'dc:creator cc:attributionName', 'rel' => 'foaf:maker sioc:has_creator cc:attributionURL'))),
      '!datetime' => '<span property="dcterms:created" content="'. date('c', $comment->timestamp) .'">'. format_date($comment->timestamp) .'</span>',

It's worth noting though the date 'c' switch is PHP 5 only, and it's apparently full ISO 8601.

The other difference for comments here is that SIOC can describe the relationships between them nicely. Having toyed around with various ideas of where to put sioc:has_reply and sioc:reply_of I was struggling to find anything better than an otherwise empty element, or making an 'in reply to...' link to pop into (and CSS display: none) the submitted information. I'm sure there's a better way, but for now:

  $parent_path = 'node/'. $vars['comment']->nid;
  $parent_options['fragment'] = $vars['comment']->pid ? 'comment-'. $vars['comment']->pid : '';
  $parent_options['attributes']['rel'] = "sioc:reply_of";
  $vars['parent_link'] = l(t('in reply to...'), $parent_path, $parent_options);

Another one that's bothering me is I want to identify what the content is, but encoded content is hard work, from what I gather using RSS 1.0 content is going to be the way, but was just a start.


Throughout CURIE used from:-

 @prefix dc: <http://purl.org/dc/elements/1.1/>.
 @prefix dcterms: <http://purl.org/dc/terms/>.
 @prefix sioc: <http://rdfs.org/sioc/ns#>.
 @prefix foaf: <http://xmlns.com/foaf/0.1/">
 @prefix cc: <http://creativecommons.org/ns#>.
 @prefix wot: <http://xmlns.com/wot/0.1/>.

Apr 25 2009
Apr 25

This is part five of my series, The DX Files: Improving Drupal Developer Experience. Today I am simply posting, verbatim, a message that a potential new Drupal developer sent me. The point here is just to understand how Drupal's DX influences the way it is perceived and the kind of people that want to work with it.

Hi Barry,

I am a new Drupal user/aspiring developer. I stumbled across your presentation "Developer Experience: Because Coders are People Too" on the DrupalCon 2008 Szeged site just last week. I watched the video and just nodded my head in agreement the whole time. Thank you! This validated my own opinions ­ there is something wrong (or at least unusual) about Drupal; it's not just me not getting it.

Anonymous arrays (the poor man's OOP) and un-typed arguments seem like a terrible idea to me. I almost react viscerally against them. I can understand why some have rejected Drupal. Your friend who will not work on Drupal again ­ I am almost there myself.

A little about my background: I have a Berkeley CS degree, worked for HP for 5+ years doing software development and now work at a small company that I cofounded a couple of years ago. I have lots of OOP experience. I have worked on a few 50,000 line+ projects in C++ and Java over the years. To do these medium to largish size projects, it has been my experience that one must do "defensive" programming. Part of this is knowing that the compiler is your friend. One should write code so that mistakes can be caught by the compiler. In Drupal, there are string literals everywhere and anonymous arrays ­ basically ticking time bombs waiting to blow off limbs. I find this frightening. I would never do this in C++ or Java.

I am just starting with Drupal. Part of why I liked your presentation so much is now I realize these are issues ­ something that I never saw acknowledged elsewhere ­ so I can hopefully move on and actually start making progress with Drupal without wondering why I wasn't getting it.

I am reminded of Winston Churchill's famous quotation: "It has been said that democracy is the worst form of government except all the others that have been tried." To me, Drupal is "The worst CMS except all the others that have been tried."

Contributed modules like Views, CCK, Voting API, etc and themes make Drupal more than a CMS. It is a terrific platform. Much easier/better than rolling your own. Java doesn't have a viable competitor, that I am aware of.

So basically I want to know how can I learn more and how can I help? I want to make Drupal sites, because of its huge wealth of contributed modules and the ability to extend the system. I am extremely frustrated by many parts of Drupal. I basically agreed with everything you put in your series of blog posts about DX.

What, as a noob, can I do?

I would like to contribute some how.


Apr 25 2009
Apr 25

Second video take on content type editing is embedded below: this time focusing more on workflow-oriented fields such as status and author.

Apr 24 2009
Apr 24

So, I have been inspired from a recent video to go play with AEgir. I thought I would try it on my laptop, so off to install DAMP.

I must say, I was very impressed with the DAMP install. Simple, straightforward, quick. Oh yea, and it 'Just Works'! Very impressive. I played with the Drupal install for a few minutes and it all seems in order.

So, a little light reading on the AEgir page and it seems I need to start with installing 'drush'. A quick read of the instructions and well, this is different. A download from d.o that is NOT installed as a module. No problem and off we go.
Run through the steps in the README and change to the drupal base directory. Run drush and there are a few problems. Some warning messages. I push a little deeper and find that DAMP doesn't include the 'mysql' client. The server is there, but no client command to run. It seems that drush needs this for some of its 'sql' features. Another thing that I noticed, but thought was related to the missing client was that the 'drush sql conf' command returned an empty array. We will come back to that in a moment.

Well, I thought, ok, let's install MAMP then and see if the client is there. Sure enough, the mysql client is part of MAMP. Got them both running. Ran an export from the DAMP side. Ran an import on the MAMP side. And then copied the Drupal install into the MAMP directories.

Back to that empty array. I don't have any idea how Drupal under DAMP was accessing the database. I really need to dig a little deeper. This could be interesting. The $db_url entry had a purely generic setting. No real userid, password, or database name. So, of course, after the copy, I still had that generic entry. I replaced that with $db_url = 'mysqli://root:[email protected]:8889/acquia_drupal'; (these are the defaults) and the acquia install came up just fine in the MAMP environment.

So now I get to go back and play a bit more with drush. The 'drush sql conf' command actually displays the expected output, so it seems that it must be reading the settings.php file.

So far, I would say that the DAMP installer could use:
#1) a mysql client
#2) a conventional settings.php file entry for $db_url

It should be noted that I have just started playing with the whole drush / [DM]AMP environment and have probably made some incorrect assumptions or outright mistakes.

I'll keep plugging away at it and see what else I can find.

First thing to look for is the right place to post this where the developers can see it.
So many different interacting parts though. Not sure if it should go on AEgir, drush, or acquia (DAMP).

Apr 24 2009
Apr 24

Second video take on content type editing is embedded below: this time focusing more on workflow-oriented fields such as status and author.

Slides can be found in Flickr.

Apr 24 2009
Apr 24

At the University of Campinas, more than one hundred people, 18 talks. A lot of people to talk about Drupal, learn new skills, get to know each other and organize the Brazilian community. It was an awesome Drupalcamp. The first Brazilian Drupalcamp and one it showed that there's a huge and promissing community out there. We've got all talks on video and we'll get them online soon. Meantime, check out the photos and the tweets. There'll be soon two other Drupalcamps in Argentina (june) and Perú (september). In this way, we'll continue with our plan: host a South American DrupalCon in 2010!

Apr 23 2009
Apr 23

These are exiting days for Drupal. Behind D7UX, a cryptic name meaning “Drupal 7 User Experience” hide bunch of talented professionals who really want to take the notoriously complex piece of code to a next level. Their headquarters: http://d7ux.org

So, it's time to join in. Here's my first contribution, a 10-min video embedded below what tries to explain how content type editing should work in new UI framework.

The slides I am using in the presentation can be checked out in Flickr.

Some background reading: my Drupal UI challenges article, especially “Views + Panels + CCK UI” section and also wireframe by Lullabot what explains the complexities around mapping content editing and viewing UIs.

Apr 23 2009
Apr 23

Drupal developer personas

This thing was constructed on April 23, 2009, and it was categorized as Drupal.
You can follow comments through the RSS 2.0 feed. Both comments and trackbacks are closed.

I was just going through some work I did a few months back and found some personas I wrote based off of some interviews with (mostly) Drupal developers. I ended up finding similarities to some drupal.org personas written in 2007, so I used the names and some of the language to write my own.

Out of the 22 people interviewed they mostly fell into three environments – academic/non-profit, a web development shop and a kind of super-hobbyist (meaning, they do a lot of web development in their free time). There were a couple solo freelancers, but I’d want to interview more to seriously stand behind that persona (Danielle).


Profile: Tim doesn’t have formal training in programming, but he geeks out on learning new things and likes to set time aside when he’s not at work to pursue projects he feels will be of value to his community. Recently he’s come up with what he thinks is a great new idea for a social networking site, and wants to put some of his new PHP skills to use.

Relationship to Drupal: He’s excited by the community and hopes to contribute one day. Occasionally he finds a bug or an error he doesn’t know how to fix, and spends what he feels like is way too much time on the Drupal site and in forums. If he can’t find a solution, he’ll just learn to live without the module, or even the functionality.


  • Feel capable of solving the issues as they arise
  • Feel supported by his immediate web community
  • See his ideas come to life
  • See evidence of people interacting with his site
  • Create an active, popular website
  • Build a site he thinks looks and works right
  • Earn a supplemental income


Profile: Wendy has worked with CMS’s before, and just took on a new job in an academic environment to manage the website. Her first task is to redesign the old site in Drupal, which was chosen a few months back by her boss. Her boss helps her in planning, and she has two part time students available to help out with the tech when needed. While her job primarily consists of working on the site, she finds herself in a lot of meetings. She feels fortunate however that it’s a pretty low risk environment – as long as she doesn’t rock the boat her deadlines aren’t cut-throat. She can read code and do a little design, but she really enjoys figuring out how to organize and structure information for the users.

Relationship to Drupal: Wendy really appreciates all that Drupal can do, but she really wishes that some modules were better documented – she’s under a lot of pressure to add certain kinds of functionality and there’s not much budget to do it. Sometimes she’ll post a question on a forum, but otherwise sticks to reading through what she can find online. She hasn’t had much time to really consider getting involved in the community.


  • Feel like she has the work under control and on time
  • Discover exciting, dynamic new tools to learn and incorporate into the website
  • Come up with clever and efficient ways to structure all of the data
  • Build a site that users really care about
  • Manage her communities expectations about the site


Profile: Dan is a code-monkey who primarily builds custom Drupal modules for sites his company makes for clients, but lately he’s taken over a bigger role on some smaller sites – communicating with clients and building the entire site himself.  Dan has a lot of resources to draw on in his small company to help him with his expanded role, from a project manager, to an Information Architect, to other programmers like himself.

Relationship to Drupal: Dan’s a big fan – he’s been using Drupal and involved with the community for several years now. He feels pretty at ease with at all – but really gets annoyed when there’s a change in the module that disrupts his typical way of getting things done.


  • Feel like the work is under control in a fast paced environment
  • Feel smart and clever (and in control) with clients
  • Develop a site that pleases his clients
  • Feel like he’s contributed something new or special
  • Feel part of a community


Profile: Danielle has been working freelance with small business and non-profit clients for several years now. She has an arts background and is self taught (and very proficient) with XHTML, CSS, some JavaScript and visual design. She’s started using CMS’s to help her maintain her clients’ websites. She spends a lot of time with her clients sites, and feels very personally involved with their success.

Relationship to Drupal: Danielle reluctantly moved to Drupal because of a client’s request, but she’s becoming more intrigued as she learns the interface and understands the functionality available. As a late-comer to CMS’s, she’s happy to not have to maintain a static site any longer. Problem solving is intimidating for her though – there’s a lot of information out there and she’s intimidated by the “gear-heads” in some of the forums.


  • Manage her clients expectations
  • Ensure a successful, attractive site for her client
  • Learn new skills
  • Earn a living doing work she enjoys independently

I’d say these are still a work in progress. Becuase I wasn’t focusing on d.o while writing I’m not going to be bold and edit the wiki :)

This thing was constructed by Becca .

You can follow comments through the RSS 2.0 feed. Both comments and trackbacks are closed.

« Kim Goodwin on project planning New Project: Drupal Documentation IA »
Apr 23 2009
Apr 23

Helping out on Drupal 7 UX, part 1

These are exiting days for Drupal. Behind D7UX, a cryptic name meaning "Drupal 7 User Experience" hide bunch of talented professionals who really want to take the notoriously complex piece of code to a next level. Their headquarters: http://d7ux.org

So, it's time to join in. Here's my first contribution, a 10-min video embedded below what tries to explain how content type editing should work in new UI framework.

The slides I am using in the presentation can be checked out in Flickr.

Some background reading: my Drupal UI challenges article, especially "Views + Panels + CCK UI" section and also wireframe by Lullabot what explains the complexities around mapping content editing and viewing UIs.

Apr 23 2009
Apr 23

Have you been looking for an excuse to play around a bit with Drupal 7, and have an interest in helping to directly shape it? Would you like to not only see how Drupal core contributors collaborate together, but become one yourself? Do you have an itch you'd like scratched and are willing to help scratch others' in return? Would you like to be exposed to new and interesting areas of Drupal you might not have otherwise experienced? Are you exceptionally good at finding faults and breaking things?

If so, drop by #drupal-dev on irc.freenode.net on Saturday (May 16) for a patch review sprint! (What is a patch review sprint? / How to connect to IRC?) While somewhat informal, there will be people around all weekend to help get new patch reviewers started and to help guide seasoned contributors to important patches.

Our goal is to try and knock the core patches to review queue down to zero (or as close to it as possible) by trying out patches to see how they work, and recommending ways that they can be improved. The Patch review sprints page has more information on how patch reviews work, a handy cheat-sheet of all the commands you need, and a list of prerequisites in order to participate.

Please note that "coding skills" is not on the list of prerequisites. While people with coding skills can perform certain types of reviews better than non-coders, non-coders can also perform certain types of reviews better than coders. In short: everyone is welcome!

Hope to see you there! :)

Apr 23 2009
Apr 23

Attached below are the slides for the April, 2009 ASU Drupal Users Group presentation I gave on maintaining sites using a combination of CVS (to checkout Drupal core and contrib modules) and Subversion (for backing up your site's code base and integrating with locally maintained modules and themes).

Here's a quick rundown of links mentioned in the presentation:

Read on after the break for code samples.

A quick reference for the shell scripts we created (OS X):

Create or update ~/.bash_profile

export PATH=$PATH:/usr/local/bin

Bash script for checking out Drupal core

Create the shortcut command, drcvs_core in /usr/local/bin/:

cvs -z6 -d:pserver:anonymous:[email protected]:/cvs/drupal co -d $1 -r DRUPAL-$2 drupal

Make the file executable:

chmod ugo+x /usr/local/bin/drcvs_core

Bash script for checking out Drupal modules

Note: Be sure to make the bash script executable (see above).

Create the shortcut command, drcvs_module in /usr/local/bin/:

cvs -z6 -d:pserver:anonymous:[email protected]:/cvs/drupal-contrib checkout -r DRUPAL-$2 -d $1 contributions/modules/$1

Bash script for checking out Drupal themes

Note: Be sure to make the bash script executable (see above).

Create the shortcut command, drcvs_theme in /usr/local/bin/:

cvs -z6 -d:pserver:anonymous:[email protected]:/cvs/drupal-contrib checkout -r DRUPAL-$2 -d $1 contributions/themes/$1

Bash script for cleaning up for Subversion after a CVS update

Note: Be sure to make the bash script executable (see above).

Create the shortcut command, drcvs_cleanup in /usr/local/bin/:

for FILE in `svn status $1 | grep '?'`; do svn add $FILE; done;

for FILE in `svn status $1 | grep '!'`; do svn rm $FILE; done;

Sample usage

Checkout Drupal core from CVS and commit to Subversion

cd /path/to/subversion/branches/folder

drcvs_core cvs-demo 6-9
svn add cvs-demo

svn commit -m "Adding drupal core for cvs demo site"

Checkout modules from CVS and add to Subversion

cd sites/all/modules

drcvs_module cck 6--2-2

drcvs_module views 6--2-4

drcvs_module cvs_deploy 6--1-0
svn add *

svn commit -m "Add CCK, Views and CVS Deploy modules"

Checkout a theme from CVS and add to Subversion

drcvs_theme zen 6--1-0
svn add zen

svn commit -m "Add Zen theme"

Updating Drupal core or modules from CVS

cd /path/to/drupal

cvs up -dP -r DRUPAL-6-10

drcvs_cleanup .

svn commit -m "Update to Drupal 6.10"

cd /path/to/views

cvs up -dP -r DRUPAL-6--2-5

drcvs_cleanup .

svn commit -m "Update to Views 6.x-2.5"

Telling Subversion to ignore files

cd /path/to/sites/default

svn propedit svn:ignore .

# Add ‘settings.php’ to the first line of the file and save it

svn commit . -m "Ignore settings.php"

Referencing an external Subversion project

cd /path/to/themes

svn propedit svn:externals .

Add the following to new line(s) in the file

asuzen https://opensource.asu.edu/svn/asuzen/branches/asuzen-6.x/

Retrieve the external project and commit the change

svn up

svn commit -m "Add external reference to ASU Zen theme"

Apr 23 2009
Apr 23

While I was at Drupalcamp Galway, Stéphane (scor) recorded an interview with me about not just the Galway doc sprint, but also about future doc sprints around the world. He's got the interview up on his blog and it's only 6 minutes long. Give it a listen and let me know about your Drupal event and how I can help you out.

Apr 23 2009
Apr 23

I presented on Drupal at UNC's An Introduction to Content Management Systems workshop last week. The presentation is geared to people trying to decide between Drupal, Joomla, and Wordpress. I hope that I swayed a few to the Drupal camp!

Apr 22 2009
Apr 22

I've been involved in the organisation of a number of scientific conferences over the past few years. For example 4m/ICOMM 2009 (submissions), I*PROMS 2009 (submissions). The conference sites are usually powered by drupal, the submissions using OpenConf. Managing the submission and peer review of papers is a chore, unfortunately, as is often the case, software gets in your way. So here I try to skim over some of the experiences I had with OpenConf - the good and the bad.

I've tested indico, which looks like a very good system, but it is heavy and over-engineered, especially if you want to run a couple of events, and not hundreds or thousands. It might be good for organisations managing a big number of events, but not for us.

After going through a number of trials I've settled on openconf. It was simple. It fitted the current web infrastructure - LAMP. I reckoned, I could eventually integrate it, or simply transfer some of the data into drupal, and maybe even benefit from code reuse. Surprisingly, I ended being both pleasantly surprised and not so.

It was an interesting experience. Openconf is a strangely written software. It is quite hackish, in a bad way. Inside it uses quite a lot of cryptic names, virtually no code documentation or useful comments, etc... A lot of 'bad style' code. The system won't win a beauty or security contest - that's for sure.

What won me over, and I will probably use it again, is that it is trivially moldable to my requirements. Let's give a few examples.

Styling it

Well, it has very little significant markup present. Minimal, considering some of the monstrosities I've seen over the years. To personalise the look of the submission pages I had to modify three nearly empty files - the header and footer php scripts for some limited wrapping markup and the openconf css file. That's all. Ok, that was sufficient to modify the overall styling, so that it is consistent with the conference 'mother sites'.


Conference systems are not automatically adaptable to your workflow. You usually adapt your workflow to your system. They are not unique in this respect. A lot of enterprise CRM, workflow whatnot systems force you to adopt what they consider good practices, but that is a rant for antoher time - it makes good business for a lot of people. In this respect openconf is not unique - it presumes a workflow, and it even uses terminology which was alien to us.

The first thing to change was the terminology. An afternoon of reading code and testing resulted in a handful of scripts to replace advocates for theme chairs and some such. Annoying, sure, but not that hard.

A sequence of happy coincidences, helped with other problems, for example how do you check if authors revised their papers after review and if not send them a reminder email. I was prepared to check the file modification times and filter by date. Doable, but would result in some strange looking sql queries. Instead, due to publisher requirements, I ended checking for file types, and getting the list of forgetful paper authors that way. Funnily enough, the email.php file is contains both the best and worst of the code in openconf. The emails and recipient kinds declaration is fairly declarative. Just an array of definitions with stuff like titles, and sql queries in there. And based on your choice and php name magic you get the appropriate template, for which the appropriate list of recipients is pulled from the db. Nice. To make matters even better, it is a long flat file of if .. else .. statements with a few function declarations in the middle. It took me a while to get used to that. But for all its ugly insides, there is something good - it is easy to add modify the markup. No over-engineered templates - the system doesn't really need that. These cosmetic changes are surprisingly important, since it helped me improve the interface, to differentiate between emails for positive, negative and other causes - no wrong emails afterwards.

Random addons

For one of the last conferences I had to add scripts to make all paper authors reviewers, do custom reports etc.... It was a couple of days of work, mostly testing and reading code. And only one file to modify - the one where I had to add a link to the new functionality. All that required very little modification. Just add the new functionality.

The end is nigh

To wrap it up. Even badly written software could end up being more useful in practice than a number of well written, carefully designed systems. I have a feeling that this is the story of a lot of php projects, and the language itself. Could it be that the beauty is in the eye of the beholder? Or maybe the authors guys know something I miss - because the software does do the job, maybe not brilliantly, but good enough to be re-used again and again.

What makes openconf so moldable? Probably the php "component" architecture, that is each different kind of page has a different entry point php script, with shared includes for code reuse. This meant I wouldn't break more than one page at a time. Which in turn can lead to task based modifications, which in turn made my life easier, despite occasional the surprises.

Apr 22 2009
Apr 22

This past weekend, I had the privilege of being one of the chosen attendees for Social Web FooCamp. Needless to say, I was flattered and had an amazing time (thanks again, @daveman692 and @davemorin ) . One thing, however, became very apparent: the conversation, currently, is being dominated by the 'big players' (Google, Yahoo, Facebook and Myspace predominantly). In several discussions I found myself increasingly dropping the phrase:

... on the rest of the web

the big guys

First off, this is not a critique of the Google's and Facebook's of the internet. They are incredibly valuable to the growth of the openweb. The fact that Google, Yahoo and Myspace all three have various OpenID and OAuth initiatives in the wild and are actively pursuing additional ways to open their data is awesome (and Facebook wants to get there). It helps raise awareness and bring (slash confirm) "legitimacy".

The big guys also have resources. They can attend the conferences (and camps!) and have dedicated resources to write the standards, participate in the discussions and help shape the future.

However, they are only part of the discussion.


The issues the major providers face are different from the rest. They have a few sites with large numbers of users (hundreds of millions). Out here on the rest of the web, we have millions of websites, each with a "small" number of users (hundreds or thousands). We all understand the necessity for open data, identity, standards and protocols, but our reasoning tends to be slightly different.

The big guys recognize the benefit of exposing their data and most are providing OpenID and various levels of OAuth. How many are consuming it?

Sure, the big players want to be the primary authority for your identity and your information. In some cases, it is their business. But, rather than ranting against 'the man', I ask: have we - the rest of the web - given them a compelling reason to yet?

open source platforms for the open web

It's one thing for a major site (with hundreds of millions of users) to act like a silo, but on the rest of the web it amounts to isolation.

Those of us working on open source web platforms have an enormous potential for influence here. Implementing the various open standards "from scratch", while possible, is not realistic or even necessary. Increasingly, individuals have Wordpress blogs or perhaps their company, organization or club has a Drupal site. Web developers are increasingly turning to these platforms, or development frameworks such as Rails and Django. These platforms all have a real opportunity to bake in implementations of these open standards. The DiSo project offers a central place for co-ordination around these efforts.

We have data - gobs of it. We also, collectively, have the users and, in most cases, have more authoritative information about them (we know ourselves, our employees and our members).

We - the rest of the web - need to join the conversation: attend the events, participate in the mailing lists, and build the code to power the open, social web.

Apr 22 2009
Apr 22

This past weekend, I had the privilege of being one of the chosen attendees for Social Web FooCamp. Needless to say, I was flattered and had an amazing time (thanks again, @daveman692 and @davemorin ) . One thing, however, became very apparent: the conversation, currently, is being dominated by the ‘big players’ (Google, Yahoo, Facebook and Myspace predominantly). In several discussions I found myself increasingly dropping the phrase:

… on the rest of the web

the big guys

First off, this is not a critique of the Google’s and Facebook’s of the internet. They are incredibly valuable to the growth of the openweb. The fact that Google, Yahoo and Myspace all three have various OpenID and OAuth initiatives in the wild and are actively pursuing additional ways to open their data is awesome (and Facebook wants to get there). It helps raise awareness and bring (slash confirm) “legitimacy”.

The big guys also have resources. They can attend the conferences (and camps!) and have dedicated resources to write the standards, participate in the discussions and help shape the future.

However, they are only part of the discussion.


The issues the major providers face are different from the rest. They have a few sites with large numbers of users (hundreds of millions). Out here on the rest of the web, we have millions of websites, each with a “small” number of users (hundreds or thousands). We all understand the necessity for open data, identity, standards and protocols, but our reasoning tends to be slightly different.

The big guys recognize the benefit of exposing their data and most are providing OpenID and various levels of OAuth. How many are consuming it?

Sure, the big players want to be the primary authority for your identity and your information. In some cases, it is their business. But, rather than ranting against ‘the man’, I ask: have we - the rest of the web - given them a compelling reason to yet?

open source platforms for the open web

It’s one thing for a major site (with hundreds of millions of users) to act like a silo, but on the rest of the web it amounts to isolation.

Those of us working on open source web platforms have an enormous potential for influence here. Implementing the various open standards “from scratch”, while possible, is not realistic or even necessary. Increasingly, individuals have Wordpress blogs or perhaps their company, organization or club has a Drupal site. Web developers are increasingly turning to these platforms, or development frameworks such as Rails and Django. These platforms all have a real opportunity to bake in implementations of these open standards. The DiSo project offers a central place for co-ordination around these efforts.

We have data - gobs of it. We also, collectively, have the users and, in most cases, have more authoritative information about them (we know ourselves, our employees and our members).

We - the rest of the web - need to join the conversation: attend the events, participate in the mailing lists, and build the code to power the open, social web.

Apr 21 2009
Apr 21

My Google Summer of Code 2009 proposal was accepted. The basic idea is to develop at least three modules based on Recommender API. For example, one module is to recommend Flash videos based on users' viewing history like in YouTube. A mockup screenshot is like this:

For more details and discussion, please go to http://groups.drupal.org/node/19894.

(This site is heavily abused by spams, and the captchas don't work well for me. Commenting is temporarily disabled. Sorry about that...)

Apr 21 2009
Apr 21

Update: Feb 17, 2010 This article was written nearly a year ago when CTools was still in alpha. I don't know how much of it applies anymore but I've been told there's an up to date plugin example that ships with CTools now so you'll want to look to that as an example.

Note: This article requires the current Panels 3 / CTools development snapshots (or the beta when it comes out) as the alphas do not contain the recent changes to content types.

When you open the dialog to add content to your panel, there are many items already in there which come from core and contributed modules you have installed. But what if you want to add something new? There are a couple of options.

The simple way is to do it right through the UI with the option to add "New custom content" but this is only recommended if you just need to add a few lines of text or want to test something out. For dynamic content, you'll want to make your own content type. A content type is one of several types of CTools plugins along with "relationships", "layouts", and more. It is a discrete bit of content, defined in code, that can be added as a pane to your panel. You define the content type in a module and then it is available to the Panels UI. This article will walk you through creating a content type using my Author Pane as an example. You can also look at ctools/plugins/content_types for examples that come with CTools.

Note that you need to create content types inside of a module. If you have a site module for customizations you can use that or you can create a module just for this.

Step 1: Name your content type

Each content type needs a distinct name that will not conflict with any other content type name, including those coming from other contributed modules. Because of this, it's best to include your module's name in the content type name. If your module is only providing one content type, you can simply use your module name for the content type name. In Author Pane, I only create one content type so I named it simply "author_pane".

Step 2: Create the file and tell CTools where to find it

Your content type needs to live in an include file of the same name. In my case, author_pane.inc. You should put this in a directory that only contains content types. The recommended directory structure is: moduledir/plugins/content_types. For Author Pane, the complete path with file is author_pane/plugins/content_types/author_pane.inc

Once you have the file and directories set up, you need to tell CTools where your plugins are. If you followed the recommended directory structure, you can simply drop this code into your module (be sure to change MODULE_NAME to your module's name.):

* Implementation of hook_ctools_plugin_directory().
function MODULE_NAME_ctools_plugin_directory($module, $plugin) {
if ($module == 'ctools') {
return 'plugins/' . $plugin;

This code will look for content types in plugins/content_types, relationships in plugins/relationships, and so on for all the various plugins. Don't worry about creating the other directories if your module doesn't make any other plugin types.

Step 3: Create the content type

The rest of this will walk you through the Author Pane content type, explaining what each bit does, and how you should change it for your own content type. All of these functions go in the ct_name.inc file you created in the last step.

Tell CTools about your content type:

* Callback function to supply a list of content types.
function author_pane_author_pane_ctools_content_types() {
return array(
'single' => TRUE,
'title' => t('Author Pane'),
'icon' => 'icon_user.png',
'description' => t('Author related variables gathered from helper modules.'),
'required context' => new ctools_context_required(t('User'), 'user'),
'category' => t('Advanced Profile Kit'),
'defaults' => array('image_path' => '', 'template_file' => 'author-pane'),

Here's what each bit in that code means:

  • The function name is MODULE_NAME_CT_NAME_ctools_content_types. Because our module name and content type name are the same, we have "author_pane" twice. This looks a little funny but doesn't hurt anything.
  • We are only creating one content type so we set 'single' to true.
  • The title is the name that shows up in the add content dialog.
  • The icon is the icon that shows next to the name that shows up in the add content dialog. Since this is user related, we are using the user icon. This icon is in CTools and you will either need to copy it to your plugin directory or put the full path to it (or make your own icon). If you don't provide an icon, CTools will provide a default.
  • The description shows up when you hover over the item in the add content dialog.
  • Required context is what context this content type needs to work. In this case, we need the user object so we make use of the user context. If the Panel does not have a user context on it, our content type will not show up as an option to add.
  • The category defines where our content type shows up in the add content dialog. For a user related item, you could use simply "User". In this case, I wanted it to be grouped with other items provided by Advanced Profile Kit as that is where it will most commonly be used. If you are creating this content type for your own site, you can use whatever category you like. If you are creating it for others to use, be careful what you choose here to avoid cluttering the add content dialog.
  • Defaults is an array that contains the default values, if any, for the items on your add/edit form.

Tell CTools how to display your content type:

* Output function for the 'author pane' content type.
// The function name is MODULE_NAME_CT_NAME_content_type_render
function author_pane_author_pane_content_type_render($subtype, $conf, $panel_args, $context) {
// $context in this case is a user context, so we can get the user object
// from it and put it into $account.
$account = isset($context->data) ? drupal_clone($context->data) : NULL;

// Make a new empty "block" which will be a Pane you can add to your Panel.
$block = new stdClass();

if ($account) {
// Set the title of the block to the name of the user. It can be overridden
// through the UI as well.
$block->title = check_plain($account->name);

// Call the function that makes the author pane and use that for the block
// content. In our case, this is just one line but you can have whatever
// code you need to assemble the content and then assign it to the
// $block->content variable.
$block->content = theme('author_pane', $account, $conf['image_path'], $conf['template_file']);
else {
// If somehow the user context is empty, this is a fallback message but
// that should never happen.
$block->content = "User information not available";

return $block;

Define the settings form for the pane:

* Returns an edit form for the custom type.
// The function name is MODULE_NAME_CT_NAME_content_type_edit_form
function author_pane_author_pane_content_type_edit_form(&$form, &$form_state) {
// The current configuration
$conf = $form_state['conf'];

// This and the next one are normal FAPI form making.
$form['image_path'] = array(
'#type' => 'textfield',
'#title' => t('Image directory'),
'#size' => 50,
'#description' => t('Full path to image directory, not including leading or trailing slashes. Use [theme_path] to substitute the active theme\'s path. If left blank the images in the module directory will be used.'),
'#default_value' => $conf['image_path'],
'#prefix' => '

'#suffix' => '


$form['template_file'] = array(
'#type' => 'textfield',
'#title' => t('Template file'),
'#size' => 50,
'#description' => t('Template file to use for the author pane.'),
'#default_value' => $conf['template_file'],
'#prefix' => '

'#suffix' => '


Prepare the settings form for submission.

function author_pane_author_pane_content_type_edit_form_submit(&$form, &$form_state) {
// For each part of the form defined in the 'defaults' array set when you
// defined the content type, copy the value from the form into the array
// of items to be saved. We don't ever want to use
// $form_state['conf'] = $form_state['values'] because values contains
// buttons, form id and other items we don't want stored. CTools will handle
// the actual form submission.
foreach (array_keys($form_state['plugin']['defaults']) as $key) {
$form_state['conf'][$key] = $form_state['values'][$key];

Define the title displayed on the layout page of the panel:

This is the title you see when you are editing the Panel. It is not the same as the title
of the pane when you are viewing the panel, which is defined in the render function.
function author_pane_author_pane_content_type_admin_title($subtype, $conf, $context) {
return t('"@s" author pane', array('@s' => $context->identifier));

Explore the possibilities

This example has shown the most common bits you will need to create a content type. With it, you can make use of the panel's context as well as settings on the pane and your own code to come up with your own dynamic, custom content. This lives in a file that can be checked into version control rather than just being set in the database. You can also include it with a module for distribution to share with others. From here, there are more complicated things you can do such as multi-page settings and more.

If you maintain a contributed module, consider what parts of it could be encapsulated into content types to make it easier for your users to add them to their own panels. While Panels will make use of blocks you provide, that is only part of the story. Making it a true content type gives you more options for integration such as showing content for a particular user based on the user context or a node based on the node context.

The possibilities are endless.

Much credit goes to merlinofchaos who helped me quite a bit in writing this as well as converting my content types from Panels 2

Apr 21 2009
Apr 21

As of half a day ago, for the Google Summer of Code 2009 have been announced (and of course, also for the other participating organisations). We selected 18 wicked students with intriguing project proposals, and had a hard time sorting out which ones to take because the number of promising proposals was pretty high this time for Drupal. We still should be able to provide motivated students with mentoring even if they didn't make it to the final list, assuming Google's prize money was not the primary motivation to apply for SoC.

In addition to the official Drupal list, I also noticed a hosted by Creative Commons. Also, former Drupal SoC alumni Allister Beharry (who worked on DAST in 2007) is now showing up with a . Other favorites of mine include the entirety of KDE and X.org projects, as well as my buddy klausi getting accepted for .

The coolest thing for me personally, though, is the selection of not one but an thrilling number of two awesome projects related to Version Control API: (a.k.a. marvil07) will work on internal API improvements and other stuff like SSH key authentication, while (a.k.a. chrono325) takes care of better VCS support and Rules integration. Both want to help with the transition of Drupal core to a distributed version control system such as Git, and will be mentored by Tony Narlock (skiquel), Sam Boyer (sdboyer) and of course me. With a little luck, we should be able to avoid the epic failure of last year's project and push Version Control API to the next level.

And of course, pushing it onto drupal.org is still on the plate and will be the first thing for me to work on after I finally submit my thesis in mid May.

Apr 20 2009
Apr 20

When I migrated my blog from Wordpress to Drupal one key thing I still wanted to do was be able to use ecto to post messages from my laptop rather than through the web interface - it can be just easier at times. Thankfully Drupal has a plugin/module built in which does this for you, the BlogAPI module. So I activate the module then try to connect using ecto only to be greeted with the lovely message:

The response from the server did not contain valid data.

This was frustrating, it should just work, right? Thankfully ecto has a console feature which displays all communications with the server, and I was able to see it submit:

<?xml version="1.0" encoding="UTF-8"?>

This is a normal Blogger API call to find out what blogs a given user (me) has permission to write on at a given blog installation, and should have returned some valid data. Here's what came back:

<?xml version="1.0"?>


Obviously this isn't quite right.. I dug through the code, adding print and print_r statements where I thought they might help, until I came to blogapi.module line 937 which says:

$available_types = array_keys(array_filter(variable_get('blogapi_node_types', array('blog' => 1))));

This is supposed to grab the blogapi_node_types system variable which stores a list of the Drupal content types you told it were allowed to be written to using the BlogAPI.. and I had set them, right?


No, as it turned out I hadn't, though I thought I had.

Once I went to /admin/settings/blogapi I was able to mark a few content types to be editable, hit save, go back to ecto and finally see what I wanted:



Ok, so next problem.. I wrote the above, including the two pasted images, hit Publish but started getting the following error:

<?xml version="1.0"?>
   <value><string>It is not possible to upload the file, because it exceeded the maximum filesize of 0 bytes.</string></value>

Obviously a problem persisted.

I cranked open the files and inserted some extra code that made it say::

<?xml version="1.0"?>
   <value><string>It is not possible to upload the file, because it exceeded the maximum filesize of 0 bytes and your file was 12.04 KB.</string></value>

From this you can see that it was getting the file, but it was basically saying that my account was not set up to accept attachments, which was not true as I was the administrator and could do everything, right?

I went back to the BlogAPI settings page, ensured that the file settings looked correct..


.. scratched my head. Then I went to look at the permissions.. as it turned out I had not enabled "administer content with blog api" for my user group.


Doh. I enabled that permission, saved it, and now when I went back to the BlogAPI settings page there was a new item waiting for me:


I expanded that, set the same 1MB and 5MB... and saved..

Et voila! That did the trick, I can now post embedded images too!

Apr 20 2009
Apr 20

People often need to build a custom user interface on top of the Alfresco repository and I see a lot of people asking general questions about how to do it. There are lots of options to consider. Here are four options for creating a user interface on top of Alfresco, at a high level:

Option 1: Use your favorite programming language and/or framework to talk to Alfresco via REST or Web Services. PHP? Python? Java? Flex? Whatever, it’s up to you. The REST API is nice because if you can’t find a URL that does what you need it to out-of-the-box, you can always roll-your-own with the web script framework. This option offers the most flexibility and creative freedom, but of course you might end up building constructs or components that you may have gotten “for free” from a higher-level framework. Optaros‘ streamlined web client, DoCASU, built on Ext-JS, is one freely-available example of a custom UI on top of Alfresco but there are others.

Option 2: Use Alfresco’s Surf framework. Alfresco’s Surf framework is just that–it’s a framework. Don’t confuse it with Alfresco Share which is a team-centric collaboration client built on top of Surf. And, don’t assume that just because a piece of functionality is in Share it is available to you in the lower-level Surf framework. You may have to do some extra work to get some of the cool stuff in Share to work in your pure Surf app. Also realize that Surf is brand new and still maturing. You’ll be quickly disappointed if you hold it to the same standard as a more widely-used, well-established framework like Seam or Django. Surf is a good option for quick, Alfresco-centric solutions, especially if you think you might want to leverage Alfresco’s browser-based site assembly tool, Web Studio, at some point in the future. (See Do-it-yourself Alfresco Surf Code Camp).

Option 3: Customize the Alfresco “Explorer” web client. There are varying degrees to which you can customize the web client. On one end of the spectrum you’ve got Freemarker “presentation templates” followed closely by XML configuration. On the other end of the spectrum you’ve got more elaborate enhancements you can make using JavaServer Faces (JSF). Customizing the Alfresco Explorer web client should only be considered if you can keep your enhancements to an absolute minimum because:

  1. Alfresco is moving away from JSF in favor of Surf-based clients. The Explorer client will continue to be around, but I wouldn’t expect major efforts to be focused on that client going forward.
  2. JSF-based customizations of the web client can be time-consuming and potentially complex, particularly if you are new to JSF.
  3. For most solutions, you’ll get more customer satisfaction bang out of your coding buck by building a purpose-built, eye-catching, UI designed with your specific use cases in mind than you will by starting with the general-purpose web client and extending from there.

Option 4: Use a portal, community, or WCM platform. This includes PHP-based projects like Drupal (Drupal CMIS Screencast) or Joomla as well as Java-based projects like Liferay and JBoss Portal. This is a good option if you have requirements that match up well with the built-in (or easily added-on) capabilities of those platforms.

It’s worth talking about Java portal servers specifically. I think people are struggling a bit to find The Best Way to integrate Alfresco with a portal. Of course there probably is no single approach that will fit every situation but I think Alfresco (with help from the community) could do more to provide best practices.

Here are the options you have when integrating with a portal:

Portal Option 1: Configure Alfresco to be the replacement JSR-170 repository for the portal. This option seems like more trouble than it is worth. If all you need is what you can get out of JSR-170, you might as well use the already-integrated Jackrabbit repository that most open source portals ship with these days unless you have good reasons not to. I’m open to having my mind changed on this one, but it seems like if you want to use Alfresco and a portal, you’ve got bigger plans that are probably going to require custom portlets anyway.

Portal Option 2: Run Alfresco and the portal in the same JVM (post). This is NOT recommended if you need to scale beyond a small departmental solution and, really, I think with the de-coupling of the web script engine we should consider this one deprecated at this point.

Portal Option 3: Run the Alfresco web script engine and the portal in the same JVM. Like the previous option, this gives you the ability to write web scripts that are wrapped in a portlet but it cuts down on the size of the web app significantly and it frees up your portal to scale independently of the Alfresco repository tier. It’s a fast development cycle once you get it set up. But I haven’t seen great instructions for setting it up yet. Alfresco should document this on their wiki if they are going to support this pattern.

Portal Option 4: Write your own portlets that make services calls. This is the “cleanest” approach because it treats Alfresco like any other back-end you might want to integrate with from the portal. You write custom portlets and have them talk to Alfresco via REST or SOAP. You’ll have to decide how you want to handle authentication with Alfresco.

What about CMIS?

CMIS fits under the “Option 1: Use your favorite programming language” and “Portal Option 4: Write your own portlets” categories. You can make CMIS calls to Alfresco using both REST and SOAP from your own custom code, portlet or otherwise. The nice thing about CMIS is that you can use it to abstract the underlying repository so that (in theory) your front-end code will work with different CMIS-compliant back-ends. Just realize that CMIS isn’t a fully-ratified standard yet and although a CMIS implementation is in the Enterprise version of Alfresco, it isn’t clear to me whether or not you’d be supported if you had a problem. (The last response I saw on this specific question was a Peter Monks tweet saying, “I don’t think so”).

The CMIS standard should be approved by the end-of-the-year and if Alfresco’s past performance is an indicator of the future, they’ll be the first to market with a production-ready, fully-supported CMIS implementation based on the final spec.

Pick your poison

Those are the options as I see them. Each one has trade-offs. Some may become more or less attractive over time as languages, frameworks, and the state of the art evolve. Ultimately, you’re going to have to evaluate which one fits your situation the best. You may have a hard time making a decision, but you have to admit that having to choose from several options is a nice problem to have.

Apr 20 2009
Apr 20

Over the last couple of years, our development approach has shifted considerably. When we originally began doing client work, we regularly used a fairly wide variety of tools (Wordpress, custom apps in PHP, Ruby on Rails, or Java enterprise) in addition to Drupal to accomplish our clients' wide variety of projects.

Since the release of Drupal 5 & 6, we've seen the Drupal project mature into a very capable general purpose tool. As a result, we've transitioned away from having a large toolbox of languages and tools to use on a given project, to building most of our projects on Drupal.

What is Drupal?

Drupal is an open source Content Management System (or perhaps more accurately, a Content Management Framework). In high-level terms, it is a software package which can be customized to create websites with widely varying capabilities, from large social networks, to running a newspaper, to applications such as a CRM or a rental fleet tracking and reservation system.

Why do we use Drupal over other CMS systems?

There are many other Content Management Systems, such as Joomla or MODx, which have been written to do the same task as Drupal. So why do we choose Drupal for our projects over these others?

  1. It's open source - Drupal, like many other Content Management Systems, is Open Source. This means there are no license fees to use it, and the code is completely open an transparent. If we find a bug in Drupal, we can report it, fix it ourselves, and contribute the fix back to the community rather than depend on the original development team to fix the bugs. Hundreds of shops and individuals fixing and improving Drupal means much stronger and secure code.
  2. Clear, well-documented API - Many of our clients have specific requirements that cannot be fulfilled using core Drupal or community modules. In these instances, we often have to write custom modules to extend Drupal. Having a clear and well documented API saves us both time and frustration, which translates into saving our clients money.
  3. Flexibility - Each new release of Drupal is more flexible than the last. This is due, in many ways, to the power of the API mentioned above. This is not to suggest that Drupal is encumbered with many features users will never use. Core Drupal is kept slim and mean, with much added functionality coming by way of community module.
  4. Large User Community - Drupal has a strong community of users. This means that when we encounter a situation new to use, there is usually someone who has been there before. Being able to rely on community experience (and in turn offering our experience) means much less time hacking through problems.
  5. Responsive & Approachable Developer Community - When bugs and security issues are found, or new features are suggested, the Drupal development community is quick to get stuff done. User feedback is sought, and the development process is very transparent.
  6. Secure - Drupal's codebase is very secure. A lot of care is taken to prevent opening potential exploits. On rare occasions, exploits are found. Usually, they are fixes on the same day, and a new version of Drupal with the exploit closed is made available for download. This, combined with the the simplicity of keeping Drupal up-to-date, makes it secure.

Of course, there are situations where Drupal doesn't fit the bill. In these cases, we recommend solutions based on other software packages. As an example, for a client who wants a full-featured blog, but has no intention of ever adding new features, we would recommend a solution developed based on Wordpress.

Why choose Drupal over a custom application?

In most cases, writing a custom application is not feasible, since a large part of what is required for a client's website, from user authentication & authorization to content theming and display, is already part of Drupal. Using existing code is far more cost-efficient than writing our own. Additionally, given the large developer community, the code in Drupal is far more secure and feature complete than we would be able to offer from our own development team within a reasonable budget and time frame.

There are rare cases where neither Drupal, nor any other existing software package, will fill the client's requirements. In these rare cases, we still write custom applications for our clients.

Will we use Drupal forever?

At this point in time, we feel that Drupal is the best CMS to invest our time and effort into; however, this may not always be the case. There are hundreds if not thousands of other CMS platforms available, and there could very well come a time when we feel that it is time to move away from Drupal to another platform.

For this to happen, another platform has to clearly surpass Drupal not only in features, but also in philosophy and community. This is the beauty of open source - the tools we use are what me make them.

We generally have at least one other CMS running on our development server in order to play with it and judge it's capabilities. Over time, we've found some promising software, but nothing yet that surpasses Drupal.

The bottom line

For most of the projects we build for our clients, basing our work on the Drupal platform allows us to offer our clients a better product at a better price than we are able to achieve using other platforms or writing custom applications. It saves us a lot of headaches and frustrations in the meantime, which leads to far more efficient use of a client's budget.

Apr 19 2009
Apr 19

This video/tutorial was initially started as a presentation for the Denver Open Media Conference this weekend. Since we had a snowstorm on the day of my session, I decided to do this as a screencast here instead. My description of the session and the screencast appear below:

The FlashVideo module provides a simple, yet powerful interface for your users to upload video files of various formats and have them convert and display in a Flash player of your choice. According to the D.O. usage stats, currently over 3,200 Drupal sites are using this module to create YouTube-style sites. In this session, I'll show how to install and configure FlashVideo to build a user-contributed video site.

Apr 19 2009
Apr 19

Earlier in the year I was asked by Packt Publishing if I would like to review some of their Drupal books on my blog, obviously I jumped at the offer and quickly e-mailed back a big fat "YES". A week or two ago a copy of "Drupal 6 Themes" by Ric Shreves landed on my door mat, since then I have been working my way through the book and compiling this review.

Drupal 6 Themes was published by Packt Publishing in September 2008, it was written by Ric Shreves who is a partner at the Drupal development company Water & Stone in Bali. Ric also wrote Drupal 5 themes for Packt Publishing, which I have not had the chance to read.

The book is split into nine chapters, which nicely lead the reader through the Drupal 6 theme development process. Chapter one (The Elements of a Drupal Theme) assumes you know what Drupal is, but starts form the basics in regards to theming. By exploring and discussing what a theme is, what a theme engine is, how to enable a theme, and what files make up a theme, Ric allows and the reader, no matter how advanced, to get a good overview of Drupal's theme system in a matter of pages.

Chapter two (Theme setup and configuration) follows on nicely from the last chapter, after the reader has learnt what a theme is and how it works, Ric then works through the process of downloading and installing the Zen theme. The theme configuration is then covered in a lot of detail, aspects such as the color module configuration, page elements, logo and shortcut icon settings. These are all covered from the perspective of a user or a site manager, and not from the perspective of a developer, who would be looking at how to incorporate these features in their theme. This chapter also covers other aspects of configuration that will effect the look of your site such as block and module management, blocks are looked at in slightly more details, covering the configuration of the access levels and visibility of the blocks.

Theme Engines where briefly covered in the first chapter, but Chapter three (Working with theme engines) greatly expands on this. Drupal's default, and most used theme engine, is PHPTemplate, which is where this chapter starts, and what most of the chapter covers. Ric covers the contents of a PHPTemplate theme in a lot of detail, with full code for each of the files within the Bluemarine theme. In a section headed "Alternative theme engines" covering just over two pages Ric discusses PHPTAL, Smarty and PHP XTemplate theme engines.

Now that the reader had a good idea of what a theme is, how to configure it, and run through of the code in an existing PHPTemplate based theme. Chapter 4 (Identifying templates, stylesheets, and themable functions) starts to look at code that the reader may want to use in their theme. The chapter works through most, if not all of the core modules listing all the stylesheets, themable functions and variables that could be used of overridden within your theme. This chapter is a great reference for new and existing theme developers.

Chapter 5 (Intercepts and overrides) starts by simply looking into how to override CSS attributes, but then expands upon the lists within Chapter 4 to explain how to override templates and themeable functions. It looks into what part the template.php file plays within a theme, how to add one and what to do with it. Template.php files can be very complex, but Ric managed to describe the how to do the overrides very well, but quite briefly.

Chapter 6 (Modifying an existing theme) is quite a long chapter but explains the process of making a sub theme from the Zen theme very well with all the code needed. For the more advanced Drupal developer, with little theming know how, this is where the book starts to get exciting, and by the end of the chapter you have your very own sub theme that you could submit back to the Drupal community.

Chapter 7 (Building a new theme) works in very much the same way as chapter 6, but without the Zen theme as a base, so there are few pages on planning your theme and setting up your files. All the code is given, but this can also be downloaded from Packt's web site. By half way through the chapter you will have your own PHPTemplate based theme, but the chapter carries on to look at a pure PHP theme, or one that doesn't use a template engine. Ric uses the Chameleon theme as an example and steps through the development process of a theme such as Chameleon.

Now that you have a Zen sub theme and a custom theme chapter 8 (dynamic theming) moves on to look at ideas such as admin themes, multiple page or section templates, dynamically theming page elements and working with template variables. This chapter is really great for the more advanced developer and expands on some of the ideas discussed earlier in the book. All of the techniques displayed within this chapter will allow the reader to make their theme change depending on the page being viewed, the user viewing it, what regions are being used and other dynamic variables.

Chapter 9 (Dealing with forms), the final chapter, is a very specific module looking into modifying the look of forms in many different Drupal-y ways. Starting by looking at how forms work in Drupal, the chapter moves on to look into modifying forms by using simple approaches such as CSS overrides, theme functions and custom modules.

The appendix includes a Drupal CSS Map, which maps out the CSS files for all core modules, all files for all core themes. Also included is a "Themer's Toolkit" section, looking into useful modules and firefox extensions.

In summary, Drupal 6 Themes by Ric Shreves is a great book for new Drupal theme developers, and the second half of the book provides a great resource for the more advanced developer too. My only complaint with the book is that it would be nice if a few of the screenshots where printed in colour, to give a clearer view.

Apr 19 2009
Apr 19
Share this

At the Open Media Camp in Denver yesterday, Kevin Reynen (kreynen) got things off to a great start with Overview of Metadata Standards for Video - Why doesn't it work like a Library? We discussed the difficulties of even agreeing on a standard set of genres for tagging video, from how to decide what genres to include in a taxonomy to the user interface in presenting those options to editors. (For instance, he said that his experience with the standards used at PEGMedia.org is that editors often use the Action genre by default, which is listed first in the listing, rather than scrolling through the hierarchy of available choices.)

Everything is Miscellaneous

I was reminded during this discussion of a book I read last summer, Everything is Miscellaneous: The Power of the New Digital Disorder, by David Weinberger. I mentioned the book, and got a few nods and a few shakes of the head. Seems quite a few people have looked at these issues from a lot of directions...

Kevin mentioned a meeting he facilitated with a group of librarians, whom he hoped would have a magic bullet for the question. After presenting the dillemma, he turned it to them, but got answers ranging from maintaining a simple list to "use the Library of Congress's classification".

I liked David Weinberger's approach in Everything is Miscellaneous. He discusses the inherent difficulties in classifying information, and the centuries-long struggles to achieve the perfect classification. This history has ranged from the revolutionary idea in the middle ages of ordering books alphabetically, to the Library of Congress's flexible classification, to the Encyclopedia Britannica's approach of using editors to decide what information is worthy enough to even classify, to Melvil Dewey's entrepreneurial and astoundingly successful attempt to force public libraries to adopt his Christian-biased taxonomy (which gives 9% of the entire taxonomy to Christianity, 0.1% to Islam, and a mere 0.01%, at the austere classification of 294.3, to represent Buddhist literature from over 2000 years of a large portion of the world's population).

Weinberger goes on to show how there are basically three orders of information. The first order is atoms, the physical world, and is the challenge faced by brick and mortar store fronts, such as Best Buy needing to determine what items to place at the front of the store, and to arrange things in such a way as to make it relatively easy to find that particular ink cartridge for your printer (but still be tempted to buy that worthless Microsoft software placed on the way back to the cash register).

The second order of information is likened to library card catalogs. This is also Drupal's basic core taxonomy, where you create and populate a vocabulary. This is the focal point of Kevin's discussion, where video librarians struggle to agree on a set of genres to offer their editors. This is merely the latest battle in an old political war, that sees its roots in medieval universities and has had no good resolution. Whomever can force their system of classification on the world can control the information, and that's a dangerous power, whether it's a mainstream newspaper deciding to highlight a slanted story on its front page while not even publishing an article that might be detrimental to one of its advertisers, or whether it's Blockbuster fooling the public into believing that all movies can be neatly classified into Action, Comedy, Drama, Family, Horror, and Foreign.

The third order of metadata is what the Internet has brought into being, exemplified by Drupal's folksonomy. This allows everyone to classify their own information, and compare that with others'. Free-tagging, whether it's a comma-separated list, or YouTube's foolhardy space-separated list (what's the point of a full taxonomy term for "the"?). This idea is also at the root of Amazon.com's recommended buys, and for the Google Summer of Code's
Making Drupal Smart: The Recommender Bundle

I've decided that I'll remain neutral in this particular battle for control of video genres. However, I also recognize the desperate need for a sensible and consistent system of storing file metadata. This morning, during the Media Sprint, one of our first orders of business will be to implement a Meta-Data Plan and Structure for Drupal's Media module. This will create a simple table of key/value pairs by fid, and allow implementing modules to decide how to fill those pairs. This will allow any meta data to be easily exposed, such as with Views or in an XSPF play list, and also allow them to be consistently presented to editors, so that any video, whether a local video from a cell phone, a flash video, or a stream from YouTube, can be tagged meaningfully, regardless of the final editorial decisions.

Apr 17 2009
Apr 17

We released today the first stable release of the comment_moderation module for Drupal. I was lucky to have another Drupal developer David Stosik to join the project. David implemented all the remaining functionality that I wanted for the first stable release.

The comment_moderation module provides you a custom view on your approval queue by allowing you to moderate comment by comment, moving from one to the next and giving the options to publish, edit, reply, delete or report to mollom as spam. It always returns to the next comment in the queue.

It takes away some of the pain of using the default approval queue. And in fact the comment_moderation view is also accessible from the approval queue if you do not want to use the comment_moderation block.

Future development is still open, but we are looking at the following wishlist:

  • more integrated mollom support
  • showing embedded (obfuscated) links from comment body
  • browse (re-moderate) published comments
  • batch moderation by IP address/hostname

If you are interested in certain functionality we are happy to receive feedback. And thank you David :-)

Apr 16 2009
Apr 16

Front End DrupalI managed to get my hands on a pre-release version of a new Drupal book that just came out this week. The book is Front End Drupal and it is written by Emma Jane Hogbin and Konstantin Kaefer. The book says on the cover, Designing, Theming, Scripting, and I'm excited to see another book that really gets into Drupal 6 theming. When we, at Lullabot, wrote Using Drupal and we had to draw the line at a basic intro to theming, I was looking for a book to carry that forward. Since I am lucky enough to have myself a copy and found some time to sit down and read it, I thought I'd share my thoughts for those that may be trying to decide whether to order it (short answer is "yes").

To properly orient this review, I should start off by saying that I know Drupal theming pretty well, so my take on things may be a bit different from someone who is totally new to theming. I've also taught a lot of folks though, on every part of the learning curve, so I can appreciate what it means to get some of this stuff to click for people. The book tells you at the start that you shouldn't be a total Drupal newbie. This book is about getting Drupal to look the way you want, but it expects you to bring some basic skills to the table. Now, that said, the first few chapters do take the time to get you oriented with Drupal; so if you are rusty, you get a refresher, and if you are cheeky and like to scoff at "prerequisites," you at least get a toe-hold of the basics before being whisked into the heart of it all. So, off we go.

As I started into it, the first thing that I noticed was that this really is not about "just" code. I was expecting to get dumped right into some hacking and instead, you are given some good groundwork first. While the first two chapters would be the stuff I'd normally skip, I'd advise reading them, especially if you are new to Drupal or dynamic web sites in general. If you are a know-it-all, then I suggest you at least skim the headings and make sure you actually know what you think you know. The first chapter covers a lot of the basics of WTH are you even doing when making a website. These are generally good things to think about and go through even if you aren't theming. Stuff like, what kind of content are you really going to need, how do things need to be listed, who will be using it and how? The chapter walks you through the questions and talks about them from a Drupal perspective. You really should think about your site before you dive in willy-nilly. After you get your head into the proper space about what you are building, chapter 2 covers tools. This covers the gamut from a CCK and Views refresher, to cron and using version control. Basically, it is packed with a really complete checklist and you'll save yourself time and frustration if you take some time to go through this chapter and get yourself comfy.

Chapter 3 is where you start to learn about Drupal themes themselves. After a bit about how to install and configure existing themes, you get to make your first theme. It walks you through multiple ways to get started; using a contributed theme, making a theme from scratch, upgrading a theme from Drupal 5 to Drupal 6, or even how to convert a theme from Wordpress or Joomla!. I was surprised to find some of this more "advanced" stuff like upgrading or converting so early in the book. I would have expected it to be in the appendix instead, especially since some of the things it refers to haven't really been covered yet, or are really not likely. Not many people start with theming by upgrading a theme from 5 to 6, but they definitely would want a handy reference for it later if they need it. On the other hand, I can see that covering how to move from another system would be a more comfortable way for some people to start off. One thing that would be nice for those sections is to provide more detailed references right there (e.g. a link to the Drupal.org theme upgrade or variables docs). That way folks can come back to that chapter later and use it as a more one-stop shop for that kind of work later.

Once you have the basics down, the next few chapters take you into the major building blocks of themes by looking at the overall page (and things like blocks, taxonomy, search, etc.), as well as getting into content (nodes, CCK and Views). This is the nitty-gritty of what all these template files are for and how to crack them open and get them doing what you want. Sprinkled in here is a section on getting images into your content. It doesn't really do the full pointy-clicky work, but it does point you off to the various techniques to look at, like Image vs Imagefield.

Related to content, but in a whole chapter of its own (rightly so), is a really nice guide to working with Drupal forms. Output is great, but what about those pesky input forms that are the workhorse of administering your site? Again, this chapter has solid code examples and explanations, along with more module discussion about things like WYSIWYG editors. From there the book goes on to cover other important things like users and profiles, with a bit about controlling various things in this realm with regards to things like permissions and spam. The admin interface chapter is very module heavy and looks largely to modules that can make your admin's life a little easier, with some theme tweaking thrown in for good measure. Definitely a very pointy-clicky chapter more than codey.

With all of the aspects of your site humming along nicely, the rest of book takes you into the wonderful world of JavaScript and the Drupal flavor, jQuery. These chapters leave the pointy-clicky behind entirely. Here you will plunge into an overview of JavaScript and then on into fun things you can do with jQuery, from hiding and showing elements on a page to playing with AJAX. It is an intense few chapters packed with lots of info. You can also grab sample code from the book website, http://frontenddrupal.com, to play around with to help get a feel for it.

Ok, so long review already, but there is definitely a lot of stuff in here. I expected a "theming" book and got more than I bargained for. At times some of the things that had more to do with modules and configuration would surprise me, but then again, the front end of a website is more than just the theme, it is all of the pieces that play a part in both look and feel. So, while I found it surprising, I don't think it is off-base and honestly for people who are new to Drupal this is a freaking gem. Don't think that this is only for newbs though, not at all. This is a serious book, made for grownups, and it expects you to be able to extrapolate from examples and make use of the references you've been given. To my mind that is the only way to really learn this stuff. The chapters give context, some conceptual framework, and points to the standard references, but then it dives straight in to real examples, and they aren't namby-pamby. Some examples are definitely doing some interesting stuff, but the great thing is that each part is explained step-by-step. This gives newbies some hand-holding while allowing more advanced folks to just get down to it and see what they can really do beyond the basics. Overall, a great book, jam-packed with lots of learning. Congrats to Emma and Konstantin for producing another great book in the Drupal library.

Apr 16 2009
Apr 16

Another large, well-known site has moved to Drupal. Optaros and IDG Communications issued the press release today, but the new InfoWorld site went live on the popular open source community platform last week. Congrats to the IDG and Optaros teams as well as the Drupal Community!

Apr 16 2009
Apr 16

Play Video

Movie link (right-click to download) Problem with this video? Contact me

Drupal is all about two things, content and management. Ok, so that was a cheesy one about Drupal being a CMS. But,the biggest advantage Drupal has, as I see it, over many other CMS's is both its flexibility and the number of contributions made to extend what it can do. Quite literly, there are new modules every week (RSS feed) which make Drupal do things you probably want it to do.

Herein lies the problem. Knowing what modules do, which ones to use and how to find them. If your goal is simply to allow other users to contribute content to your site with a degree of control over who can contribute, how they contribute and what the process is, then this video will get you started.

Using the Modr8 module [issues] - [usage], you can add moderation of content to your site. When allowing users to contribute, you can clean things up by using the Vertical Tabs module [issues] - [usage], which makes the node edit form much more clean. Finally, when it comes to allowing some users the ability to publish, without moderation, using the Override Node Options module [issues] - [usage], you can provide users with control over the node options of Published, Promoted or Sticky and allow for the Authored On and Authored By to be controlled per role.

As Drupal has proven time-and-time-again, there's very little you can't accomplish. All you need to do is either find the module or build it.

Apr 15 2009
Apr 15

Play Video

Movie link (right-click to download) Problem with this video? Contact me

One of the most time-consuming tasks for any new Drupal site is setting up and testing what users can and can't do. This is the realm of user permissions and role permissions. I'm guessing you've visited the checkbox maze - as I like to call it.

One of the most frustrating aspects of Drupal's Permissions screen is this; with any number of roles beyond a few, and with a large collection of modules, the task of permissions management becomes quite hazardous. The potential for "accidentally" checking one little box which gives the wrong role the wrong access and allows the wrong user to do the wrong things, it's no wonder managing Drupal permissions can become unnerving.

Enter my solution to this problem. A collection of modules which extend the level of control, make it easier to focus on the permissions that matter (relative to what you're setting up at the time), and remove the visual clutter from this extensive web page.

Here are the modules I cover in this video.

Here are some other modules, which I didn't review in the video, that deal with permissions. They seem to provide even more control over who can do what on your Drupal site.

If you've got other suggestions or ideas about making it easier to manage Drupal permissions then leave a comment below!

Apr 15 2009
Apr 15
Steve Purkiss's picture

Wednesday, 15th April 2009

We went over many topics at the Drupal 101 Workshop on Thursday April 9th 2009, I will be posting some notes here. For a more complete SEO-friendly setup for your site, download the SEO Checklist module http://drupal.org/project/seo_checklist and follow the instructions

Module requirements

NOTE: If you have downloaded the Acquia Drupal distribution from http://acquia.com/downloads then these are already included, otherwise:

  1. Token - http://drupal.org/project/token
  2. Pathauto - http://drupal.org/project/pathauto
  3. Path - included in the core Drupal distribution


NOTE: These are just how I set things up, obviously tailor to your individual needs/preferences!

  1. Enable the above modules in Site building->Modules (/admin/build/modules from your site root)
  2. Go to Site building->URL aliases->Automatic alias settings (/admin/build/path/pathauto from your site root)
  3. I set General settings->Maximum number of objects to alias in a bulk update to something representing the current number of nodes on your site or higher - the default is quite low so you can often forget this. I set it to 9999 but this could be trouble if done on a live site so you would need to do it in smaller batches in that particular use case
  4. I set Blog path settings->Pattern for blog page paths to 'blog/[user-raw]' rather than 'blogs/[user-raw]'
  5. Check the 'Bulk generate aliases for blogs that are not aliased' so that this new setting gets updated
  6. I set Node path settings->Default path pattern to '[title-raw]' rather than 'content/[title-raw]'
  7. I set Node path settings->Pattern for all Blog entry paths to 'blog/[author-name-raw]/[yyyy]/[mm]/[dd]/[title-raw]'
  8. Check the 'Bulk generate aliases for nodes that are not aliased' so that this new setting gets updated
  9. I set Taxonomy term path settings->Default path pattern to '[vocab-raw]/[catpath-raw]' rather than 'category/[vocab-raw]/[catpath-raw]'
  10. Check the 'Bulk generate aliases for terms that are not aliased' so that this new setting gets updated
  11. I set User-tracker path settings->Pattern for user account page paths to 'member/[user-raw]/track' rather than 'users/[user-raw]/track'
  12. Check the 'Bulk generate aliases for user-tracker paths that are not aliased' so that this new setting gets updated
  13. I set User path settings->Pattern for user account page paths to 'member/[user-raw]' rather than 'users/[user-raw]'
  14. Check the 'Bulk generate aliases for users that are not aliased' so that this new setting gets updated
  15. When you're ready, click Save configuration and watch the magic happen!
Apr 15 2009
Apr 15

One of my current Drupal projects (live local) has been giving me a headache lately, due to a small but very annoying problem. My PHP development tools of choice, at the moment, are Eclipse PDT and TextMate. Both of these generally work great for me. I prefer TextMate if I have the choice (better config options + much more usable), but I switch to Eclipse whenever I need a good debugger (or a bit of contextual help / autocomplete). However, they haven't been working well for me in this case. Every time I try to load in the source code for this one particular project, the IDE either hangs indefinitely (in Eclipse), or it slows down to a crawl (in TextMate). I've been tearing my hair out, trying to work out the cause of this problem, which has forced me to edit individual files for several weeks, and which has meant that I can't have a debugger or an IDE workspace for this project. Finally, I've nailed it: self-referencing symlinks are the culprit.

The project is a Drupal multisite setup, and like most multisite setups, it uses a bunch of symlinks in order for multiple subdomains to share a single codebase. For each subdomain, I create a symlink that points to the directory in which it resides; in effect, each symlink points to itself. When Apache comes along, it treats a symlink as the "directory" for a subdomain, and it follows it. By the time Drupal is invoked, we're in the root of the Drupal codebase shared by all the subdomains. Everything works great. All our favourite friends throw a party. Champagne bottles pop.

The bash command to create the symlinks is pretty simple — for each symlink, it looks something like this:

ln -s . subdomain

Unfortunately, a symlink like this does not play well with certain IDEs that try to walk your filesystem. When they hit such a symlink, they get stuck infinitely recursing (or at least, they keep recursing for a long time before they give up). The solution? Simple: delete such symlinks from your development environment. If this is what's been dragging your system down, then removing them will instantly cure all your woes. For each symlink, deleting it is as simple as:

rm subdomain

(Don't worry, deleting a symlink doesn't also delete the thing that it's pointing at).

It seems obvious, now that I've worked it out; but this annoying "slow-down" of Eclipse and TextMate had me stumped for quite a while until today. I've only recently switched to Mac, and I've only made the switch because I'm working at Digital Eskimo, which is an all-out Mac shop. I'm a Windows user most of the time (God help me), and Eclipse on Windows never gave me this problem. I use the new Vista symbolic links functionality, which actually works great for me (and which is possibly the only good reason to upgrade from XP to Vista). Eclipse on Windows apparently doesn't try to follow Vista symlinks. This is probably why it took me so long so figure it out (that, and Murphy's Law) — I already had the symlinks when I started the project on Windows, and Eclipse wasn't hanging on me then.

I originally thought that the cause of the problem was Git. Live local is the first project that I've managed with Git, and I know that Git has a lot of metadata, as well as compressed binary files for all the non-checked-out branches and tags of a repository. These seemed likely candidates for making Eclipse and TextMate crash, especially since neither of these tools have built-in support for Git. But I tried importing the project without any Git metadata, and it was still hanging forever. I also thought maybe it was some of the compressed JavaScript in the project that was to blame (e.g. jQuery, TinyMCE). Same story: removing the compressed JS files and importing the directory was still ridiculoualy slow.

IDEs should really be smart enough to detect self-referencing or cyclic symlinks, and to stop themselves from recursing infinitely over them. There is actually a bug filed for TextMate already, so maybe this will be fixed in future versions of TextMate. Couldn't find a similar bug report for Eclipse. Anyway, for now, you'll just have to be careful when using symlinks in your (Drupal or other) development environment. If you have symlinks, and if your IDE is crashing, then try taking out the symlinks, and see if all becomes merry again. Also, I'd love to hear if other IDEs handle this better (e.g. Komodo, PHPEdit), or if they crash just as dismally when faced with symlinks that point to themselves.

Apr 14 2009
Apr 14
{{#if useSimpleSecondCol}} {{#if useSecondColThin}} {{else}} {{/if}} {{#with secondColumn}} {{#if simpleList}} {{/if}} {{#if complexList}} {{/if}} {{/with}} {{else}} {{#with secondColumn}} {{/with}} {{#with thirdColumn}} {{#with content}}


{{#each images}} {{/each}} {{/with}} {{/with}} {{/if}} {{#with thirdColumn}} {{#if fullBanner}} {{#with content}}


{{{description}}} {{/with}} {{/if}} {{#if view}} {{{content}}} {{/if}} {{/with}} {{#if hasFourthColumn}} {{#with fourthColumn}}


{{{description}}} {{/with}} {{/if}} {{/if}} {{{description}}}
Apr 14 2009
Apr 14
Drupal surfboard

So what does everyone think of my new surfboard? It's a custom 6'3" made by Clayton (site under construction) in Durban, South Africa, my home break. I took it for a test drive last week and it is a sweet board indeed! Very reasonably priced too, especially after converting British pounds into South African rand.

I'm currently based in London, but I'm planning a few surf trips to Indonesia and Western Europe in the near future. Look out for photos of Druplicon inside some sick barrels. I hope.

Apr 13 2009
Apr 13

Content Overlay

I traditionally find content overlays extremely useful for simple content operations and modal dialogs. For instance I patched and advocated an issue that would promote the delete operation on a node to a Menu Local Task like Edit and View currently are. This is in line with my views on implementing actions as decorators on the objects they perform their work on.

The proper use of a content overlay in this situation would be as a confirmation dialog for the delete operation. This would save us a page load and still provide the users protection against unintentional data loss. Another valid use of this system is the on the fly creation of a taxonomy term for a node that is being created, terms are simple concepts and their creation as an interruption of the node creation process makes sense because it inhibits the nodes creation (which is after all the real purpose of a modal overlay).

A misuse of this content overlay system would be in the creating of a complex piece of content like a node. Take a quick look at most REAL sites and you'll see that the node edit form can get to be rather large and complicated. Trying to stuff all of this content into a content overlay will surely result in having to scroll (even with the new vertical tabs in d7). If you want to see a deer in headlights give a user a content overlay that requires scrolling to see the submit button or the rest of the form. You might be there for hours if you don't break the spell on the poor subject.

I see the problems you are attempting to solve by introducing content overlays for node creation as two fold: the first is that you perceive the creation of content as too disjunctive form the normal sites flow (i.e. you create it, where does it go/live, and where should you go when you're done). The second is that I think you perceive the task of content creation as overly arduous and complicated. Reducing it to a content overlay would certainly provide the push to fix this issue. Let me start by saying that i think both concerns are valid but that i think the solution is suboptimal and might introduce more problems than it solves.

I'm a fan of making easy things easy and hard things harder. Applying that to this scenario might lead to an additional "Settings" tab (aka Menu Local Task) to accompany View, Edit, and (Delete)[http://drupal.org/node/196758]. This section would contain all of the "default settings" we've defined in the content type administration section. It could include comment (disable, enable), workflow (published, unpublished, promoted), and authoring information. It would also provide a place for contrib modules that operate in this same fashion to override their settings. For example pathauto module could be set on the content type with a pattern and the path could be overridden on a particular node in the settings tab with the user never having to know what generated the default path, only that if they want to change it they can do it there. We could reuse the forms and most of the validation logic for such a setup because it is a perfect mirror of itself.

We should be able to assume that the "defaults" we set in content type administration decently fit the usage scenario of the content type in question and not have to provide places for this to be changed during the simple act of creation or editing the actual content. This further reinforces the value of separating these actions from the node form (aka "add/edit).


I traditionally favor decorating objects (nodes, comments, users, categories) with the actions that you can perform on them (view, edit, delete, categorize, etc). To that end using the header as a decorator on the whole site works very well as a natural relationship for me.

Where the header concept seems like a really good idea for items that don't usually belong to something but instead belong to the site. These tend to include "1 off items" like account, status, creating content, search and shortcuts to administrative sections (content type admin, site info, user admin, etc) and help.

Where this analogy fails is when it attempts to extend that relationship to specific items on the site or page in question. Using the header to create a distance between the item being operated on and the action being performed on it seems detrimental to the process of getting the user to understand the relationship dictated above. I would favor the approach of decorating the actual content itself with that operation along with the other you might wish to privilege the user to perform (track, delete, etc).

Furthermore, while I understand the reasons behind wanting to hide what could amount to a cluttered list of actions on each content item (e.g. node, block). The concept of an "activation edit" button, assumes a false dichotomy between the normal use of a page and the interaction with its content. Because so many diverse sites are created with drupal we cant always predict how the functionality we write might be deployed on a particular implementation.

As a simple example "Developer A" might deploy the five star rating system on the site of a movie reviewer and "Developer B" might deploy it on a Yelp or Netflix style site that solicits normal users for input. In the first case the voting action is clearly administrative and would occur while creating the content but in the second case the user would interact with the widget in a much more casual fashion. This is just the simple example I could come up with on the fly. I'm sure talented others could extend it across other modules and actions for you if you'd like.

Instead of implementing a page wide "edit mode" thats enforces this dichotomy perhaps a more content item specific hover effect similar to the way "Views2" embeds administrative function links above displayed views could be adopted. This would unclutter the base interface while providing context sensitive actions that the present user has privileges to perform. For the example above "User A" might be able to rate a movie or a business by clicking on the widget, and "Administrative user B" might be able to clink on a link to the itemized result list.

Inline Editing

I LOVE inline editing. It appeals to every inclination of every person ive ever watched use drupal. Editing content where it lives is a great and noble idea. Unfortunately a lot of the power of drupal also lies in a developers ability to hook into various stages of the contents rendering and modify it before it is output for display. Teasers and computed fields are wonderful examples of "content you cant edit" because it isn't content but is the aggregate of user input from multiple places mixed with the context of display. This makes it VERY difficult to "edit this content" in any meaningful way.

I could imagine using multiple callbacks to discover how the field is computed and provide the necessary forms and items for the user to manipulate the field but this might significantly hamper possibilities with out current infrastructure that are key to drupals value proposition (it would also greatly complicate the modules that had to implement them). We could disable such fields but then we introduce inconsistencies in the UI that mean less predictable interfaces for relatively little gain on the simple fields that do allow it. There are much better people to approach about the complexities and possibilities of edit in place as it isnt a new desire by any stretch of the imagination but i think it si a complicated one that might be better (or at least more easily) served by simply providing more contextual "edit actions" on content as it is displayed throughout the site.

Apr 13 2009
Apr 13

Drupal is modular. Drupal is more modular. Sometimes you feel Drupal is _too_ modular. Example: The recommended best practice for building a mainainable and generic image gallery uses at least seven Modules: CCK, Views, Filefield, Imageapi, Imagecache, Imagefield, A batch uploader like image fupload plus a template file and css for your theme. Uff. And now here you go and explain to a beginner that Drupal is easy.

Thing is: in the end it is quite a simple structure. Recently I came to my personal best practice: Using multiple values for an imagefield and the new image fupload for slick batch uploads. With the new feature in imagefield to add captions to images even when using multiple values and the ability to rearrange the order with the drag and drop widget there is not much to miss. With some Views and Taxonomy magic one should be able to build _Really_ large multiuser galleries, and if you want to seperate the images better you make single nodes of each - good news image fupload also supports this option. Sounds like a missing link, eh?

But this is not what this post is about.

Now how do I share this wonderfully flexible gallery with someone who came to Drupal only a month ago and is struggling with CCK let alone views without having to do it for him? This thought came to me and I asked people on IRC for a solution. I  found that just recently an entire bunch of modules saw the light of day that make up for this strength of drupal that can be a weakness.

Lotsa nifty solutions

There is context and spaces with features and also patterns Module that are able to save complex configurations of Modules and settings into something that can be transferred to other sites given the same modules are installed. I have not investigated in depth, so forgive mistakes about the exact way the modules do this. Context and spaces come up with a module in the end that you install and which then performs his magic. Patterns produces more of a portable code like you use for importing/exporting content types / views / panels.

Here's a presentation screencast for patterns. There is also an explanation available on drupal.org what exactly is the difference in approach between the two alternatives and how they complement each other. There is even an entire group on d.o. that is on deployment and packaging. Wow.

I am not sure if any of the modules solves the problem that this approach also needs styles to be added to style.css and you might need a template file - normally the system does not have write access to the themes directory so this might be tricky. Storing styles inside the database makes every purist shout bloody murder. But I am sure this problem will be solved.

All these approaches have in common that they differ heavily from installation profiles: installation profiles can only be performed on the first install of your site. These approaches can be used anytime to add features to an already existing site. So the use cases are different and can well complement each other.

Together with the new energy that is put into installation profiles this might take Drupal to another level: We can preach the holy purity of CCK/Views/writeyourmodulenamehere solutions and at the same time make them affordable for Non-Drupal-Ninjas. I am really excited about this and we will see what the enormous creativity of Drupal Developers brings to us next. The daily needs for better solutions brings on the power to solve problems that have been there for quite a while, so one can be very confident. Rock on!


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