Let's face it - anyone with anything more than a passing interest in the Drupal community is probably aware that we're in the midst of embracing Git, "the fast version control system". As with just about everything else in our community, we are continuously jettising outdated technology and replacing it with modern solutions.
Drupal 6: Ultimate Community Site Guide (2nd Edition) was published earlier this year by Sun Flare Ltd.. Dorien was kind enough to participate in an interview with DrupalEasy's Mike Anello. Dorien Herremans runs Sun Flare Ltd, an organisation that specializes in Drupal development and consulting. She is a MSc Commercial Engineer in Management Information Services from the University of Antwerp, Belgium. 1. Dorien, please tell us a little bit about your book. The Drupal 6: Ultimate Community Site Guide could be compared to a very long tutorial on how to set up a community site with Drupal 6. Or better yet, sequences of small tutorials, that are integrated. Some of the features that are implemented are profiles, photo galleries, video galleries, forum, walls, private messaging, etc. Throughout the entire book, the reader is guided by the example site drupalfun.com. The implementation of every feature is described in detail, along with example screenshots. In essence, this book takes you by the hand in setting up a full featured community website.
Creating a well-organized, content-heavy website is difficult. Creating one that is also sustainable is even trickier. It's easy to keep adding features to a web site without considering how they fit into the overall plan until you get to the point where things start getting out-of-hand and site maintenance starts becoming a real issue (blame Drush for making it so darn easy to add new modules!)
One of the primary ways of keeping a Drupal site of any size running securely and at peak performance is to ensure that all of its modules stay updated. With thousands of modules in the Drupal eco-system, updates are released literally every day. Luckily, Drupal core's Update Status module helps site administrators keep notified of modules in need of updating. In this article, you'll learn how to use the power of Drush and Apache Subversion (aka "svn"), a revision control tool, to update your site's module quickly and safely. You'll be presented with two methods for solving the problem. The second method is much faster, but comes with a caveat. Read on.
In an attempt to point to some of the great things that are available using Features, I tried to look for a directory of Feature Servers. Sadly, Google was not very helpful. After some digging, I was able to locate a page on the OpenAtrium Community site called Distributed Feature Servers. This points to many of the other pages I was able to find via search. Utilmately I created a wiki page on the Packaging & Deployment group of groups.drupal.org, which seems to be one of the hottest places to discuss Features. Directory of Public Features Servers wiki page Currently, there is tons of info about how to create your own Features Server, but not much about where all the publicly available features servers are located. If you know of others, please go edit the wiki page on groups.drupal.org or leave them in the comments here.
I recently presented a talk at DrupalCon Paris titled, "45 Modules in 45 Minutes: The Best Modules You're Not Using". I hand-picked 45 modules that were not among the top 100 most downloaded modules from Drupal.org for the period of June 21 - August 16, 2009.
This is your moment, you've decided to step up and make a job board for your local Drupal User Group. You spend some time thinking about everything you'll need, including the job listings themselves. You'll want to gather the standard info, like job title and job description, salary, experience, the works. When it comes to gathering company info, your instincts make you take a few extra moments to plan. If you think about this from the perspective of the person posting 6 or 7 jobs, she would end up having to type (or at least copy and paste) the business' contact information each time. If you think about collecting 3 or 4 fields for each business, then that's about 20 extra form fields for the user to fill out. If she then decides to change the info, let's say she made a typo, she now must click through each edit screen 6 or 7 times. That amounts to hundreds of clicks and several hundred repeated keystrokes. There must be a better way. A nodereference can help your users. Once finished, you will have two nodes, one for a job and another for a company, and yet you will still display the information about the company inside the job listing. By the end of this tutorial, you should understand what a nodereference is for, how to create and use one, and finally, how to use template files to theme the output of the nodereference and get the most out of the relationship.
This article is also available in French from KolossalDrupal. There's an incredible amount of functionality that can be provided by the Views module, especially when it is combined with intelligent use of Node Reference fields. When you relate your site's nodes with Node Reference fields, these relationships can be easily leveraged to create some very useful views. I'm going to build a view for a sample music site. In the site, I have 3 related content types for "Band" nodes ("Black Eyed Peas", "Linkin Park", etc...), "Album" nodes ("Back in Black", "Bat Out of Hell", etc...), and "Events" (concerts, television appearances, etc...)
In the first three parts of this series, we've looked at what RDF will do for you as both a consumer and a provider of RDF data and we've had a quick primer on what exactly implementing RDF entails. Turning our attention back to Drupal, this article will take a look at the state of RDF in Drupal 6 and some of the available contribued modules. Tomorrow's article will take a look at what the next version of Drupal will offer in terms of RDF. Drupal 6 does not have any RDF functionality in core. If you want to implement anything having to do with RDF in Drupal 6, you'll need to utilize contributed modules. Only a few of the RDF-related contribued modules for Drupal have even had official releases - the majority of them are still somewhere in the development process. While reviewing the existing RDF modules for Drupal 6, I found that I could categorize them into two categories - "Provider Modules" and "Consumer Modules". Those in the former category are designed primarily to help you RDF-ize your site's content. Modules in the "Consumer" category are generally designed to help you consume, use, and display RDF data from various sources. In some cases, there is some overlap, so this categorization is more for convenience than anything else.
If you've read the first couple of installments of this series, you should have a pretty good idea of what the "semantic web" is by now. By providing precise meaning to a site's content, applications can take advantage of these machine-readable hints to link data together across sites in a myraid of ways. Before you jump in the deep end of the semantic web pool, there's a few more things you should have a clear understanding of. As I previously defined, RDF stands for Resource Description Framework. This is a family of standards for describing content on the web. The vast majority of current and future Drupal implementations of RDF are actually RDFa ( Resource Description Framework in Attributes), a set of extensions to XHTML. RDF is normally implemented using XML; while this is possible with Drupal, RDFa allows Drupal to implement RDF as part of the standard content displays.
Even if you're not ready to implement RDF into your Drupal site, there's still a number of reasons why you should be excited about the Semantic Web. The fact that data will be linked from web site to web site (regardless of the underlying technology running the site) will lead to powerful Semantic Web applications - most of which haven't even been imagined yet. First and foremost, search will be revolutionized. Imagine being able to search for a specific person - not just the person's name. This is a subtle but important distinction. Currently, when you type "Dave Matthews" into your favorite search engine, the results you see are based on the words "Dave" and "Matthews". You'll see results about Dave Matthews, about people with the name "Dave" and/or "Matthews", about the orgin of the words "Dave" and "Matthews", etc... The search engine doesn't know that you're looking for a specific person with the name "Dave Matthews". With the Semantic Web, you'll be able to specify, "find me the person with the name 'Dave Matthews'". You'll even be able to perform "deeper" searches by specifying things like "find me all events having to do with Drupal taking place between now and July". Other than search, the Semantic Web will also provide you with the ability to do stuff with this data. For example, let's say you perform the Drupal events search from the previous paragraph and you're looking at the results. Because the data returned will have meta-data attached to it, future software tools will allow you to click on a returned event, and see if you're available on that date and time. If so, another click will seamlessly add it to your calendar. If you're familiar with Mac OS X, it's like data detectors on steriods. Really good steriods.
RDF. Semantic Web. Giant Global Graph. Food for Robots. By now you've probably heard all of these phrases, but relatively few of us have actually done anything with them. For example, I try to follow all the RDF modules on Drupal.org, read all the blog posts regarding Drupal and RDF but I've yet to implement anything having to do with RDF on any of the sites I develop or maintain. Why is this? Am I behind the curve? The answer is two-fold. First, I have yet to have any clients specifically ask for RDF functionality in their web sites. Secondly, I hadn't been convinced that recommending that my clients spend the time and money to implement an RDF solution is a sensible move for them. The reason I decided to research and write this series of articles is to figure out if and why I should recommend implementing RDF functionality to my clients. Prior to performing the research for this series, my knowledge of RDF was limited to water-cooler-conversation type knowledge. Big on bulletpoints, small on details. I was aware that RDF will, in the future, be used by search engines to provide better search results. I was also aware that by "tagging" web site content with RDF would enable a "richer" experience. The one example I would relay to people was a vCard-powered business card embedded on a web page using microformats that allowed the user's computer to do something with the contact information. Amusingly, it turned out that my one RDF example didn't even involve RDF, and that the vCard format was actually called hCard when used as a microformat. I had a lot to learn.
At the most recent Florida Drupal User's Group meetup, I gave a quick rundown of some of the new stuff that has made it into Drupal 7 core. It was by no means an in-depth look, it was mainly designed to give people a quick update on what they have to look forward to in the next version of Drupal.
It could have been an April Fools joke. On April 1st we got the call. "We have mockups for the design of the site, and we need the theme done in 2 weeks. After that we can discuss the XML import part of the project. We need to go live at the beginning of May." We knew it would be a challenge, but we made it happen - on May 7th the site went live.
This article is also available in French from KolossalDrupal.com. I need to speak to the Jedi Council. The situation has become much more complicated. This is pretty much what I thought to myself a few weeks ago when a project I was working on presented me with an interesting problem. I had just finished importing data from an external source into Drupal when I learned that in addition to the brand-new 3,000+ nodes, we somehow also had to take into account several thousand more "aliases" for each node. Keep in mind that I'm not talking about "aliases" in the normal Drupal sense... In this case, each imported node had the possibility of having multiple titles and each title needed to be available in various Views and discoverable via Drupal's core search mechanism. It was a requirement that we didn't just duplicate node content and give each duplicate a new title. We needed "phantom" nodes.