or …
“Just Enough about Unix to get into trouble…”

Determine type of server:
I’ve found that PHP scripts work more reliably on Unix servers than NT. Also, be sure that the server is not running PHP as a cgi script. It really doesn’t work as well. How do you tell?

phpinfo
Upload a little file containing this code:

<? phpinfo(); ?>

Name the file “phpinfo.php” and then view that page online in your web browser. This is a php script that returns all the information about your server environment. In the first table of information, you will find “Server API.” This should be “Apache.” If it says “CGI” you are in trouble. However some things will work fine in this setup, so it’s always worth a try.

Linefeeds:
Set your HTML editor, including text editors to use [b]”Unix Linefeeds”[/b]. Generally, the default setting will be the one for whatever type of machine you are on, so be sure to check this. Remember this tip! It is very easy to forget to check this preference if you are working on a new setup, or have reinstalled software. The wrong linefeeds result in messed up code which the server cannot interpret.

Decompression software:
Stuffit Deluxe will expand almost any combination of tar, gz, zip, including nested compressed archives, and is well worth getting.However, it is always best to check that nothing is left unexpanded. Also, it is important to check the preferences in Stuffit and make sure that under “Cross Platform” it is set to “never” convert to MacBinary. If you are using the True Finder extension, make sure the preference is set there as well.

The correct unix-geek alternative to this procedure (and to most of the following) is to ftp the tarball up to the server, telnet in, and decompress the files on the server. In a designer’s work environment though, there are many other tools that come more readily to hand (and to mind). Especially since you will probably want to edit several of the files from within your local html editor, such as config files, and html templates, rather than using a terminal and Pico.

Shut off automatic features:
If you are using Dreamweaver or GoLive,or any other WYSIWYG editor, turn OFF all automatic html correction features in the preferences. In Dreamweaver this is under “Code Rewriting” in the preferences. In many scripts, especially templates, there are many times when an entire page of html will be un-terminated (tags are not closed), and that’s “OK.” The last thing you want is for a helpful program to fix all that for you.

Special note for editing perl scripts:
Do not use Dreamweaver for editing these, even for minor changes. Use bbedit or some other text-editor. As of this writing, Dreamweaver has a nasty habit of corrupting perl code.

File types:
When you ftp files to your server be careful that php files go up as ascii, not binary. Dreamweaver will often make a mistake on any extension that it doesn’t understand, so either change the extension temporarily, or use an ftp client that allows you to specify ascii, binary, or whatever. If you aren’t sure if a file is binary or not, open it in bbedit: if it looks like gibberish, it’s probably binary.

Paths:
Phpinfo is also useful for another reason. Many times you have to determine the exact path from your server’s “Home” to a given directory in your site.
Place a phpinfo script in the directory in question, and browse it (http://yourdomain.com/yourdirectory/phpinfo.php). Look way down the page for the “PHP Variables” section. There will be an entry for “_SERVER[“PATH_TRANSLATED” which may say something like: “home/yourname/html/yourdirectory/phpinfo.php.” This is the path to the file phpinfo.php.

Permissions:
It is possible to set permissions using your ftp client which I often find more convenient than telnetting in and chmod’ing everything. GoLive also supports this, but Dreamweaver does not. For a good article explaining permissions read: Understanding Unix permissions and chmod.

Why things don’t work:
This leads to another point: When things aren’t working, it’s usually either the wrong path, or the wrong permissions

Error messages, the key to reality:
How do you tell? You read the error messages very very carefully. A path problem means the program can’t find a requested file (often an include) and errors out. Permissions problems will usually result in a file or folder not being able to be read or written to, as when a gallery needs to access a folder to add images.

Long filenames:A Mac-related problem is that in some cases, the unix file names are too long, and the finder will truncate them as you decompress the archive. Then any requests for “fooblahblahblahblah.php” will turn up empty. Simply correct the file name on the remote side using your ftp program.

Managing your databases:
Unless you are using your own server, it is very likely to be set up so you cannot log in to your SQL database from a remote location. This means you can not use MacSQL or other desktop based database management utilities since they will be denied access. The solution to this is to install and use phpMyAdmin for administering the database. This is simple to install. Only one or two lines need to be edited with your database login and password information. This will often be preinstalled for you by the server administrator.