Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Content Count

    5143
  • Joined

  • Last visited

  • Days Won

    142

Larry last won the day on December 18 2018

Larry had the most liked content!

Community Reputation

421 Excellent

About Larry

  • Rank
    Administrator/Writer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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"!
  7. This may be related to your PHP version. What version are you using?
  8. 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.
  9. 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.
  10. 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?
  11. The newline affects the HTML source code of the page. It's visible there, not in the visual result rendered by the browser.
  12. 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...