I know mostly everything you need to know, but just not the coding. I know to use POST rather than GET, i know about DB connecting and everything else, im just no good at remembering syntax.
Um....If you don't know the "coding", then you can't say you know "mostly everything you need to know" about programming a login system. And if you are "no good at remembering syntax", you'll never be a good programmer. I'm not trying to be mean or argumentative--just realistic.
First, understand that a login system that you code yourself using PHP (or ASP, etc.) will only be able to protect PHP files -- not PDF's, images, Excel spreadsheets, etc. This probably should be obvious, but this is because your PHP protection script will only be processed within a PHP page. Now, there are advanced ways to use PHP to protect these other document types. Basically, you place your PDF's, images, etc. in a non web-accessible directory. Then you write a PHP script that is used to download or access those protected documents. It opens those files then streams the contents using the appropriate content-type.
I've written a lot of login systems, so let me try to explain the architecture that is common to many login systems. You'll need a common include file that you include in every PHP script you want protected. This code should be the first thing that runs in your script. It should check the status of a session variable to see if the user is logged in. If so, simply allow the script to continue processing. If not, redirect to a login script. A key feature here is usually to store (either in session or cookie) the URL of the script the visitor was trying to access so that once they login, you can redirect them back to their original destination.
Your login script will serve two main functions. One will display a login form to the user. The second will process that form to authenticate the user. Authentication usually involves checking a FORM-submitted username and password against a username and password in the "user" or "member" table of your database. A common "trick" is to use md5() to encrypt the password. Store the passwords encrypted in your database. When the user submits her password, encrypt it before checking it against the database. If authentication fails, re-display the login form with a message indicating the failure. If authentication is successful, set a cookie to indicated their "logged-in" status, then redirect to the page the user originally wanted. When that page loads this time, the same protection code will run, but this time, it will find the cookie indicating the user is logged in, and the rest of the page will run.
So there really are only 2 scripts in a common protection scheme. One that is included in every PHP script to check logged in status and redirect to login script if not logged in. The other is the login script which both presents the login form as well as performs the auth checks.
My class_session provides both a method to manage sessions as well as a method to protect PHP scripts. A sample login.php is included. Instead of PHP Sessions, my class generates it's own sessions. The main reason for this is by rolling your own sessions, you can avoid the session timeout issues.