Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Content Count

    5203
  • Joined

  • Last visited

  • Days Won

    143

Everything posted by Larry

  1. 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.
  2. Excellent. Thanks for letting me know and kudos!
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. You can use the uniqid() function for this: https://www.php.net/manual/en/function.uniqid.php
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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?
  14. 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.
  15. 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"!
  16. This may be related to your PHP version. What version are you using?
  17. 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.
  18. You don't say how it's not working but my guess is the problem is b/c you're hard-coding the PDF application type in there. The content-type header indicates to the browser what type of file to expect. If you say to expect a PDF but send a Word doc, that's not going to work.
  19. So the problem is that you're still viewing an HTTPS page when you don't have HTTPS enabled. I assume it's because of the .htaccess. Did you restart the web server after making the change?
  20. The newline affects the HTML source code of the page. It's visible there, not in the visual result rendered by the browser.
  21. Ah! Then if you haven't acquired a certificate, your HTTPS links won't work. Change them to HTTP. I wouldn't worry about a certificate for now--and certainly don't purchase one yet.
×
×
  • Create New...