Chris Parsons

Five Things I Wish I Knew When I Started Using Drupal

Chris — Sun, 24 Jan 2010 16:45:53 +0000

I noticed the other day that my account on Drupal.org is coming up to its three year anniversary, which means I've probably been working with Drupal for four years now. So I took a look back at some of the old Drupal sites I had put together, and like most developers, almost cringed at what I had done to some of those sites. So, with nearly four years under my belt, these are five things I wish I had been doing in 2005, when I started.

Everything Goes in the Sites Folder.... Everything

Those /modules and /themes folder in the root directory are so tempting. They're clear as day, and it makes perfect sense to just put the modules and themes in those folders. That's what they're there for, right? Wait, you're telling me that instead of using those perfectly good folders, I'm supposed to make a /themes and a /modules folder inside /sites/all, or /sites/default, or /sites/example.com?

However, when you have to do a site backup, it's way easier to zip up the sites folder, and just grab a new version of Drupal, than it is to zip the entire site. In addition, when you put modules and themes within /sites/default or /sites/example.com, you're now able to limit the module to just those sites.

Use a Base Theme, and Subtheme it

As with people using Reset CSS stylesheets for static HTML websites to standardize their development, using a base theme or a theme engine and subthemimg from there is a great way to streamline development of Drupal themes. In addition to having the standardization between browsers already built in, many have additional features, such as wireframing abilities, reseting the theme registry automatically in order to solve a lot of the caching problems that occur when trying to develop themes, as well as customizing the appearance of breadcrumbs.

I typically use the Zen theme to do 95% of my theme development. The only time the theme does not work well is when you have two sidebars on the same side of the content (think Smashing Magazine). Otherwise, it makes development way simpler, and since I use it every time, my theming times are getting faster and faster. If Zen isn't made for you, then perhaps look at the Blueprint theme, or possibly the 960 Theme.

Create a Custom Module for Each Site

As you start to get comfortable in Drupal, you'll start to want to tweak little form elements, or perhaps change how a function works. Don't be tempted to hack core, you're only going to cause yourself headaches if you do it. The proper way is to use the hooks system, and override the function.

One of the tricks I've learned after watching and learning from others is that it can be extremely useful to make a site-specific module to dump all of these random FormAPI and other hooks that a site needs, but no other site will ever need. I typically have one module called exampledotcom, with it being the name of the site instead, which contains all of these functions. I drop this in /sites/example.com/modules/custom and now not only do I have complete control of if I want the changes on or off, it's contained within the site module, so backups and upgrading are still a cinch.

Choose Your Contrib Modules Carefully

With 4970 modules currently listed on Drupal.org, knowing which ones to use can be a chore. You typically have two things to worry about when selecting a module. First, you have to make sure that you're choosing the best module for what you need to do, as there's likely multiple versions of the module feature you need. Then, you also have to make sure that it's a living module – you don't want to get a module that won't be maintained in six months, leaving you stuck in your current system.

Luckily, this is where having an awesome community helps out tremendously. If you're not sure which module to use between a couple seemingly valid choices, ask! The Drupal.org Forum has a large amount of users, with a wide range of skill sets and experience levels, and is a great place to go to ask "Should I use X or Y" type questions. In addition, there are other great help sites, such as Vark or even Twitter that are great sources for assistance. When in doubt, if you're having problems deciding on two modules, check the last commit date on each module; chances are the more recent last commit is the one to select.

Learn Just Enough Command Line to Use Drush

One of the major complains with Drupal is upgrading is a pain in the neck (and I need to write an article about how people are being drama queens about it). Drush is absolutely the answer - not just for upgrading, but simply maintaining your drupal site.

Yes, it's command line. Yes, it's not going to kill you. If you've chosen Drupal, you've already pretty much decided on power and flexibility over ease-of-use, and Drush is not complicated. In fact, upgrading is as simple as typing in "drush up". There are dozens of commands, and there are cheat sheets if you're starting, but if your host provides you with shell access, then this is a no brainer, and if your host does not provide you shell access, I would start looking around for shared hosting that offers limited shell access, as that's all you should need.

Anything I missed? Let me know in the comments!

Getting Back to Writing

Chris — Sat, 23 Jan 2010 15:13:58 +0000

Normally, a letter like this would be addressed to existing readership, but considering the number of articles and how long it's been - mom, I'll be writing again!

