Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Content Count

    5220
  • Joined

  • Last visited

  • Days Won

    143

Everything posted by Larry

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. 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"!
  8. This may be related to your PHP version. What version are you using?
  9. 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.
  10. 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.
  11. 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?
  12. The newline affects the HTML source code of the page. It's visible there, not in the visual result rendered by the browser.
  13. 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.
  14. If you're getting a 404, your PHP code is probably fine and it's the Apache configuration that's the problem. In other words, given this URL, Apache doesn't know what page to serve. It looks like your regular expressions are incorrect. You seem to be using the same matching pattern for all three conditions and that pattern doesn't match /our-furniture-test/beds/20/5/.
  15. I don't quite follow why you would print the same database value in three different radio buttons. Radio buttons are normally used to select one item from a group of items with different values. I also wouldn't use array syntax for the radio button name. You'd only want to do that for something like SELECT menus or checkboxes where multiple values can be selected or checked.
  16. First, to be clear, the behavior has nothing to do with DIVs (or PHP for that matter). It's simply how radio buttons work in HTML. I'm not quite following what you're trying to do, though. Maybe you should be using checkboxes instead? If you could explain the scenario in more detail I can give more specific advice.
  17. It's probably either a problem with your certificate or your server configuration. What operating system and web server are you running and how did you install and configure the certificate?
  18. Thanks for the nice words! As for this situation, first of all, congrats on the growth of your site! I've not done this particular thing before, but my inclination is to start by thinking about what variables would exist. You'd always have $current_page and $total_pages. I think I'd then add a $show variable, for the number of additional numbered links to show (e.g., 2 gets you 4 5 6 7 8). Then the logic becomes: If $total_pages is greater than some figure (maybe $show * 4?), don't loop through every page number. And then... If there's more than $show pages between 1 and $current_page, do "FIRST...". And also... If there's more than $show pages between $current_page and $total_pages, do "...LAST" I'm not sure if that's everything but off the top of my head that should get you going in the right direction! Let us know how it goes or if you have more questions!
  19. Thanks for the nice words on the book! I don't quite follow what your goal is here, however. Could you maybe start by explaining the end result you're working towards?
×
×
  • Create New...