owatagal

I have Wiley's "MySQL/PHP Database Applications" which I like because it specifically focuses on how to create things like guestbooks, discussion boards, content management systems, catalogs, etc--the first two chapters teach you the basics of PHP and MySQL, and the rest of the book shows you how to integrate them for specific applicatiosn. To be fair, I did know the basics of both languages before going in, so it's made a lot of sense to me, but it's also already taught me better ways of doing things--I think someone new to both PHP and MySQL could follow it, especially if you took time on the first two chapters to really understand the basics of the languages before jumping ahead to the fun application stuff.

One thing to keep in mind as you're learning, especially if you happen to pick up any older books/tutorials: prior to PHP 4.2.something, register_globals was automatically set to 'on', which allowed you to process variables without defining them. Because it's a security risk, register_globals was then automatically set to off, which is where it is now for most sites. This means that any time you process a form, you have to define your variables. So for every variable on your form, at the top of the results page you need something like: $my_variable_one = $_POST['my_variable_one']; $my_second_var = $_POST['my_second_var']; (which is what Jaxx is saying) Then later on you can call echo $my_second_var; And it will work -- but only because you defined it early on. You're going to see a lot of tutorials that don't define the variables, because they were written prior to the 4.2.whatever switch, but if you get into the habit of always defining them, you should be ok. And POST is almost always better than GET, but if you have to use GET for some reason, you define your variable as $my_variable = $_GET['my_variable']; This threw me when I was first learning--if you google "php register global", you'll get a bunch of sites explaining the switch and the security and what not. Better background than I can explain, certainly!

I don't know very much about .htaccess and rewrite rules, so I've cobbled this together after several days of trial and error. Basically, I decided I didn't like my blog on a subdomain (blog.mysite.com) and I wanted to streamline it with the rest of the site (mysite.com/blog/). I also wanted to change all the dynamic URLs (mysite.com/blog/archives/view.php?date=2005-02-10&keyword=puppy) to clean URLs (mysite.com/blog/archives/2005/02/10/puppy) This is how my .htaccess ended up (it's saved in the /blog/ folder): This works, so I'm basically happy, but I'm just trying to understand the logic of this stuff. Since I am getting rid of the subdomain, I assume the first two RewriteCond and the first RewriteRule have to be in the /blog/ folder in case someone does try to access blog.mysite.com--the /blog/ is acting something like a root folder until the URL redirects it back to mysite.com, right? I don't understand why the second RewriteRule also has to be in the /blog/ folder instead of the site root. I've tried putting it in the root folder as --basically, it's the same rule, but with the addition of the /blog/ folder. But it doesn't work--I just get my error page, and when I echo out the referer, I get the fake blog/archives/2005/02/10/puppy URL and not the URL I want it to go to. Yet as soon as I move it to the /blog/ folder, it suddenly works for me. Is there a reason for that? I'm confused. Granted, it works, so I shouldn't complain, but I hate not understanding things. Does anyone understand rewrite rules enough to know why I can't move the second rule, at least, to the root folder? Does it have something to do with the fact that I've stopped using the subdomain and am redirecting traffic back to the regular mysite.com/blog/ ? Any help is much appreciated. I'm just trying to understand what's going on.

Great -- thank you for the help!

I'm looking at moving a couple domains into a reseller account, and will need some redirect features on the .htaccess file and would like to make use of an .htpasswd file to password protect directories. Are there any limitations on what can be redirected through the .htaccess file? For one domain I will be stripping .asp file extensions and replacing ithem with .php. For another domain there will be some fairly significant architectural reorganization, so files will need permanent redirects. Is there any problem with this (the company where I currently host a .php site gives me only limited control over .htaccess functions, so I want to make sure I'll be able to convert my asp site to php with a minimum of hassle -- for which I need more .htaccess permissions than I currently have. Also, it would be convenient to be able to write permanent redirects, because I hate 404 pages). And is it possible to save an .htpasswd file above the root level so that user names/passwords can be stored in a place that is not web-accessible? Alternatively, where are the user names/passwords saved if I set the option through CPanel (i.e. is it above the root or is the file web-accessible)? I appreciate your help. (I had another question on MySQL databases, but that was answered through another post. It's good to know I can query a database from multiple domains -- something else my current hosting plan doesn't let me do.)