Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
The Drupal software comprises over a thousand files and directories, but for the most part you only have to concern yourself with a handful inside of the sites folder and the most important file inside there is the settings.php file. It primarily tells Drupal where to find the site's database, but it also has the potential to do much more. The file itself is over 500 lines long, but only about 60 of them are functional code and of those 60 lines only about 35 are actually active, while the rest are commented out, so don't fret even though it looks intimidating.
We'll look through the whole file with special emphasis on the most important parts, and we'll start by looking at the settings.php file as appears in a traditional installation; that is where it's on the web host, as opposed to using Acquia Dev Desktop on your development computer. I'm already logged in here. Take a look at where we are. Here's our lynda site in the site's folder and in default. If I list it, and there is my settings.php file. I'll edit it by going nano settings.php, and again, you to learn more about this in the videos about using the UNIX command line.
So let's start up here at the top. All of the lines that you see that start with stars like these are just comments; they don't actually affect your site, so let's start scrolling through lots and lots of comments. The first part has to do with a multi- site installation, and we talk more about that later on in this course. But again, this is just documentation; it talks about how to set them up with the different options that are possible and so forth. The second group of comments is the database settings; this is the most important part. We'll scroll down, and again, you can read these at your leisure, but when we get way down at the end, we see the actual settings for our site; here, where it stops being commented.
The most important parts are the database name here, which in my case it's tgeller_lynda, the username, the password, and then some of the other ones, which you usually don't need to change. Let's continue on. Then we have quite a few more comments. This part is actually also important if you don't have user ID Number 1. User ID Number 1 you might remember, is the one that gets installed when you first create your Drupal site, so if somebody else installs the site and you don't get that password, you're going to have to change this line here, update_free_access, so that it says TRUE.
Otherwise, you won't be able to run update PHP on your site, and you won't be able to bring it up to the latest version of Drupal, for example. This can be very touchy though, because if you change this value to TRUE, like so, and then forget to change it back, it means that other people may be able to make changes to your site, and that's actually a big security hole. So if you do change this, go right back in and change it back to FALSE. Now we come to a section of settings that very few people ever find a reason to change, so I'm going to go through them really, really quickly. As you'll see though, there is a fair amount of explanation in the settings.php file itself, in the form of documentation.
The first thing here has to do with how Drupal comes up with random numbers this drupal_hash_salt. You generally again will never have to change this. However, do note up here that you can store this in an external file, if your security setup demands that. The next two settings are for troubleshooting. They'll generally only change them if your site isn't working properly when you first install it. We first come to the base URL, and you notice that this is also commented out; by the way, both the hash mark here and the star are used for commenting in files of this type.
Continuing down we have a section of PHP settings, and a lot of these are ini_set values. Basically if you don't know what these are, don't change them, and if you do need to change them, take a good look at the documentation that comes with them. The cookie_domain variable, you only change if you're doing cross-site tracking and that will happen if you have a complicated setup for your domains. If for example, you're hosting your site on one domain, but it's being called up on another domain, and so forth, and you wanted all to be tracked in the same cookie, that would allow somebody who logs on to one site, to also get into the other site without having to re-login.
Then we come to a section called Variable overrides. Quite honestly I've never heard of anybody using this, because pretty much anything that you do here can also be done in the Drupal interface. The only reason I could imagine changing these is if you're setting up a Drupal distribution where you're handing off a specially configured copy of Drupal and you want to make sure that these values get in. As we continue down we have quite a few settings that are really geeky. There is this reverse proxy configuration, a whole bunch about page caching, file compression, and so forth.
Basically, if you don't know what they are, then don't touch them. Next, we come up to String overrides. This is something you actually might find yourself using if you just want to change one or two little things in the site, the way that it states things. For example, if instead of saying forum, you wanted to say Discussion board, you would uncomment this line here; these two are just given as examples. Now I wouldn't use this if you're doing some large amount of changes. If for example you're translating a site from English into French. To do that, see the video "Internationalizing sites" in my Drupal Gardens Essential Training course.
Continuing down, we have a way to block certain IP addresses for security reasons. It's possible to change how 404 pages are displayed; that is, when people can't reach a certain page in your site, you can make them go a lot faster by changing these configurations, but generally speaking, you only have to do that for extremely busy sites, where you want to make sure that calling up those pages isn't taking up a lot of resources. The last section is this Authorized file system operations. You can change this if you want to prohibit Drupal from using the update function for example.
This is what allows Drupal to update modules and do other things on the file system. Again, generally speaking, you won't ever touch it, and that's the end of the settings.php file. The last thing I want to point out is how Acquia Dev Desktop puts the most crucial part of this file, that is, the database address, at the very end. So to show that I'm going to switch over to my Desktop. Close out this window. Open up my desktop installation. Go to sites, and lynda, and there's my settings.php file. I'm going to open that in a text editor, which in this case is Text Wrangler.
Scroll down to where the database settings normally would be; and you'll notice it's actually just an empty line in this case. That gets overridden by what Acquia Dev Desktop puts at the end of the file here, and you'll notice it puts up this big warning: don't edit anything below this line. Well, the fact is, you may have to edit what's below that line in order to make it work on your web host when you move your development environment. So there you go. Once we broke it all down, it wasn't so bad, was it? As you saw, there are very few parts that you really have to change, and in fact, the only part I've ever personally touched was the database settings and the update free access setting.
Earlier I stated the rule I follow for the rest of the settings. Simply, if you don't completely understand it and you have a specific reason to change them, just leave them be, or find someone experienced in making such changes. In any case, be sure to back up your settings.php file before making any changes, so that you can roll it back if anything goes wrong.
Get unlimited access to all courses for just $25/month.Become a member
82 Video lessons · 101804 Viewers
61 Video lessons · 88555 Viewers
71 Video lessons · 72373 Viewers
56 Video lessons · 104074 Viewers
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.
Your file was successfully uploaded.