Larry

Okay. Glad it's working for you and thanks for sharing what you learned.

Printing is a feature of the browser (i.e., it's a client-side thing). PHP does not apply to that concept because PHP is server-side. So you can use PHP to create a dynamic Web page, but then the user goes ahead and prints the page using their browser (you can use JavaScript for a shortcut to the print menu selection). As for your second example, yes, PHP can do that. I'm not sure you'd want to, though.

You can store a file in the database using the BLOB data type. You can reveal it using a proxy script. Printing isn't a PHP issue.

I don't regularly use Windows, so I've never pinned the MySQL monitor to the taskbar (I don't really know what that means), so I couldn't speak to this. Sounds like it may be a bug in the Zend Community Server.

Okay, not to belabor the point, but you need to know, for certain, the full and exact versions of PHP and MySQL in use. Without a doubt, this is the most important thing one should know before using PHP and MySQL. Fortunately, it's easy enough to find this data out. As for that error, it's not a connection problem. The user you're connecting to MySQL as does not have EXECUTE privileges.

Quotes aside, both of those queries are very, very bad, as they allow for SQL injection attacks.

Ryan, First, I'm going to say again, per the forum rules, you need to start including your basic information (such as PHP and MySQL version) if you want help. Second, to be more explicit, take this line in the original code: //if (!$r) echo mysqli_error($dbc); and turn it into: if (!$r) echo mysqli_error($dbc); That way you'll see the error immediately after executing the stored procedure (if the stored procedure failed). What you did was just remove that line, which isn't helpful at all.

Your stored procedure isn't working. Uncomment the debugging line to see why. Also, per the forum rules, you should be including the versions of PHP and MySQL in use.

I wrote about this in this thread in the old forum: http://www.larryullman.com/forum/read.php?24,50607

I'm not sure that I follow why you couldn't just use PHP to pull the data from the database and populate the text area directly, without Ajax or any magic.

For starters, you can also check out this thread: http://www.larryullman.com/forums/index.php?/topic/450-there-is-no-php-6-version-why-then-does-this-book-has-php6-as-title/ The only part of the book that requires PHP 6 is about half of Chapter 14. And that functionality can now be done in PHP 5.3, depending upon your setup. However, you may want to decide whether you need some of that ability before making any big changes. Thanks for the nice words on my work!

You can execute a stored procedure from phpMyAdmin, but the support for it is inconsistent, depending upon the version of phpMyAdmin, PHP, and MySQL. I've posted instructions in another forum thread (forget where offhand), but, the short answer is that it's inconsistent and other interfaces are better for this purpose.

Sure thing, Alex. This is what I meant... Here's the key code from view_settings.php: <style type="text/css"> body { <?php // Script 9.2 - view_settings.php // Check for a font_size value: if (isset($_COOKIE['font_size'])) { print "\t\tfont-size: " . htmlentities($_COOKIE['font_size']) . ";\n"; } else { print "\t\tfont-size: medium;"; } // Check for a font_color value: if (isset($_COOKIE['font_color'])) { print "\t\tcolor: #" . htmlentities($_COOKIE['font_color']) . ";\n"; } else { print "\t\tcolor: #000;"; } ?> } </style> So to get that to work in customize.php, which also needs to be aware of the posted form, the code would be: <style type="text/css"> body { <?php // Script 9.2 - view_settings.php // Check for a font_size value: if (isset($_COOKIE['font_size'])) { print "\t\tfont-size: " . htmlentities($_COOKIE['font_size']) . ";\n"; } elseif (isset($_POST['font_size']) { print "\t\tfont-size: " . htmlentities($_POST['font_size']) . ";\n"; } else { print "\t\tfont-size: medium;"; } // Check for a font_color value: if (isset($_COOKIE['font_color'])) { print "\t\tcolor: #" . htmlentities($_COOKIE['font_color']) . ";\n"; } elseif (isset($_POST['font_color']) { print "\t\tcolor: #" . htmlentities($_POST['font_color']) . ";\n"; } else { print "\t\tcolor: #000;"; } ?> } </style> Note that there's an error in the prompt, in that the form uses POST, not GET. Let me know if you still have questions about this.

I installed it on 64-bit Windows 7, too. As for your error, can you get to the XAMPP Web start page without a problem? If so, what's that URL for you?

In theory that's correct, except that forces PHP to typecast the value to a PHP integer and a PHP integer may be smaller than the actual number, as you're seeing. If you use "s", for string, no PHP conversion will occur and the original value will be maintained. What you're doing would seem to be appropriate, but there are behind-the-scenese complications.

I'm only sure in that I went to the XAMPP Web site and it says that the installer requires Mac OS X 10.4.

I suspect the problem is that your prepared statement is not using the proper identifier for the data type.

Okay, looking more closely at what you wrote before, you have a repetition of the same two lines. So you need to fix that. Here's how you would enforce SSL for a specific file: RewriteCond %{HTTPS} off RewriteRule ^checkout\.php$ https://%(HTTP_HOST)/checkout.php [R=301,L] Also, there's a syntax error in your original code. You have another set of parentheses after "checkout.php", where it should be a | after checkout.php.

XAMPP requires Mac OS X 10.4. MAMP, what I use, requires 10.6. Your best solution, I think, would be to manually build PHP and MySQL. That's not going to be easy (at all), but is the last straw for getting a working version on your computer when no pre-compiled versions exist.

To confirm, is this all on one line in your .htaccess: RewriteCond %(HTTPS) off RewriteRule ^(checkout\.php|billing\.php|final\.php|admin/(.*))$ [url="https://%(HTTP_HOST"]https://%(HTTP_HOST[/url])/$1 [R=301,L] Because that should be two separate lines.

By symbolic logic I mean propositional logic (http://en.wikipedia.org/wiki/Propositional_logic), which is on a lower level (i.e., easier to grasp) than first-order logic. I don't know that there's a direct correlation between propositional logic and programming (there is between first-order logic and programming). But what I ascribe to first-order logic, which has aided me, is the ability to look at things rationally, without being confused or misdirected by immaterial issues. It's a valuable, but hard to teach, skill that makes debugging much easier.

I think it's a bad idea. Worth considering, yes, but definitely one to be tossed out. What you're proposing means that the site will virtually serve 40 pages of content whether the user visits one page or 40. That's bad. It's bad for the server and it's bad for the user. For starters, it'll take that much longer for the user to load the initial page. Then, the memory requirement will be exponentially larger than it should be. This is just a bad idea (in case I wasn't clear as to my thoughts on this). To me this strikes as one of those cases of "just because you can do X doesn't mean you should do X". By comparison, if you had a site with a series of pages that are read sequentially, there would be an argument for pre-loading the next page in the series. That's a valid example of loading content that the user might never see, but I'm talking about loading one more page, not 39 more.

You don't need to worry about this function's level of support. It's been available for years and will continue to be. The MySQLi_STMT::insert_id() reference just means that the insert_id() method is part of the MySQLi_STMT class.

Thanks for the nice words on the book. Much appreciated. Yes, the variable assignment will occur first and you're correct in thinking that if $var is assigned an empty string or 0, the conditional will be FALSE. More importantly, it will still be a bug, which is the point I'm trying to make by that particular prompt.

Yeah, I expected that was going on. Kudos for figuring it out and thanks for posting your solution.