Chapter 5: Installing PHP Scripts

Setting file permissions

OK, now let's assume you're ready to begin installing a PHP script. Perhaps you obtained a script that you want to install; maybe you just wrote (and debugged?) one of your own. Either way, be sure it is ready to work on your Web server. Did you make sure all the HTML code is valid and that all tags are closed?

If you're sure that both of these jobs have been completed successfully, go ahead and upload the script(s) to the server. PHP files can be placed pretty much anywhere and you don't usually need to set file permissions. If your script came with installation instructions, be sure to follow them exactly - there's usually a reason when they ask you to put files in certain places (or set file permissions). Most of the time, you can just put them in the same folder or directory with your HTML pages.

In fact, you can build your whole site using PHP files. The web folder is often named "public_html", "www" or "htdocs". Your cgi-bin folder may be inside the web folder (public_html, etc.) or it may be at the same directory level as the web folder. When you log into the site using FTP you may see both the cgi-bin and public_html folders. Or, you may have to go into the public_html folder before you see cgi-bin. Set file permissions as described in the instructions. Depending on which FTP program you're using, there are different ways of doing this.

Common permissions are:

• Owner - read, write and execute (rwx in Unix terms)
• Group - read and execute (write is usually optional)
• Others - read and execute (write is usually optional)

Note: Often you'll see both "www" and "public_html" folders; these are usually just two names pointing to the same folder.

Tip: When you first log in to your site using FTP, try to upload a file to the initial folder (which contains the folder for your web pages). If you can write files here, that's a good thing! Why? Because files that are outside the "web tree" are not accessible to web surfers. That makes this a good place for log files, etc. that you don't want anyone to see. Remember: if a file is located here, and you need to refer to it (in a script or a link), you'll have to use ../ to make the web server look one level above the current level to find the file. This is a good security measure. But - beware of putting links to these files on any web pages.

If your script will be writing to files, the directory containing those files will usually need to be set to allow everything. Owner -rwx, Group - rwx and Others - rwx. This is permission mode 777.

If you're using WS_FTP, this part is really easy. Right after you uploaded the script file to cgi-bin, there was a list of files in the right-hand pane of the WS_FTP window. You right-click on the script file's name to bring up an option menu. Choose chmod (Unix) from this menu. Now you get a little dialog box with 9 checkboxes and a couple of buttons. They are grouped into Owner, Group and Other from left to right. They are grouped as Read, Write and Execute from top to bottom. Click all three boxes marked Execute so that there's a check mark or dot in the box.

Click the OK button. That's it! Now, whenever you right-click on the file and bring up the chmod (Unix) box, you'll see that the correct boxes are checked.

Tip: Verify this any time you edit the file and send a new version to the server. Sometimes the permissions revert back to the default state (which does not include Execute). If this happens, just set them again and all will be right in your world.

Some programs, such as telnet and certain FTP clients, give you access to the Unix command prompt. If this is the case, setting file permissions is also a breeze. Just type:

chmod 0755 [filename] or
chmod 0777 [directoryname]

Telnet requires the 0, but it doesn't affect the file permissions.

Just in case you're wondering about the numbers, here's the story. Read has a value of 4, Write has a value of 2 and Execute has the value 1. Adding the permission values together results in a number between 0 and 7. There's one of these "composite" numbers for each of Owner, Group and Other. So, if you do a chmod 755, you've set Owner to Read+Write+Execute, Group to Read+Execute and Other to Read+Execute.

If you fail to set the permissions properly, bad things can happen. When the server is asked to run the script it will display an error page. Most often, it will say, "ERROR 403: Forbidden". This means that the file does not have "execute" permission - the server thinks that nobody is allowed to run it. To fix the problem, repeat the procedure in the last paragraph.

This doesn't usually happen on Windows NT hosts, because most of them don't have the concept of file permissions. Also, PHP files generally don't care about file permissions at all. As long as they will work without the permissions set to 755 you can leave set to 644. 644 is more secure than 755.

However, depending on the Web server software package being used, the tech support folks may be able to deny execute permission to scripts on a case-by-case basis. This brings up a point that cannot be over-stressed. Always treat tech support people with courtesy and respect. They have a lot of power that you don't. They're often over-worked and stressed out. They must deal with hackers, viruses, "Trojan horse" programs, mail system hijacking and lots of other very bad things you don't even want to know about!

Test everything!

I'm not kidding. If the script is supposed to send out emails, do whatever it takes to get it to send you one. Then check your email and see if you got the message. Was it formatted the way you expected? Did it contain the text you expected to see?

If it was supposed to create some kind of account, verify that it did that. Does the account requires a username and password? Do you get know what they are? Did you type them correctly? Do they work? Does a wrong username or password also work?

In short, test everything the script is supposed to do and make sure it works exactly right. If there's a problem, check all your configuration-type stuff and be certain it's OK. Did you mis-type a file path? Did you set permissions where needed? (Sometimes you DO have to set file permissions - usually for files the script is going to write data into, such as log files.)

Be absolutely sure you've done everything you were supposed to do before you ask for help. But if you're certain that some failure or odd behavior wasn't due to not setting things up right...contact the seller or creator of the script. There's a chance that the version you downloaded has a bug.

Maybe it's one that the programmer never even saw. Software is funny that way. Once enough people have used a program, unexpected flaws often turn up. Usually the developers are willing and able to fix the bug. You'll actually be doing them (and all those who get the next version) a favor!

Sometimes the programmer will offer you a free product, an upgrade, or whatever as a reward. I know it's true because I've reported bugs and offered a fix or a suggestion. I ended up getting really cool freebies from the author. So don't be shy!

Copyright © 2004 Steve Humphrey