Prepare your Drupal site to be Slashdotted, Dugg, and Farked

Slashdotted, Dugg, Farked. These are all terms that site operators, bloggers, and web developers are very familiar with. They imply having a site 'front paged' at a website that drives a LOT of traffic to your own site.

Over the past week one of the sites we host, ended up on the front page of Fark.com and Foobies.com at the same exact time. It added up to some very busy days for a site which is hosted in a shared environment (meaning that it has to share resources of a server with other sites) as well as some useful knowledge concerning:

  • what kind of load a Drupal powered site can handle when in a shared enviroment
  • how to optimize Drupal's capability to handle a large number of visitors

To begin, it need to be understood that overall optimization for site traffic is going to depend on a gazillion different factors. If you don't have a reliable server stack which is already optimimized this article will only do you so much good. Apache, MySQL, and PHP need to be running reliably, and well tuned.

Assuming you have a well tuned server, then how much traffic your Drupal powered site can handle will depend on:

The amount of resources it has available (cpu and memory particullarly)
If your site is on a fully dedicated server that has 4GB's of ram and 4 CPU's, it's obviously going to make a tremendous difference in what the site can handle, in comparison to a site which exists in a shared enviroment and only gets a fraction of those resources to use. This is common sense, of course. Eventually, if your server stack is fully optimized and your Drupal installation is fully optimized and your site still can't handle the load then mo' better hardmare is your only long term choice.

How many features are enabled on the site, and which ones

One of the rather fun aspects of watching the site receive so much traffic was having a chance to test real world cause and effect with a number of Drupal/site features. Some of them make a very big difference in how much work needs to be done to generate a page view, and thereby how many people the site and server can reliably and consistently handle.

10 February, 2007

Drupal Intranet - Controlling access by role, per node, per user

Recently we had the pleasure of developing a very cool intranet for a group associated with the United Nations. They desired an online space within which they can privately share articles, comments, and files with each other.

Our mission was to make a site that would:

  • Not let anonymous users view any content
  • Enable varying levels of viewing, adding, and editing rights across differing authenticated user roles - on a per page/node basis
  • Enable different/custom menu configurations based upon user role
  • Redirect users after a successful login attempt to a front page which is unique to user role

If you have never used Drupal before you may not know that the above functionality is not available out-of-the-box. However, with a little research we found some contributed modules which helped us to achieve a totally customizable intranet:

  • front page
  • login destination
  • menu per role
  • nodeaccess
8 February, 2007

Drupal themes

One of the greatest things about the Drupal CMS is that it can support *any* look and feel you want it to in a just click of a button. Or at least it can once you have the theme you want designed and "Drupalized".

Themes/designs are a very unique part of a web site, because they they simulataneously are "just" a wrapper for the content on your site - while at the same time being *the* main element which keeps your site from just being a bunch of text splattered on a page (screenshot of this page without an active theme).

So, the visual design of your site is one thing in itself, but it's only a beginning, and in a proper site construction a theme should start out literally as a 'pretty picture', mocked up in Photoshop for easy experimentation/changes.

What happens after this stage in theme development is an entirely different case altogether, because now we're moving from a 'pretty picture' to working code, which will affect browser compatibly (do Internet Explorer 7 users see your page as a blob?), download speed, and usability (does the link to the contact page not work for Firefox users?).

The coding stage is where expertise and testing become necessary in order to keep a your design from becoming a nightmare in terms of usability, compatibility, and flexibility.

So, a good theme is not coded to not just look like the pretty picture you started out for one browser, but to also:

  • look and behave correctly across a wide variety of web browsers - now and for the future
  • be flexible enough to provide future customization and extensibility. Having a theme that falls apart or cannot support at least minor revisions to the layout will be very limiting later on if you need to change things up.
  • be efficient and degradable. If your theme uses Javascript or Flash, it should be made to 'degrade' gracefully if a visitor does not have those features turned on in their web browser. In certain cases, consideration for "accessibility" issues of handicapped web visitors must/should be taken into consideration when coding your theme.

Design resources:
HigherVisibility Theme Library
Hundreds of high quality themes, for dozens of categories. Browse and brainstorm - themes available in raw format, or professionally Drupalized

Open Source Web Design
Browse Free Web Design Templates (non-Drupalized)

The Drupal Theme Developer's handbook is a good place to go for information on developing the code for your own theme.

30 January, 2007

Sacramento Drupal development

In addition to the U.S. and international markets which HigherVisibility serves, we also have a non-virtual home in the Sacramento area, which gives us and our clients more opportunities for the kind of personal face time that isn't always an option when communicating thousands of miles away.

So, if you're in the Sacramento area and are looking for world class web design, online community building, blogging tools, or intranet development - all done with the best open source tools available contact us.

30 January, 2007

Import raw content (nodes, users) into Drupal

Published in: 

(This article is made specifically for showing how to get raw content into Drupal, but the methods below can likely be adapted for other use cases [we also imported a list of users using these techniques for instance].)

Importing raw content into Drupal, can be, well let's just say it's not always easy. In two years of experience with Drupal we've imported a MoveableType site, a Blogspot site, content from one Drupal site to the other, and now raw data from a csv file (raw meaning that it did not come from some other CMS/website), and we've used everything from custom scripts, several different Drupal modules along the way including import-exportapi.module, userimport.module, nodeimport.module, WordPresstoDrupal.module.With the exception of the WordPresstoDrupal.module we've been mostly disappointed with the results of our experiments with the Drupal based import options. That said, this may not be the best method to start off with if you can find a ready-made solution that works for you, since it is somewhat time consuming.

Besides being a somewhat complex thing to begin with, the issues around importing content into a Drupal installation are exacerbated by the wide array of variables any point and click solution has to contend with. It's impossible for any module developer to be able to keep up with the number of different/custom Drupal content types for even one version of Drupal, let alone for all new versions of Drupal.

In short, for the serious site-operator/Drupal developer getting raw content imported to Drupal is always going to be a problem because one size is never going to fit all (the 'bad' side of such a customizable platform). This is important to understand in order to fully appreciate the workaround below, which is not particularly easy or fast, but is 99.9% reliable from a data integriy standpoint.

"How's that," you say? Well, because the following method does not actually "import" anything at all, at least not in the traditional sense that most people think of when adding new content into a database. With this method you'll create complete Drupal nodes with SQL, which you will then simply place it in your existing database. Nothing is automatically calculated, scripted, or extrapolated - which is exactly why this method is not easy or particularly fast, but also why it is precise:

In brief:
Create two separate sql import files. One for the "node" table of your database, and another for the "node_revisions" table. The last step will be to update the "sequences" table to let the system 'know' about the new content.

(these "node" and "node_revisions" tables are used only for certain module based content types not for cck nodes - though you could adapt these instructions to create new cck nodes by figuring out what tables you need to populate and using the techniques below)

What you need:

29 January, 2007

Convert Xtemplate to PHPTemplate

So you've got an Xtemplate that you need to convert to the PHPTemplate format because you've found out that the Xtemplate has become a third rate citizen at Drupal.org? (many modules don't support Xtemplate themes anymore, Drupal.org doesn't consider it a "supported" format, and "theming" Xtemplates is much harder than with PHPTemplates)

Well, no problem.

With a little work it is relatively easy to convert your Xtemplate into a much more compatible, supported, and extensible PHPTemplate. In fact, there's a very good handbook page at Drupal.org about this issue which I came across and have used to convert several of my own Xtemplates.

21 January, 2007


Subscribe to RSS - Drupal