From Design to Live: 15 Must-Do Steps after Installing Drupal
I’ve used Drupal for a lot of different sites, each using different layouts and different features. Some sites needed multi-user blogs while others were being built for ecommerce. Portfolio sites, business directory sites, social networking sites, personal blog sites. Some with light colors, some with dark colors… one, two or three columns, videos playing and splash pages. All very different sites.
Despite the differences, I have developed a routine of steps that I always follow no matter what the site is that I am setting up. There are certain modules that I always use and configuration options I always set, no matter what kind of site I am building or what types of features the client is asking for. This article is about those steps.
15 Must-Do Steps after Installing Drupal
I am not going to walk you through how to install Drupal or the best contributed modules to use for your specific type of site. Rather, I am assuming that you have already:
- Established a plan regarding the types of features that you require
- Researched the modules that you will need to download or build to get the required features
- Decided on or built your theme
- Successfully installed the latest version of Drupal (or the latest version that you can use while still supporting the needed modules).
So, if you’re looking at a nice, fresh installation of Drupal on your server but aren’t really sure what to do next, this article is for you.
1. Bump up your server memory limit
If you check your site’s status report, you will see what your PHP memory limit is set to. More than likely this is set to 64M. This is the amount of memory that your server allocates to running the PHP scripts that power your site.
64M would be enough to handle a basic Drupal site with a fairly basic set up. If you plan on using much more than just the basics, though, you’ll need to bump this up. The best way to increase this is to use a php.ini file. You can find out from your hosting company how to go about either adding or editing a php.ini file. Some already have them set up but require you to download them to make your edits, while others allow you to simply create one and upload it to your server.
Either way, get into your php.ini file and find the lines for Memory Resource Limits.
If you plan on having any sort of pictures / thumbnail support, you will want a minimum of 96M since resizing just one image to a thumbnail will take upwards of 46M. And how horrible would is be to run out of memory simply because a thumbnail needed to be generated? I usually set my sites to 128M just to be on the safe side.
To date, I’ve only come across one hosting company that refused to allow me to raise the PHP memory limit for a client; I advised my client to leave that hosting company. If you contact your hosting company and they refuse to let you raise this limit then I advise you to do the same.
2. Enable and disable core modules
There are a number of Core Modules that will come installed and enabled with your new Drupal Installation. There are actually two sets of Core modules – Required and Optional. If you’re using anything older than Drupal 7, your admin section for modules (Administer > Site Building > Modules) will show both sets. Drupal 7 will only display the optional modules within this section.
Most of these Core modules are useful, but that doesn’t mean you necessarily want them all. Read through the description of each of the Core Optional modules and make sure you have enabled only those that need to be enabled. For example, the Color Module is one that, while useful, is not necessary if you’re using a custom theme.
You’ll also want to go through this list and enable the Core modules that you will need. Modules such as the Blog or Forum modules will be on a site-by-site basis, but I do highly recommend making sure that Toolbar and Path are enabled along with the Field, File, and Taxonomy modules no matter what kind of site you’re building.
3. Rock your theme
Whether you’re developing your own custom theme, buying a theme from any of several resources or using one of the free themes that are available from drupal.org, enabling your chosen theme and setting it to be the default is something that should be done early in the process.
The primary reason I get the theme set up and running so early is so that as I begin adding in new sections or modules, if I need to make edits to the theme it is easier to find those problem areas and make the changes quickly.
I usually see this when using one of the free themes that are available: although the themes may be great, once I install a particular module that enables a new content type I notice that the content type doesn’t look right within the theme. Adding a new custom.css with style settings for that content type is easy to do and fixes the problem right there on the spot.
4. Set up your URLs
Right now, that’s probably what your URLs look like. They are very ugly, hard to read, and even harder to remember.
The Path module that you enabled earlier will allow you to enable clean URLs. This is not a requirement by any means – your site will work regardless of how clean or dirty your URLs are. However, clean URLs are easier for both humans and search engines to read and remember.
Once you’ve enabled clean URLs, your URLs will go from that to this:
Okay, so it’s still not extremely pretty, but it is getting there. Another thing that the Path module allows you to do is enter a custom alias that will be displayed instead of that ambiguous
So the URL in this example would end up being
http://www.yoursite.com/ten-most-important-steps. So much easier to remember than node/4, right? There are still a couple of other steps that we need to take before we can take full advantage of this power to alias our URLs, but this is a very important step.
5. Fine tuning your SEO
While I may not be an SEO expert, I do know a good amount about the basics of SEO. That gives my clients a good head start so that when they hire an SEO expert, I’m not stuck rebuilding, renaming or reconfiguring much of anything. I so dislike “re-“ing things.
Setting up your file names, URLs and overall theme design to be search engine friendly is a great start, but setting up keywords, descriptions and other meta tags will also be important to your client.
Now, let’s be honest, adding meta tags is not going to guarantee that your client makes the front page of Google. Heck – chances are your client won’t be in the first four pages of Google unless he or she is using a very unique combination of keywords and hires an actual SEO expert instead of relying on a site designer to handle the online marketing of his or her site.
That being said, there are a couple of really good modules that will help with setting up SEO basics such as the meta tags and keywords. And, just as with using the Pathauto module to set up your patterns for the URL aliases, the earlier in the process that you get these items set up, the better.
In Drupal 6, the go-to module for adding in meta tags was Nodewords; however, in Drupal 7 the new module is Metatags. Unfortunately, at this moment Metatags isn’t completely ready for production use; it is still being tested and there are issues being worked out. To help with the transition between Drupal 6 and Drupal 7, there is a new module called Metatags Quick that has been developed and is being used. And there appear to be plans to ensure that people who use this module to set up their keywords and other tags can upgrade easily to the new Metatags module once it is ready for production.
Metatags Quick allows you to configure which meta tags to enable for each entity on your site, including different content types, paths, taxonomy and user. You can then add these fields to your content just as you would any other CCK Field. And since these fields support the token module (which you’re about to install) you can also set up some patterns to help handle the creation of your metatags.
6. Set up cron
In Drupal 6, configuring Cron was a much more involved process that required setting up a command to tell your site to ping cron.php at various intervals depending on your needs. This was done off-site and usually at the server level. Depending on your hosting company, you sometimes even had to contact them and ask them to configure the cron job for you.
With Drupal 7, configuring your cron job is now easily done through the administrative section of the site. Simply select how often you want cron to run, and save your configuration.
How often you want it to run is going to depend on what you’re using the site for. If you have mostly static content that is only being updated every couple of days, then setting your cron to run once a day will more than satisfy your needs. However, if your site is going to include things that are updated more often, such as news feeds or newsletters, or various other services such as pinging services, Twitter updates and the like, you’ll want cron to run more often.
7. Get ready to rebuild your registry
Setting up a new site in Drupal can get extraordinarily frustrating if something happens that cramps your registry. As you go about setting up your theme, installing modules and the like, there will be times in which the site will try to rebuild its registry. The problem is that sometimes something gets clogged while it’s trying to rebuild this registry and you’ll find yourself staring at a WSOD with a Fatal Error… something like this:
PHP Fatal error: Class 'EntityAPIControllerExportable' not found in ...sites/all/modules/rules/includes/rules.core.inc on line 11
I’ve only come across this a couple of times… And both times I was so absolutely happy that I found the Registry Rebuild Module. Just as with other modules, this gets uploaded to your sites/all/modules directory. And that’s it. You don’t need to enable or configure this module.
In fact, if you are able to go in and enable this module, then you probably don’t need this module.
If a problem arises that requires your registry to be rebuilt, simple point your browser to
http://www.yoursite.com/sites/all/modules/registry_rebuild/registry_rebuild.php and this module will take care of the rest.
I should probably note, this is not an end-all fix-all of broken sites and will not fix every single error that pops up… It’s only meant to help unclog the mess that is keeping the registry from being rebuilt when it needs to be, such as when a module is updated to a new version.
8. Install the rest of your contributed modules
Depending on exactly what you want this site to do, you will likely have a small list of contributed modules that you need. There are thousands of modules that have been contributed to the Drupal community by Drupal members and they cover online classrooms, donations, project management, ecommerce and shopping carts and just about anything else that you can think of.
Now that your memory, URL patterns, SEO and cron are set up, it’s a good time to begin installing the contributed modules that you need. Make sure you read the
README.txt file for each module for specific installation and configuration steps, but most (about 85%) are installed by extracting and uploading the module to your server at
yoursite.com/sites/all/modules and then enabling the modules you need along with any sub-modules.
For each of my sites, I tend to go through this step fairly systematically; I upload and install two or three modules at a time, then configure each one before moving on to a new group to install. For modules with dependencies, such as either Views or Panels with Chaos Tools Suite, I make sure that I upload and install the primary module first, and then upload and install the modules that depend on it.
9. Control your taxonomy and categories
This step can actually be done alongside building your custom content types or setting up your existing content types.
Drupal 7 comes with a tags vocabulary already set up by default. This vocabulary allows for a free tagging system of categories. If you want your categories to be a bit more restrictive, you can set up new vocabularies and add in new terms. Some modules will install a new vocabulary. There are also a few modules, such as Hierarchical Select, which will help you set up even more features with your categories.
10. Set up your content types
Now that the majority of CCK has been integrated into Drupal Core, setting up various content types is even easier than before. There will still be some additional contributed modules that you’ll want depending on your exact needs, such as the Link module that creates a CCK Field specific for web addresses and links.
You can edit existing content types and customize them to your heart’s content with the help of CCK and Fields. Drupal Core comes with two basic content types, Article and Basic Page (Drupal 6 and earlier also came with two content types, Story and Page). Some modules, such as Frequently Asked Questions, Poll, Forum, and Blog will add other content types to this list that you can also alter and customize to suit your needs using CCK and Fields.
You can also create your own, custom content types. With each content type, now is also the time to add fields for your meta tags and categories as your needs dictate.
11. Tell Drupal how to handle your URLs
Once you’ve set your site up to be able to use clean URLs and have given yourself the power to alias those URLs, the next step is to tell Drupal what to do with them once they’re cleaned up and aliased.
Why is this important? I’m glad you asked. Typing in an alias for the Path module doesn’t change the URL – it only applies a mask over the URL that search engines and humans can read.
Drupal saves the URL for all content in the form of
node/[node id]... So in the example I gave above, the actual URL is still
node/4 and will always be
node/4. So, that means that this page can be accessed by typing in either
http://www.yoursite.com/ten-most-important-steps. For obvious reasons, this can be very bad for SEO. You want to minimize the number of different URLs that any one page can be accessed with, not increase them!
And, it’s kind of a pain, right? Having to go in to every page of content and type in a new alias? And if you forget to type in the alias you have to go back in… it’s a pain. So, we’re going to make it easier on you right now by downloading and installing the Pathauto, Token, and Global Redirect modules.
Pathauto will allow you to set up patterns. These patterns use a combination of input from you as well as tokens to create a URL alias and assign this alias to a piece of content automatically when you create the new content.
So, in the example above, I have tokens set up for each type of content. For classified ads, my pattern is set up as
(token for the date that the content is created)/node:title (the token that pulls the title of the content). So if I create a classified ad on September 20th and title it “Free Kitten to Good Home”, my URL alias would be
But if I didn’t want to post this as a classified, just as a basic page, the pattern is different. The pattern only calls for the
node:title – which, again, is the token used to pull the title off the piece of content you’re creating. So, if I were creating this announcement that I have a free kitten to go to a good home as a basic page, then the URL would be aliased as
Once your patterns are set up the way that you like them, the form that you use to create new content changes, too. Instead of just having an area where you can type in a new alias, there is now a checkbox that lets you know that an alias will be created for you using the patterns that you set up before.
If you don’t want to have the site set up an alias for you automatically, you can uncheck the box and go ahead and type in a new alias yourself.
To take care of the problem about having two URLs to get to the same page, Global Redirect comes into play. This module will run a couple of checks to make sure that your site visitors are always sent to the same page and always see the same URL.
We mentioned earlier that Drupal always saves your URLs as
node/[node id] (in our working example above, the node id was 4). Saving it in this way is very important as there are several modules that will use this URL, so we don’t want to go in and change it. But we do want to make sure that everyone always gets to see the aliased URL instead of this ambiguous
node/4. To do that, Global Redirect will run a check that looks for the alias and will automatically use a 301 Permanently-Moved Redirect to send visitors – be they spider, robot or human – through to the aliased URL.
I have this listed as an initial configuration step because Pathauto does not work retroactively. If you wait and install this module after you’ve already written several dozen pages of content, you will need to generate and update your aliases in a different way for the old content – though it will work automatically for any new content you write after you finish its installation.
12. Get your search working
Configuring your search is not very hard to do; but this is a step that is much easier to accomplish if done earlier rather than later. New pieces of content on your site will be indexed within your site-wide search settings every time cron is run… So if you wait until after you’ve already written a few dozen pages before you configure your search settings, it can take several cron runs before everything on your site gets indexed.
For the basic site search, configure the search settings to get the ball rolling. There, you will be able to configure how many new items can be indexed with each cron run, whether to search content or members (or both) and how to rank the results.
If you’re building an advanced search or a proximity search, it’s still a good idea to get these basic settings configured before you start moving on to bigger and better things.
13. Set up your menus and start writing your content
Drupal 7 comes with four menus by default: Main Menu, Management Menu, Navigation Menu and User Menu.
So, I added the new menu first; then as I created each page, I made sure to add it to this new menu. I tend to add things to my sites very systematically – ensuring that one section is completed before adding in a new section. However, this is a personal preference and certainly does not have to be done this way.
This is also the time that I start building any custom Views that I will be needing for my site. Some modules will supply your site with built-in Views already to go, and the Views Module comes with a few default Views that you can use and customize to suit your needs.
14. Get ready for backup
The Backup and Migrate module is a great starting point for getting ready to backup your site. It’s not a complete, all-in-one solution to your backup needs, but it definitely makes the process much easier.
The Backup and Migrate module is uploaded and installed like normal, in the
sites/all/modules directory on your server. From there, you can schedule regular backups, configure where to save your backups, and even set up a pattern for the name of the file that will be created.
As of this moment, there is currently no stable release of a module that will help you backup your files, though there is one that is available for testing. The Backup and Migrate module will help you backup only your database and the information stored therein; and although I have never had any issues with it, there is no guarantee that this will always work. So make sure that even if you do use this module you have a plan B set up with your hosting company as well.
15. Go live with fewer HTTP requests
Last but not least, it’s finally time to go live. How you go about launching your new site live is completely up to you. Depending on the number of scripts, CSS files and modules you have working for you right now, loading time for your site could be on the longer side.
So, just before going live, visit the Performance Settings page and configure your cache settings.
There are certain modules and blocks that are not compatible with cache because of the nature of their features – for example, a news feed built by the Aggregator Module or Twitter updates. Almost every other module, though, will work with cache settings.
In the performance settings, you can configure just how to handle your cache settings, how long cache pages should last before being recreated, and how long external sources can use a cached page.
Also, just before going live, it’s probably a good idea to change the way that Drupal handles reporting errors for your site. By default, your site will display every warning and error message along the top of most of your site’s pages and visitors to your site will be able to see these errors.
To keep this from happening, visit the error handling section and make sure that errors are logged and not displayed.
Hard to believe, but that’s it. Fifteen simple steps and your site has gone from Design to Live. Depending on exactly what you’re trying to set up, some of these steps might have been a little harder (or easier) than I’ve described here… And there are other steps that you might have had to take to fulfill other specific needs.
You may even choose to perform these steps in a different order than I have described here. The more you work with Drupal, the easier you will find these steps; and the better you will be able to set up your own optimized setup routine.