surefire

No prob... I like your code better and the fact that it doesn't require Apache to work is a plus. I guess you installed it on a non TCH machine... cause I thought all TCH servers were apache. I dunno. Only been here ten days or so. Just to clarify... I wasn't hurt or offended, your modifications are excellent and should absolutely be used. I'm going to be changing my current code. On my sites. From what I've read, this is a feature that was added to php4. Since php4 has been out for a while... it's high time I update my code and take advantage of the benefits.

Freddy... your code is more elegant and also safer from a security standpoint. This is an excellent piece of advice that you've pointed out and I've been meaning to "re-teach" myself this method for safety reasons. Thanks for reminding me. But you said: You freaked me out so I uploaded the pages to test them out. They work. But without a doubt... your modifications are a significant improvement over my code. Hey... I don't know everything.

Only other thing I'd say... is that my past experience with including header and footer taught me that you have to take into consideration that a url to your header file might be correct in one file, but totally incorrect in another file in another directory. One solution (of many) is this:

Don't worry about it for a second... I don't mind... I'm glad you posted. I'm not the only one who can write about PHP. No one ever asked me to in the first place. Besides, I'm glad to have the help. I have stuff to get back to, pronto. I was giving you kudos that you did a great job and expounded on the idea and the details. Well done. If you and I keep it up, we'll write our own PHP manual in no time. Includes can save so much time for so many people that if they just 'get' this one thing... and nothing else that PHP has to offer... time well spent. So it deserves it's own tutorial... which it now has. Good job.

Freddy's right... One last thing and then I'll shuddup. Whether you use a database or flat file, you must use preventive coding to make sure malicious users don't a- Deface your site with naughty words or redirects to their site b- Break your site and erase your database by using sql injection and other tricks. As a general rule, database is more secure option than flat file.

Holy deja vu, Batman... I think I've seen this before. Just giving you a little grief, Jimuni. This is a well written tutorial that explains includes in a bit more detail than I did. And I think that the subject is definitely important enough to warrant two threads on it. Just to give the rest of TCH members an idea of how useful this concept is... I have a multi thousand page site that I manage. I can change two files, upload them to the server... and my whole site changes instantly... layout, css, whatever I want. Neat trick here! You can avoid ever serving up another page that has the ugly, unprofessional title "Untitled Document" just by putting in a little 'if' loop that says "If there's no $title variable declared, then $title is 'Ultimate Offshore Gambling' ... or whatever your want your default title to be. The other way to do it... which I use. Is to put a default title followed by the $title variable. So there's always a title, but I can put more details in the title if I want. Here's an example Worst case... The title is "Stamp Collecting:" If I add more info it could be "Stamp Collecting: Rare Foreign Stamps" Hope that helps.

By the way... Dreamweaver... in my opinion, doesn't write very clean (or good) php code. It will help you connect to a database, but the rest I would code by hand. It's a pain the first time around... but by using variables in your code, you just cut and paste. Ctrl+c Ctrl+v My two favorite shortcuts. PHP is best coded by hand.

Okay... Although it's touch to read variables set in php code... I still want the keys to my database outside of the public html folders. So I create a file called... I dunno... keys.php (little obvious but just an example) These are variables I made up. You'll need to modify those to your actual login info. Oh, by the way, this assumes you already set up a table or two in your database. Use PHPmyAdmin in CPanel... very easy. So, FTP to your site, create a folder in your root so it sits on the same level as your publi_html folder. FTP keys.php to this folder. Now you need a page that connects to the database and does some stuff. Otherwise... what's the point. So let's say it's list_of_something.php replace usrnm with your username replace folder with the folder you created in your root dir The include() function brings in the keys at run time. Then I would go to cpanel and password protect your folder with the keys.php in it. Hope this helps.

