There’s always been somewhat of a disconnect between designer-types and backend-types. And we’re not just talking about hairstyles, eyewear, and the contents of their bookshelves — designers and programmers approach problems in different ways, and their individual plans of attack don’t always jibe. Of course, you want your site to be sleek, fast, and bleeding-edge, but are you willing to compromise stability, scalability, and compatibility just so the users can ooh and aah at a few pretty pictures? Web design has always been a balancing act, and the ideologies of each camp often clash.
But Webmonkey’s here to say that it doesn’t have to be that way. It is possible to create a site that has a lightweight Flash frontend, a dreamy interface, and a scalable, secure, and dynamic backend.
Webmonkey Scott has found the balance between eye-catching design and backend database wizardry. Lucky for us, he’s agreed to share this knowledge in a two-day tutorial. He’s even put together a hands-on project that shows you how to build an easy-to-update blog using Flash. That’s right, a Flash-based blog — it sounds a little loony, but this blog pulls content from a MySQL database and feeds it into the dynamic Flash frontend using a few lines of PHP code.
In day one, Scott talks you through the construction of an open source MySQL database using both the phpMyAdmin tool and mysql on the command line. You’ll learn how to add blog entries to the database and then you’ll learn how to run queries in PHP. Topics such as basic database organization and the behavior of variables are also covered in this lesson.
Day two shows you how to design and build the blog’s Flash frontend. You’ll use common Flash ActionScript objects to pull the content from your MySQL database to the different areas of your blog’s user interface. You’ll also learn some common workarounds to keep all of your content flowing smoothly.
Whether you are designer or a programmer, it’s time to roll up those sleeves and get ready to see how the other half lives. Even if those of you who don’t feel a particular loyalty to either side of the fence will still discover that there’s plenty of hands-on knowledge to be gained.
We’re not promising that designers will sell their $500 pencil sharpeners, start marrying UNIX geeks, and honeymooning in Cancun before breeding programmer/designer children, but we will insist that they sit in a room alone together until they can build a useful website that everyone can agree on. Hey, stranger things have happened. Like Carrot Top.
Welcome to the third and final lesson for this tutorial. If you’ve gone through Lesson 1 and Lesson 2, you already know the essentials for installing and writing useful scripts with MySQL and PHP. We’re going to look at some useful PHP functions that should make your life a lot easier. First, let’s look at include files.
We all know the basics of includes, right? Contents of an external file are referenced and imported into the main file. It’s pretty easy:You call a file and it’s included. When we do this in PHP there are two functions we need to talk about:include() and require(). The difference between these two functions is subtle but important, so let’s take a closer look. The require() function works in a XSSI-like way; files are included as part of the original document as soon as that file is parsed, regardless of its location in the script. So if you decide to place a require() function inside a conditional loop, the external file will be included even if that part of the conditional loop is false.
Drizzle is a new project from Brian Aker, MySQL’s director of architecture, which aims to take MySQL and strip out the fat, leaving a faster InnoDB and UTF8-supporting database designed for today’s web apps.
Drizzle will get rid of query caches, stored procedures, permissions, views, and triggers; it will offer only simplified field types and it will be optimized for the small subset of features that are commonly used in web apps.
It isn’t intended to replace MySQL, but it could end up being, as Simon Willison suggests, MySQL’s Firefox.
Today’s web apps are generally written with frameworks like Ruby on Rails, Django and the like, all of which include things like sanitized database queries and more. So bother with prepared statements or other expensive (performance-wise) database server tools?
The project is still young and there’s no code to download yet, nor any hard and fast performance numbers, but it definitely looks like one to keep an eye on.
Dries Buytaert started down his path to fame when he coded up a private message board for his college dormitory. Nine years later, that modest bulletin board software package has grown into Drupal, one of the most popular open-source content publishing systems on the web with thousands of active contributors. In March 2008, Buytaert connected with entrepreneur Jay Batson, and together the two of them founded Acquia, a commercial venture that will provide technical support for Drupal’s devotees as well as further the adoption and development of the platform.
Webmonkey sat down with Dries and Jay to talk about the history of Drupal, where development is headed and the role their new company will play in the project’s future.
Photos: Jim Merithew/Wired
Webmonkey: Dries, can you give us Drupal’s back-story? The germ of the idea and how the platform grew into existence?
Dries Buytaert: It sort of happened by accident. I was a student at the University of Antwerp in Belgium around 1999. I was doing web development with CGI and server-side includes, but I wanted to learn more about technologies like PHP and MySQL. Also, at the same time, we had the need for an internal messaging system at our student dorm. So, I wrote a simple message board. Then when I graduated, I decided to move my internal message board onto the internet.
When I registered a domain for it, I wanted to register the name “Dorp,” which is Dutch for “small village.” But I mis-typed, and actually ended up registering the name Drop. Amazingly, Drop.org was still available, and since it’s an English word with multiple meanings, I decided to just go with it.
Our original user community died pretty quickly, but I continued working on it by adding things like RSS feeds and the ability for users to rate content. More and more people started coming to the site with ideas and suggestions, like ways to modify the algorithm that handles comment moderation. At a certain point, I was getting so many suggestions that I decided to just open up the source code. That was the Drupal 1.0 release, which came out in early 2001.
At the time of the release, I was fairly confident that I had a good system. I felt that it was competitive with the other open source technologies out there like PHP-Nuke. So, it felt like the right thing to do.
Webmonkey: One of the key pieces of Drupal’s design is its modularity — users install a core package, then add functionality by installing task-specific modules. Where did the idea for the modular design originate?
Buytaert: It was part of the initial design. I was sort of shocked that most of the other systems didn’t have a modular design — to me, with my background as a computer science student, that felt like a very natural thing to do. I was also involved in the Linux kernel back then, working on wireless network drivers. That’s also obviously a modular system, so I may have gotten some inspiration from there as well.
Jay Batson: Speaking as somebody who dealt with a lot of content management systems before meeting Dries, I can say that most of the other CMS’s out there didn’t come from people who were computer science grad-types. They were built by web designers or programmers who maybe were self-taught and had hacked together a system that sort of worked. They didn’t come from people with an underlying discipline of computer science. That ended up being a key distinction between Drupal and other systems.
Webmonkey: Drupal is especially popular with those who want to build a site around some sort of central social networking component. Is that because it gives such granular control over user management, or is it because Drupal became popular at the same time social networks were really taking off?
Buytaert: I think the first reason is definitely a big part of it. Drupal was a multi-user system from day one, but most of the other systems are behind Drupal as far as user management and access rights.
It’s a very social system by design. For example, the original Drop.org site was very much like Digg, where people could submit links and vote on each other’s submissions. Such user interaction was a key initial feature of Drupal. Over time, we’ve been moving away from these features. That voting system has since been taken out of the core, but it’s available in a module. Instead we’re evolving into a platform that can do more — the traditional web content management stuff as well as the social stuff.
Batson: They also got a good boost because Drupal 5 had as its tag line “Community Plumbing.” At that moment in time when community-based sites were becoming more important, here was this system marketing itself as being optimized for that.
Also at that time, there were a lot of people coming into the Drupal community and contributing code. So, a great deal of code was written in that area with the social features in mind. I know Dries was spending most of his time during that period managing those contributions — keeping the Drupal core slim, but making sure that the key features were there. And, at the same time, stressing the importance of modules.
Buytaert: One of the things I’ve always encouraged people to do was take Drupal in different directions. I think it’s a very powerful notion to get out of people’s way. So if they want to build a social networking site or a Flickr clone, I think it’s important that Drupal as a platform is capable of serving all these different needs. That’s what the modular design helps accomplish.
Webmonkey: Tell us about Acquia, the company you founded together.
Batson: Our goal is to become to Drupal what Red Hat and Canonical are to Linux. If you want a supported version of this open-source software, you come to us and pay a subscription. You get a distribution, a set of services for maintenance and updates plus access to our tech support center. So let’s say you’re running a large-scale media site and you’ve built all of your front-end infrastructure on Drupal. You need an answer about something, and you want the ability to pick up the phone and have an answer within an hour rather than send an e-mail and wait a day, or wait for the appropriate person to log in on IRC. On the other end of the spectrum is the small site that needs help with installing modules or managing updates. It’s a well-proven open-source business model.
The other role we can play at Acquia is supporting the Drupal development community. Drupal has wonderful organic growth. The community is roughly doubling every year. That’s impressive, but we’d like to see it grow by a factor of ten.
Webmonkey: How many developers are working on Drupal right now?
Buytaert: For Drupal 6, the last major release, we had around 900 people contribute to the core. As a reference, that’s the same number of people who contribute to the Linux kernel. There are over 2,000 contributed modules, and each of these modules has one or more maintainers. The Drupal.org website has between 250,000 and 300,000 registered users. These are not necessarily all developers, but those people are participating in the community in some way.
Webmonkey: Where is Drupal development going next?
Buytaert: We are working on Drupal 7 right now. We’ll have a better database abstraction layer, better support for WYSIWYG tools and usability improvements for admins that make it easier to configure Drupal.
We have a new core feature called Content Construction Kit, or CCK. This lets you define new types of content using a web interface. For example, if you have a bicycle website and you want your users to be able to share their favorite rides, you can create a new content type called “rides.” That content type might include a start location, an end location, a link to a Google map, some pictures of the route, text describing the ride. Once you have all of this data, you can choose to visualize the ride on a Google map, or display it all in a table or whatever you want. Many different views can be extracted from this big bag of user data, and it can all be accomplished using an easy web interface.
Our long-term vision for Drupal as an open-source project to fully democratize online publishing — to make it possible for everyone to create really powerful and interesting websites just by clicking around. Drupal lets you get a working prototype up and running in just a couple of hours without having to write any code. That’s very powerful.