Re: good practice

Or put them outside of the web server's document hierarchy. I'd feel safer with that than naming them with a .php extension. If they can still be executed by PHP using a GET request, then something could still be output to a user's browser. (Likely unintentionally, of course, but still...) Plus, if they're large enough include files that include a whack of other files, then why bother wasting CPU cycles on something that doesn't need to be processed in the first place? Just send back a DENY and get it over with. Personally, I stick 'em in an include directory and set up a .htaccess with something like <Files ~ "\.inc$"> Order allow,deny Deny from all </Files> I like having everything like that in the web server's directory if possible. Makes distributing stuff easier when you don't have to tell users, "Now copy all .inc files to /some/path and set PHP's include_path to /some/path, and make sure the server can read that directory..." J Michael Kimsal wrote: > > > On that same topic, *why* do people name files with both .inc and .php? > Your .inc file has PHP code in it, right? Why not just call it .php and > spare the server reconfiguration. If knowing which files are "include" > files (long time since I've made that distinction!) just prepend > them with inc_ or put them all in an includes/ directory. > > You hit a raw nerve there J Smith. :)