Yep... that was you. Your script is waiting on the other thread you wrote recently. I certainly don't expect payment... but if you'd like to make a donation to my IRS approved "church"... then father Surefire would absolve you of your worldly sins. (Totally kidding) By the by... cgi is just fine as a server side script... but I've read that PHP is much faster. Don't know this for fact... but it seems to be commonly accepted. Same goes for SSI... and less functionality. (But it's simple) But free advice is worth about what you paid for it...

Yeah.. there's always 50 ways to skin a cat. But the request seemed to indicate a simple solution. Personally, I don't see what value this script would be (other than amusement) since the variables dissapear into cyberspace as soon as the page is refreshed or the browser closes. No other users will see this info... But hey, chs22 didn't want a database script. (obviously other ways to do it other than db)

Dang... KW... you read the same stuff I do. chs22... if I'm not mistaken, I think I actally wrote the script for you on another thread. If that was someone else, forgive the mental lapse.

Jimuni... as usual... is right. page2 MUST be saved as php. Rule: if your page has <?php in it... it must be saved as php or else the server doesn't know it should be ready to read php. Rule 2: if your page is saved (and served) as whatever.php but doesn't have any php in it... the server doesn't care. You still get to pass go and collect $200. I wrote the last little script to indicate that just having one php page in your site doesn't require changing EVERY page to .php... but you certainly could. I do.

Also, if you wanted to have a form on page2.php and POST the form information and the info from page1.htm then here's one way to do it. In the form on page2.php, create hidden variable tags and then use the php print() function to create the necessary html. Example

At the request of another TCH member, I wrote this basic little script... It involves two pages. One html (page1.htm) and the other php (page2.php) page1.htm page2.php Notice that the form on page1 POSTs to page2.php In otherwords... whatever is typed into the form is sent over to page2.php in the form of variables named after our text boxes (could have been drop down select buttons or whatever). So the variables and $email, $name, $color. All php variables start with "$". (Some exceptions not worth noting) You'll also notice that except for three small snippets of code, page2.php is almost completely HTML. It's also very important that you purposely choose POST in your form instead of GET. Using GET isn't bad... I've heard it's quicker... but the problem is that it sends info in the URL that looks very much like: Showing these variables in the browser URL window is (usually) not a good thing. One last thing. This script doesn't bother to check that $name is a name or resemble a name... similarly, no checking done with our other variables. DO NOT trust your users to always play nice and input exactly what you want them to in the form. In fact, my experience has taught me to ask several questions: 1- What is the most malicious, code cracking input an evil little mind could type into this form? 2- What is the dumbest thing that someone new to the internet could type into this form? 3- How do I prevent either from ruining my script? Normally, I would use a combination of form validating javascript on the front of the form and back up my security with PHP functions like htmlspecialchars() on the back end. And if it's going to a database, you need addslashes() and stripslashes()... But I digress. That's info for MUCH later.

I don't mean this with even the slightest bit of animosity or elitism... but it's a tall order to ask others to write code for you... people pay good money for that. But since your request is easy and you're part of the TCH family... what the heck... just don't tell my clients. page1.htm page2.php There you go. I accept Visa, MC, American Express... just kidding... sort of. Now, one thing I'll point out to you is that this little script doesn't check to make sure that name is a real name, email is a real email, or that color isn't a number. But those nifty modifications require about 50-100 extra lines of code... Anyhow, ... enjoy.

Jim, I didn't follow that one... could you help me understand what you mean? Thanks

Glad to be here. I didn't mention that while at Value Web I'd occasionally venture out and try other hosts only to be sorely dissapointed. My feeling used to be, "Well Value Web is expensive... but it's the best I've found." TCH is in a separate class. So I'm very happy to be with TCH.

There are plenty of options out there, sorry this one didn't work for you.

Okay... that tangent I went off on regarding MySQL passwords in a separate folder... It's true but disregard it. 1- If you aren't connecting to a MySQL database then it doesn't matter to you 2- Your login information is not put in any folder that you need to protect. Here's what I was saying... If I write a PHP code to connect to a database, I need to have the password and login info in my code somewhere. Put rather than putting the info in my public folders, I'd be smarter to put the info in an array, inside of a password protected folder outside the public root. Then I include those files and variables at run time rather than keeping them in my code. I bet that makes tons of sense... right? Just techno gibbersih... don't worry about it.

Okay... I'll answer your question... but I highly discourage others from using this... just use the redirect. Here's the answer to your question: Needs to be changed to: Sgarrett, I stronly recommend that you take a break from this script. I say that from long frustrating nights at the computer with 8,000 line codes looking for a missing { . In a few days, you'll see things that you aren't seeing now and the redirect option will seem like a snap. The "hack" I've given you here is a workable but sloppy way to do it... A good script can be dropped into another website and be up and running with minor alterations. Besides... as frustrating as this might be... you're learning php. (Like it or not)

Small example But you can also set up classes like And use it in your html as <td class=one> Lots of ways to do it. Don't limit yourself with these simple examples... tons of info on CSS right on the web. Very useful stuff.

Sgarrett, What Lou means is that in the referrers array: That you can add more info such as your IP and also your url starting with 'http://' Earlier in this thread I mentioned how new sites at TCH might need to put in their IP address until everything settled down with their url (not a great explanation but I haven't had coffee yet.) All that the code is doing is grabbing the url info of the page your form is on. If it matches one of the values in the referers array, the code proceeds. If not, the security measure stops the code and gives you an error message. The code works... It's just a matter of modifying the details of the code to your site. Not difficult... but certainly frustrating if it doesn't seem to work. Lou, glad the code is working for you and thanks for sharing the info.

If you are receiving the inputs in your email... in other words... if the information you type into the text boxes for your form and coming through in your email, then you're done except for the error message on the redirect. If that's your situation, I'll give you two ways to fix it. One, open up your php file in Dreamweaver (your editor) and make sure that the very first line is And I mean there can't be a single blank line. For example... this is bad: Most php scripts wouldn't care, but this one does because of the way redirects are done... that's all I'll say on why. Remove any extra lines or anything above the <?php and then save the file and ftp it to your site so it overwrites your old file. Then... and this is key, I'd go to your browser tools and delete old files and history so that your browser knows that your php file is new. Or if you get that error message, hit refresh on your browser and see what happens. Two... Find the line of code in your script that tells the server which page is your redirect page. Add // in front of the line so it effectively turns that line off. It actually makes it a comment and so it isn't run by the server. Then there's no redirect at all, you just get a regulary old thank you page. Only downside is that it doesn't look like your site at all. If you are receiving information from the script in your email... you're close.... very close.

Tracy, your question is a good one... Both your questions can be answered at once. The print command is a PHP function (I think that's the right terminology) that tells the server to output certain code into your html. So when you take the code we created and ftp it to your site, you see a well formatted html page when you view source. Here's a piece of html code we asked php to help us create: So, you are correct... the year does have quotes around it. But this is html we're writing. All we've asked php to do is to help us write the same html code we would've written by hand. You don't see the quotes on your display because the html code you've written tells your browser... "Here's a drop down selection box, everything in quotes is a possible choice that you should show the user, and everything between > < is the corresponding value for that choice." It's just html... nothing more. But by using PHP's print function, a simple loop, and a little planning, we don't have to write all that html code ourselves. We get help from the server. The important thing to understand is that PHP does it's work on the TCH server... then the server sends HTML code to your visitor. So no matter what you ask PHP to do... at the end of it all, html code is sent. Which is why PHP code does neat tricks that everyone can see... the tricks are done before html code is sent over the internet. Get it???? So don't think of switching from HTML to PHP... think of pumping up your HTML with a little PHP. You're still sending html to your visitors. I mentioned in a previous post two styles of PHP coding... Some like to write PHP code that asks the server to create almost every line of html. Others (like me) write in html, and then insert snippets and blocks of php to spruce things up and make our lives easier. No right or wrong... just different ways of achieving the same result: HTML with extra flair. Hope this explanation helps.

This isn't a question... just my experience so far with my first week or so at TCH... my new home. I'm in the process of moving several sites over from Value Web after hosting with them for over a year. They have some strong points... but TCH is heads and shoulders better. Here's my analysis: TCH versus ValueWeb PHP TCH: Compiled as Apache (preferred method) 4.3 version XSLT and XML extensions Pear Extensions Zend Optimizer (for faster script execution) (Bottom line for those who aren't geeked out on PHP like me... TCH has loaded their servers with all the bells and whistles. You may never use it... but it's there.) Value Web: Compiled as CGI 4.2 version No XML functionality No Pear extensions No Zend Optimizer MySQL TCH Database on same server as website (localhost in script) Fast You can create multiple databases, assign users, and have varies levels of access Included with any web hosting account Value Web Company packs every mysql database for all clients on two servers Your database does NOT reside on the same server as your website (longer connection) Slow as molasses You are automatically assigned only one database, the username is automatically set to the same as your website, and your username is revealed to visitors anytime there is a failure with connecting to the database and error reporting steps haven’t been established MySQL through Value Web is only included on request and costs at least $15 extra per month Statistics TCH Several tools to analyze log files Value Web Log files are set up in a way that makes it practically impossible to be read by popular third party software like Analog For $10, you get a special version of Web Trends that is set up to read and analyze the log files but the depth of the report and the details leaves a LOT to be desired FTP TCH Allows you to put sensitive files (password) outside the publicly accessible html folders Switching to TCH gave me the ability to set up include files outside the public directories and then have my PHP scripts include them when database connections were needed. This is a huge security advantage. Value Web Forbids you access to the root directory and therefore every folder and file is automatically accessible by the public Include files are accessible to the public Cron Job TCH Gives access to automatically run scripts through access to cron Value Web Under no circumstance does Value Web allow you to execute a cron job. The only workaround is to have a “fake cron” script that executes EVERY time your website is accessed. This is a drain on resources and also requires that your website is hit at least as frequently as you want your script to execute. Control Panel TCH Full featured control panel automatically loaded with PHPmyadmin and other handy scripts Value Web Control panel is okay… but very inferior to TCH Price No comparison. TCH is better value over "Value Web" And, to some it all up, TCH Rocks I'd say that ValueWeb's strong suit is the fact that you never have to wait on hold because they have this cool call back feature. It turns out to be pretty handy since I had to call Tech Support often and ask them why their MySQL server was so dang slow.