Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Content Count

    5158
  • Joined

  • Last visited

  • Days Won

    143

Posts posted by Larry


  1. 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!


  2. 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. 


  3. 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. 


  4. 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. 


  5. 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.

×
×
  • Create New...