I really need to keep up this writing, and I'll likely be focusing towards more Drupal articles for a couple of reasons: that's all I really work in as of late, and I think there's a gap between the basic "How to use Drupal" and the advanced "This is how you rewrite a view to take a CSV file from the US Census Bureau and have it updated periodically with Cron." If you see the Drupal Forums, you can see there are a lot of these kinds of questions that need answering.

Anyways, hopefully I'll do a bit better at this than last time. Cheers!

If You Have FAQs, You're Doing Something Wrong

Chris — Thu, 20 Nov 2008 20:03:15 +0000

Frequently Asked Questions, or FAQs, as they're affectionately known, are a staple on the majority of informational and e-commerce websites. You can find them on a wide range of super popular sites, from Newegg to Digg, from Myspace to ABC.

Unfortunately, they're a cop out.

FAQs are a quick way to address an issue, but like the trivia section on Wikipedia, there's likely a better place to put it. Let's take Digg as an example and see how this can be improved.

Two Digg Examples: Taking Advantage of FAQs for Your Users' Benefit

Taking a look through Digg's FAQs, we stumble across this one:

I am getting a bad IP address warning when I try to login. What can I do?

Admittedly, I don't know how to trigger a bad IP address warning, and I really don't plan on trying. But this illustrates my point; the only people that need to understand this are the people that are receiving said warning. Therefore, it would only make sense to make sure this message shows up when a user receives such an error. If it's covered in that way, then it's one less thing you need in the FAQs (that shouldn't be there to begin with).

Let's tackle a FAQ question that's more suited to all users, rather than a specific subset. Surely this is reasonable to have in a FAQ, right?

How do I change my Digg homepage to a different topic?

I'm sure there are plenty of people that would love to set the Digg homepage to just be technology that aren't aware of this. A simple solution would be a little notification at the top of the subsection to let them know they can set the current section as their homepage. This is a win-win for both parties. Digg can use the information as additional trending to help improve their algorithm, and users now have quicker access to the information they want, and don't have to skim through information that may not interest them (such as celebrity news).

Don't Throw the Baby Out with the Bathwater

Of course, this doesn't mean you shouldn't have a help section. Help sections are a wonderful thing. They differ from simple FAQs in the fact that they're typically organized into categories, and dedicate a larger body of text, sometimes even an entire page, for each question. The better your help section is, the less human capital (I.E., your time) you have to spend answering questions.

You should treat your FAQs like a to-do list, however. Seriously, try it out. Go through each question, and see which of two categories it fits into: things that can be solved by improving the UI on your website, or things that can be best served by a more detailed section in a help area. Everyone will benefit from it. Your users will have an easier time navigating and using your site, and you'll spend less time dealing with e-mail questions, and more time with working on the cool things in life.

A More Useful 404 - PHP Edition

Chris — Tue, 18 Nov 2008 19:22:57 +0000

In its most recent issue as of this posting (Issue #272), A List Apart released an article entitled A More Useful 404. This article laid forth a method of how to write a 404 page that's useful to both web administrators and users alike - one that will e-mail the admin an error e-mail letting them know what kind of 404 error there was, and a custom error message for the user that can help point them in the right direction, or at least let them know about the problem.

My only problem with the article (and it's not really a problem, so calm down old Perl guy in the back) is that all of the code that was presented was done in perl. So I took it upon myself to rewrite the code in PHP. The code is below, and in downloadable form as well. The only variables you should have to change are the e-mail addresses at the top for who it should be mailed to - everything else should be fine.

The way I implemented it - there are no messages that are directly outputted - just a variable is set as to what kind of error you have with the 404. This way, they can be implemented in a template, or in my general use, outputted for formatting in a Smarty template.

To implement this as a 404 error document, in apache, use the first block of code in an .htaccess file. (obviously, change the URL if you're saving it in a different place) The rest of the code goes in your 404 page.

.htaccess

ErrorDocument 404 /errorpages/404-error.php

404-error.php Download this file

## E-Mail Variables

$from = "From: info@chris-parsons.com";
$to = "info@chris-parsons.com";

## Search Engines

$search_engines[] = "google.com";
$search_engines[] = "live.com";
$search_engines[] = "msn.com";
$search_engines[] = "aol.com";
$search_engines[] = "yahoo.com";
$search_engines[] = "cuil.com";
$search_engines[] = "viewzi.com";
$search_engines[] = "searchme.com";
$search_engines[] = "ask.com";
$search_engines[] = "baidu.com";
$search_engines[] = "altavista.com";
$search_engines[] = "excite.com";

## Code to check for source of bad link
## $error = "user" means that it's a bad bookmark or a typo by the user
## $error = "internal" means you have a bad link on your site
## $error = "engine" means that there's a bad link coming from a search engine
## $error = "external" means it's a bad link from another website

## Checks to see if they came from a bookmark or from typing in the URL
if ($_SERVER['HTTP_REFERER'] == '') {
$error = "user";
}
## Checks to see if it was an internal link from the same website
else if (strpos($_SERVER['HTTP_REFERER'],$_SERVER['SERVER_NAME'])) {
$error = "internal";
$subject = "Broken Internal Link on " . $_SERVER['SERVER_NAME'];
$message = "There's a broken link on the page " . $_SERVER['HTTP_REFERER'] . ".\n";
$message .= "The link ends up going to " . $_SERVER['REQUEST_URI'] . ".";
}
else {
## This checks to see if it came from a search engine in the list
## In the future, this could be expanded to strip the keywords from the
## query to determine the search made
## Use apache and redirect this link with a 301 to fix the problem correctly
foreach ($search_engines AS $engine) {
if (strpos($_SERVER['HTTP_REFERER'],$engine)) {
$error = "engine";
$subject = "Broken Search Engine Link on " . $_SERVER['SERVER_NAME'];
$message = "There's a broken link from " . $engine . ".\n";
$message .= "The link they came from is " . $_SERVER['HTTP_REFERER'] . ".\n";
$message .= "The link ends up going to " . $_SERVER['REQUEST_URI'] . ".";
break;
}
}
## If all of the above have failed, then it's a link from another website
if (!$error) {
$error = "external";
$subject = "Broken External Link on " . $_SERVER['SERVER_NAME'];
$message = "There's a broken link on the page " . $_SERVER['HTTP_REFERER'] . ".\n";
$message .= "The link ends up going to " . $_SERVER['REQUEST_URI'] . ".";
}
}

if ($subject) {
mail($to, $subject, $message, $from);
}

For an example, try clicking on the link to http://www.turnedleafstudios.com/missing-page.php and then try copying it into your address bar to see the difference.

If you run into any issues, please drop me a line via the contact form - I'll be glad to look over any problems.

Using Your Portfolio to its Fullest

Chris — Sun, 14 Sep 2008 00:30:35 +0000

As your freelancing and studio work progresses, you eventually will have a body of work that you'll be able to pull from in order to woo potential new clients. There is a tendency for all of us to show our entire body of work. This gives the impression of more experience and a wider variety of work, so that potential clients from all areas will be more likely to choose you. However, is that what you really want?

I'd be willing to argue that it'd be much easier to get the same work by focusing within a certain area, as opposed to trying a little bit of everything. Not only does it make your job easier (albeit a bit more monotonous), but being a specialist, you'll be able to ask for more money in many situations. Of course, if you specialize in something you enjoy, then it's an added benefit.

Organizing the contents of your portfolio

If you have a large body to work from, then it only makes sense to include the kind of work that you'd like to be continuing on. For example, if you enjoy theming blogs, then it would only make sense that you want to keep the majority of your portfolio as blogs that you've done in the past. Likewise, if you prefer to work in flash, then it only makes sense to highlight your flash projects.

What if you're looking to get more experience in a certain area, but don't have that much in your portfolio to show? There are two things you can do to improve. The first thing is to mock up pretend projects. This will give you the chance to improve at that area on your own time, as well as be able to show projects that you have complete control over, and don't have to bend to the design desires of the clients. The problem with this, of course, is time. For those that are busy, this isn't exactly a feasible option – time is money.

The second option is to create a category within your portfolio of the area you're looking to expand. If you have very little work in that category, you might want to broaden the category slightly to “fill it out”, but even just including the category will help you with communicating to the client (and to the search engines, if you stayed away from flash) that you're interested in that area, and have past experience with it.

Designing the Portfolio Itself

The thing that most designers neglect to consider when trying to attract new clients is the portfolio itself. Many consider the portfolio their chance to show their true colors – while this is true, this is not the best use of your portfolio. The way you design your portfolio will influence what kind of clients you will receive.

For example, if you have an entirely flash-based portfolio, I would venture to say that you're more likely to pull in clients that are looking for flash work rather than programming work, or even basic brochure website work. Alternatively, if you have a portfolio with a lot of typography and a powerful, effective layout, you're more likely to pull in high-end design work.

What does this mean? Design for who you want to attract. Your portfolio is your advertising. The message is important, but the medium of which it's transported is just as vital, if not more important.