This blog post was originally posted to my blog at Mediacurrent. It appeared on Drupal Planet.
I got involved with Drupal in 2007 when I decided I wanted to build an online community of young people interested in politics in order to encourage their interest and activism. I was in way over my head; I had dabbled with a number of desktop programming languages, but I had never built a website. I got my first hosting account on my dad's recommendation, and it came with an installer for a large number of open-source software in a variety of categories. I researched each one, and it ultimately came down to Drupal or Joomla! as the only options that could potentially fulfill my vision of vibrant forums, in-depth blogs, stunning image galleries, relevant news, timely events, thorough user profiles, and close-knit groups. I ended up choosing Drupal 5 mainly because, as someone who had no idea what a CMS was, Drupal.org actually explained what Drupal was supposed to do for me. I was also put off by the number of paid add-ons for Joomla!, as my budget was zero.
UPDATE: I gave an updated version of this presentation to the Atlanta Drupal User Group. You can get the newer slides here.
I gave a presentation on Social Networking at DrupalCamp South Carolina on June 13th, 2010 (hosted by the SouthEast LinuxFest). Here are the slides I presented (complete with my notes on them) in various formats, as well as a link to the demo site (feel free to play around) and the downloadable Feature I exported based on the demo site.
In my humble opinion, the most crippling problem with building complex social websites in Drupal is the frustrating inability of most modules to work together nicely with user relationship modules, as well as the near total lack of support for any kind of individual, user-controlled privacy settings. I'm not exempting my own modules from this: my Facebook-style Statuses module has an architecture that inconveniently prevents it from working as well with user relationship modules as I would like.
The problem was, that new copy of the form was generated on the callback page, and it had no way of knowing from what page it had been called. In other words, if the script generating the form wanted to know what the current page was, instead of getting the URL of the page on which the form originally appeared, it would get the URL of the callback page. This became a problem when dealing with links, because links often include a "destination" parameter so that when a user takes an action after clicking the link they will be returned to the appropriate place. For example, an "edit" link for a message would typically have a "destination" parameter in the URL so that when a user saved the edits, the browser would automatically send the user back to the page on which the edit link was clicked. In HTML, such a link would look like this:
Quotes are no fun if they're not shared with others, so here's a few of my favorites.
I recently did some work for a client that involved multi-page forms. Specifically, the client wanted a page where users could choose one of five forms, each of which had about ten steps with one question each. Users had to be able to move forward and backwards through the forms, with their data saved when they finished.
I knew a lot about working with forms in Drupal, although I'd never actually worked that extensively with multi-paged forms. But I did my research, and luckily there are some nice tutorials out there. However, most of these were specifically for forms with only two pages, or covered older versions of Drupal, or were crazy complicated. There is a great tutorial at pingVision which I unfortunately found after the fact, but this also doesn't cover a "back" button.
So, here's an example of what I came up with. It's a little clumsy, and there's probably room for simplification, but it works. You can move back and forward in the form and all of your data stays inputted without getting mysteriously wiped away.
I use this trick all the time, practically every day in fact when I'm building a website. When you need to test a PHP snippet or you want to find out how something responds -- you want to see the structure that taxonomy_get_tree() returns, for example, or you forgot what the structure of the data returned from a multi-select form element is -- you can use this shortcut instead of going through the whole tedious process of writing a module or running the risk of blowing up your site by saving the PHP in a node.
Rupert Murdoch has announced that News Corp will start completely blocking Google from its websites. Or something like that -- it's kind of hard to understand what he means, probably because he doesn't understand what he means. This is a man that doesn't get the internet, and he wants to impose an old-school financial model on it. My favorite tech blog, Mashable, had this insightful comment: