Join Tom Geller for an in-depth discussion in this video Comparing development and production environments, part of Drupal 7 Advanced Training.
- View Offline
So, you've built a Drupal site on your home computer, and are ready to show it to the world. Then you upload everything, and you get a big fat error message. That's because in reality there are quite a few differences between running Drupal on your development computer at home and running it in production as they say on a server. And believe me, I've gone through this experience many, many times and this video is the result of some of that painful experience. I very quickly went over some of these points in the video, launching a Drupal site in the Drupal 7 Essential Training course.
Now I'll explain a bit more in detail. I think of the differences in the following way: As you know a Drupal site is basically made up of the files and the database, and each of those have a structure to them and permissions, and these vary slightly between your development machine and production machine. Let's go through each of these one at a time. We'll start with the file structure. First, I'll go back to my development machine and take a look at a site that I already installed, this lynda site here. We go down here into the Sites folder, which is as you know the place for all of the files specific your site go, and we see that there's the all folder, and as you know that's where you usually put your modules and themes.
The default folder, which if you don't have a multisite setup, is where all of your files go and then there's this lynda folder. Now it's called lynda, because I named the site lynda, but of course, it would have whatever name you actually gave your site. When you use Acquia Dev Desktop, which is what I use to install this site, you end up with a multisite setup by default. So you'll have this lynda folder. Now when you installed using a different system, including on those web hosts, it will simply all going into the default folder. So be sure to keep an eye on that, and one thing you'll notice is that every one of these folders, except for the all folder, has this defaults.settings.php to start with.
Then when you've actually installed, the active folder will have settings.php. That's where you can tell where the active site actually lives. The second thing to watch out for is hidden files. I'm just going to go up a level here, and open up this window a little bit and we see all of the files that are in our Drupal site. However, we don't see any of the files that start with the (.) dot. If we switch over and look at the same folder through the terminal window that is using UNIX command line, we actually see something different. I'm going to go to my desktop where it lives, and now list it with all of the files shown.
So we scroll up to the top. We have this .gitignore and .htaccess. I'll show you later on in the course how to use the UNIX command line. The important thing is when you're on your development machine, whether it's Mac or Windows, by default they don't show these dot files. But when you're using the UNIX command line, whether it's again on your Mac or on a web host, you do see them. So you have to be careful and make sure that you actually copy those over. If you want to see those files in Windows or Mac, I recommend that you go online to Google or something like that, and say show dotfiles, and let's say in Finder, that's for the Mac, and then you can get some instructions on how to do that.
It's actually fairly complicated. So your best bet is to simply copy over the entire folder, which contains the dotfiles, and then they'll be copied as well. The third difference that I want to point out has to do with where Drupal puts the files. Let's go to a site that I've installed on the web server. That's lynda.tomgeller.com. Then we go upto Configuration, scroll down to File system. These paths here, Public file system path and Private file system path, as well as the Temporary directory, might be different when you move from the development environment to the production environment.
This shows up most often, because when you load the site, graphics don't show up. Simply put, Drupal doesn't know where to look for them. So if you have that problem, take a look at this setting after you've moved your Drupal site over. So that takes care of the structure of the files. Let's move on and talk a little bit about file permissions. I talk more about UNIX file permissions in the video about using the UNIX command line. If you need to make tweaks on the server, watch that video along with the Permissions section of the UNIX for Mac OS X Users course, also on lynda.com.
Usually everything will be fine when you move files from development into production and then back again, and Drupal actually fixes some file permission problems itself. The real issue arises if your web host doesn't give you all the permissions you need to administer your Drupal files, and when it does happen, there's really nothing you can do, but to send a support request to the web host. They all set up their permissions a bit differently, and I'm afraid I can't help you get pass that problem. Moving on, we have the structure of the database. There's not much to say about the database structure itself, because it generally remains the same between development and production environments.
I have run into two issues having to do with database names however. First, if you use a database name with an underscore character in it, you may have problems because it has a special meaning in your MySQL program. Second, some web hosts force you to fit your database names into a specific format. I'll show you what I mean. I'm going to go to my own setup on my web host, which happens to be webfaction.com. If I go down to Databases and then Create new database, you'll notice up here that it forces me to start every database name with tgeller and underscore (_).
That's why I've had to use the name tgeller_lynda, and as you'll see later on, tgeller_commerce, and other words like that, in this course when I'm doing things on the web host. You'll learn how to tell Drupal about a changed database name in the video about configuring the settings.php file. The last thing to look at is database permissions. This is an area where lots of problems crop up. You might not be able to create or delete databases for example. Or maybe you're limited in how big a file you can import. The two videos in this course about moving databases, along with the one on server configuration files, should get you pass those issues.
If not, once again, talk with an administrator at your web host. If you don't run into any problems moving between your development and live environments, then congratulations, you are in the slim minority. But whatever problems you do encounter, it's important that you get used to solving them so that you can move among the too easily. Those skills will remove barriers to running your site using proper procedures, which in turn will free you to be bolder with how you build your sites.
Drupal 7 Advanced Training was designed as a follow-up to Drupal 7 Essential Training and it also dovetails nicely with our other Drupal courses, such as Drupal 7 Reporting and Visualizing Data and Create Your First Online Store with Drupal Commerce.
- Moving a site from the development environment to production
- Hosting a Drupal site
- Moving databases with phpMyAdmin and Unix commands
- Making site administration more efficient with Drush
- Backing up site data
- Moderating comments
- Migrating from previous versions of Drupal
- Working with themes
- Creating variable layouts
- Enabling social features
- Creating an online store with Drupal Commerce