Larry

I don't know where those values are coming from! I'd just search through your code to see where you might have defined them more than once.

Ah, okay. This is definitely do-able, but not simple. To start, you'll need a way of reflecting sizes for non-coffees. An option would be to replicate the coffee database structure. Note that if somethings might have multiple sizes and other things might not, you'll need to account for that. For the automatic price change, you'll need to use JavaScript. When the size selection changes, the JavaScript would fetch the information for that size from another PHP script (using an XHR request). Or you could do some sort of logic where the display PHP stores the new price as metadata on the menu and then the JavaScript parses that out. In either case, you'll need to use JavaScript. For the product details page, follow the specific coffees page as a model, passing along the specific product ID and then fetching it from the database. For the shopping cart with a sized product, just replicate what's being done with the coffees. Let me know if you have any more questions and good luck!

Hmmm...this is the kind of thing that may change in different versions of MySQL. Nice work switching to using the + INTERVAL syntax, though!

Could you confirm what the FULL URL is with Books & DVDs?

Yeah, this looks like a UTF issue. I'd make sure you have all that squared away, both in the database definitions and in the connections. Switching to English only may work but it entirely defeats the purpose of what you're trying to do here!

Try escaping the % sign. That's often the solution in situations like this, where a character may have special meaning.

The table structure I have in my SQL file is CREATE TABLE `specific_coffees` ( `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT, `general_coffee_id` tinyint(3) unsigned NOT NULL, `size_id` tinyint(3) unsigned NOT NULL, `caf_decaf` enum('caf','decaf') DEFAULT NULL, `ground_whole` enum('ground','whole') DEFAULT NULL, `price` decimal(5,2) unsigned NOT NULL, `stock` mediumint(8) unsigned NOT NULL DEFAULT '0', `date_created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `general_coffee_id` (`general_coffee_id`), KEY `size` (`size_id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; where specific_coffees has a size_id column.

Excellent. Thanks for letting me know and kudos!

With XAMPP on Mac OS X, the root MySQL user password should be "root". If not that, then it's nothing (no password), which is totally fine while just starting on a local machine.

The first edition is 9+ years old right now, so I'm not sure you should use that version of Zend, even if it's still available. It looks like Zend Mail is now installed via Composer: https://docs.zendframework.com/zend-mail/ Code examples for the current version of Zend Framework can be found here: https://docs.zendframework.com/zend-mail/message/intro/ Let me know if you need more help updating the book's example for the current version of ZF.

Ah, sorry for the confusion. By putting fwrite() as the condition, it'll always be executed when the write() method is called. The condition then reacts based upon the result of the fwrite() call. Put another way: the fwrite() call is not being conditionally called; it's always called.

I cannot give you any better answer without knowing how it's not working. What is it doing that it shouldn't be? What is it not doing that it should be doing? What debugging steps have you tried and what were the results? Just posting code and saying "I'm still having trouble to make it work" doesn't provide sufficient information.

The "undefined offset" means you're referring to an index position that doesn't exist. In this case, there is nothing at $response_array[3]. You should look at what $response_array is--what values it has indexed at what positions--and what you're actually trying to do to figure out what the right change is.

You can use the uniqid() function for this: https://www.php.net/manual/en/function.uniqid.php

You probably shouldn't store the image itself in the database unless you plan on having some multi-server set up. I'd recommend storing the image name in the database and storing the image itself on the server.

Ugh. I can see what you mean. There's no way to do this as far as I know. Sorry!

Yeah, I can appreciate the frustration. For what it's worth--and I mean this in a helpful way--it does seem sometimes that you're trying things to see if they work without really thinking through the implications or full ramifications of the change. That's going to be problematic. It's not uncommon as people are learning, but it's not ideal. I have found--especially while writing books--that verbally explaining to myself what the code does often illuminates the problem. Search for "rubber duck debugging"! So in this particular situation, the behavior you're seeing has nothing to do with the session_start() line and everything to do with how browsers behave. The URL http://localhost:8888/cart.php?action=add&sku=C11 adds that item to the cart. Every time you go to that URL it's going to add that item to the cart. This includes clicking the back button, which is you telling the browser to revisit that page. The back button is not going to send you to http://localhost:8888/cart.php because that's not the previous page/URL. There are two obvious ways to change this behavior: 1. Have cart.php redirect the browser to http://localhost:8888/cart.php after updating the cart. This way the URL http://localhost:8888/cart.php?action=add&sku=C11 is never part of the browser history. This is the route I'd take. Keep in mind cart.php can only do a redirection upon a change or else you'll create an infinite loop. 2. Make cart updates be POST requests instead of GET. This is easier but unseemly. Now going back a step, if you think about what session_start() does, you'll see it's not the cause of the problem. session_start() only starts a session. It's required to have shopping cart functionality but there's absolutely nothing in session_start() that's going to affect the shopping cart contents at all.

Conventionally, I make every page call session_start() once by invoking that line in a common file included by every page. This could be a configuration file or a dedicated file for handling session activity.

That seems to make sense!

Right, if you're using session_destroy() it's going to destroy the session, which is not what you want. What you want is for every page to call session_start() once. If all pages include the configuration file, that should suffice.

I'm not quite following what you're saying. In point 1 you say the cart is HTTP and the checkout is HTTPS. In point 2 you say they are all HTTP. Could you clarify what the reality is where you're seeing this behavior?

You're probably losing the logged in status b/c you're going back and forth from HTTP to HTTPS. If it's all HTTPS you probably won't have that problem. As for remaining logged in, it depends upon whether you're using cookies or sessions but it's just a matter of extending the duration of whichever accordingly.

Off the top of my head and given the information provided I can't think of an obviously easier way. There's a lot to be said for "this works"!

This may be related to your PHP version. What version are you using?

The key to figuring this out is remember that if multiple radio buttons have the same name, only one can be checked. So just write your code to create the proper names based upon the restriction you want to put in place.