Dan

On second look..my suggestion is probably wrong. I just found some HTML code that does the same thing with the label for tag. I still think it may be in your html though. Your if statement worked for me with my HTML which matches what is in the book.

In your HTML code, try changing the label for="name" to something other than "name". I cut and pasted your if statement into my register.php script and that worked fine and the $trimmed statement also looks ok....that leaves the HTML.

Where is your code in which you define the $trimmed array?

You have a typo in your script. The line below is incorrect. // Check for an uploaded file: if(isset($_FILE['upload'])) { It should be: // Check for an uploaded file: if(isset($_FILES['upload'])) { Happens to me all the time.

You will likely then need to turn your error reporting on. It is defaulted to off. What you want to do is in the php.ini file set the display_errors flag to on and then restart Apache. Try your page again and you should see an error or warning message. Note, it is mentioned several times in the books that you would only want to do this for your development server. Don't have this turned on for your live site as it can lead to security issues.

What error are you getting?

Hi Larry, We are all refering to the comment you made back on 9/26 in regards to the question centerNegative had asked regarding the forums database. HartleySan and I tried our best to figure it out and provide assistance, but I think we were also waiting to hear back from you to confirm that we were right on or way out in left field with our response. Dan

I googled your question and the first site that came back was this. http://www.html-form-guide.com/php-form/php-form-checkbox.html Google is a developer's best friend. Dan

Center, Your first question was something I was trying to figure out as well so I just tried it. I started a transaction against the forum database and I updated a row in the messages table and then a row in the users table. I then did a rollback and got the following warning: 0 row(s) affected, 1 warning(s): 1196 Some non-transactional changed tables couldn't be rolled back I checked the tables and my change to the message table wasn't rolled back but my change to the users table was. So then I did the same test except I didn't update the messages table and when I did the rollback I got no warning message and the users table was rolled back. So from my very basic testing I would say if you wanted to you could use transactions against the forum database as long as you didn't perform any updates against the messages table expecting to be able to do a rollback. But back to the original question, the forum database would not support transactions because of the messages table being MyISAM. Although it looks like MySQL will not stop you from trying. :-)

This is my take on the question and maybe Larry will come back and tell me how wrong I am. But the forum database contains more than just the forums table, it also contains the messages table which is defined as MyISAM. The question reads why doesn't the forum database support transactions? I would answer because the database itself contains the messages table with the engine MyISAM. Just my two cents.

Finally figured out what the deal was with this. I had to modify my php.ini file to add the -t option at the end of the following line: sendmail_path =/usr/sbin/sendmail -t

In addition, I have a feeling this is a configuration issue with sendmail, not so much code related.

This really isn't PHP related, but I was wondering if anyone else got the following message when trying to send email from a PHP script such as the one in the register.php in Chapter 18? I am trying this on a Mac running Mountain Lion. I have been searching for a solution with no luck so far. This message is from the mail.log file on my machine. postfix/sendmail[15136]: fatal: Recipient addresses must be specified on the command line or via the -t option Thanks in advance for everyone's help. Dan

Yep...I saw the solution in the error messages but wanted to figure it out myself instead of asking the forum. :-) Larry may have mentioned this earlier in his book, but I did upgrade to Mountain Lion halfway through this book and that resets all the PHP.ini settings as well as Apache settings. I may have set this before in the PHP.ini file and have since forgotten it until now. I did end up just using the date_default_timezone_set() function and it worked like a champ. I will likely have to go back and review my PHP.ini file settings now. Thanks again for your assistance.

Thanks...I have done it and got the following exception. Like I said before, this is with Larry's code which I find surprising. :-) I will take a crack at debugging this one now. Thanks for the suggestions. Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CDT/-5.0/DST' instead' in /Users/DJ/Sites/PHPandMySQL/chapter16/datetime.php:20 Stack trace: #0 /Users/DJ/Sites/PHPandMySQL/chapter16/datetime.php(20): DateTime->__construct() #1 {main} thrown in /Users/DJ/Sites/PHPandMySQL/chapter16/datetime.php on line 20