SaranacLake

Well, I have to think about that, and I suppose that is one reason I posted here... There will be several tables that need to get populated in order for the checkout to reach a final state. The question again is, "Should I make it all-or-none or allow a partial checkout and then allow the user to go back and try again?" It seems to me that in the past n PHPFreaks, people encuraged me to create the Member record at all costs so that I had some way to reach out to people via email or whatever in case of a failed checkout. (I think that makes sense.) And if I had to guess, I probably need to wrap things like "Order" and "Order Details" into a transaction, because you cannot have an "order" if you haven't been paid - at least not with my business model. Likewise, you cannot have a 'paid subscription if you haven't paid me, so I suppose any tables related to that should be in a transaction too. But I welcome any thoughts from the PHP gurus here! 😉

@kicken All good advice, but I still worry... Good point. Yeah, that is sorta what I was hinting at in my OP - that hopefully having to change indexes or even keys after you go-live isn't the end of the world. In my mind, what is the most important is that you capture the right data and have the right relationships. For example, if you don't store "Order History", then later on you can't re-create it out of thin air?! And if you didn't have an "Order Details" table, but instead hard-coded 10 slots in your "Order" table, assuming no one bought 11 items, you would be safe, BUT you'd have a real mess to clean up later on!! Let's hope you are right about the "fatal" part!!! Well, hopefully i am at that point in my design where all of this is true. (Although I did find one problem area last night that I need to quickly re-work, but other than that, I think my database design is solid...) Thanks!

@requinix I have designed the "shopping cart" to be a database record regardless of whether a person a first-time shopper and doesn't have an account, or the person is a repeat customer and has an account. (I think most people just use cookies, but I've never really liked or undestood using cookies.) So the moment a person chooses "Add to cart", things should get written to the database to provide some permanency. Well, the process I described in my OP was "piecemeal", and I chose to create the Member record first since it is a parent table that kind of drives everything else, so I didn't want to lose that, plus I need that before I can add things the Order and Order Details. I could wrap the entire process in a database transaction, but then the question becomes, "Do you ant an all or none approach, or is it better to at least capture some info like creating the Member record?" I'm not sure of the best answer to that. Sounds like you have some thoughts... xxxxx

This is part PHP, part MySQL question, but since I'm more interested in the process-flow, I'll ask here. I am ready to start coding the e-commerce module of my website, which features mostly paid subscriptions. Do the below steps sound like the correct sequence to do things in... - Anonymous shopper adds subscription to Shopping Cart - Shopper goes to check out - Shopper completes checkout form which includes setting up the account and entering payment details Now for the important stuff... - System takes Shopping Cart details - which include the PHPSessionID - System creates Member record - System takes Shopping Cart details associated with PHPSessionID and links them to the new Member record - System creates Order and Order Details records - System runs the payment - System hopefully gets back a "success" message from Payment Processor - System activates the Member's account How does that sound at a high-level? Really what I'm trying to validate is if I should create the Member record 1st, then create the Order records 2nd, and worry about the payment last. (Originally I was going to run the payment first, but I'm thinking it's better to capture the anonymous shopper's details in a Member record and Order records first, because even if the paymnt fails, you want something to work off of - like reaching out to the person and getting another valid payment.) Thoughts?

So I am reviewing all of the pages and pages and pages of ERDs that I have, and hope to start building things in MySQL tomorrow. Those of you who know me, understand that I'm terrified of making some gigantic mistake on my website, and so I often tend to fret longer than necessary?! In abstract terms, where would you say people most commonly get into trouble when building databases from the ground up? Or put another way... What kind of database design mistakes tend to be "fatal"? My hope is that as long as I've included all of the necessary tables, and as long as I have things normalized (or denormalized where necessary), that everything else should be relatively easy to fix - for example changing data-types, adding/removing a few columns, changing indexes, etc. Thoughts on this?

@requinix Okay, thanks!

@requinix Okay, good to know. Okay. That being said, and knowing that I will be querying on Orders and Order Details, and knowing that I need a FK on Order_ID and Product_ID, then it sounds like you are suggesting that I create one index on {Order_ID, Product_ID) and then my second index simply on (Product_ID), correct? ...

@kicken Hello. I wanted to get clarification on something we discussed a few months ago regarding FKs and Indexes... Let's say that I have a typical order system with these tables... ORDER - id (pk) and so on... PRODUCT - id (pk) and so on... ORDER_DETAILS - id (pk) - order_id (FK1)(UK) - product_id (FK2)(UK) and so on... A few things I recall you saying to me... - MySQL requires an index on all FKs. - Indexes work left-to-right, and so any column that needs to take advantage of an index needs to be in the 1st position when multiple columns are in the index. - If querying by Orders is more common, then I would want a FK like this: (order_id, product_id) - I would need another index for product_id. Question: 1.) In order to create an index for the Product_ID FK, and to provide for possibly querying on Product_ID, could my 2nd index be (product_id, order_id)? Having (order_id, product_id) and (product_id, order_id) indexes would help with my two FKs, and all me to query by either Order or Product. This seems like the best of both worlds, without a lot of overhead from unnecessary indexes. Thoughts?

@maxxd Told you I was rusty on things!! So there is still a lot of application logic I have to figure out, but it sounds like upgrading to the HTML5 button tag should help me to address any situations where I need to have several command-type buttons on one web page, right? And another advantage is now I can just have one form, right?

@maxxd My var_dump isn't displaying anything. Then I rewrite my code, tried this, but when I click on a button I don't get any results... <?php if ($_SERVER['REQUEST_METHOD']=='POST'){ // My code... var_dump($_POST); // Maxxd's code... $option = $_POST['option'] ?? ''; if ($option) echo "You chose $option<hr>"; } ?> <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Sample</title> </head> <body> <form> Select an option <button name="option" value="1">Choose me</button> <button name="option" value="2">Choose me</button> <button name="option" value="3">No, Choose me</button> <button name="option" value="4">No, Choose me</button> <button name="option" value="5">No, Choose me</button> </form> </body> </html>

@Barand and @maxxd, I haven't actively coded PHP in nearly 5 years - which is a painful place since I am trying to finish the last 10% of a very complex code-base. 😞 I added a var_dump to Barand's code to try and undrstand what was going on, but it isn't working. What did I do wrong? <?php var_dump($_POST); // Added to show data associated with button click. $option = $_POST['option'] ?? ''; if ($option) echo "You chose $option<hr>"; ?> <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Sample</title> </head> <body> <form> Select an option <button name="option" value="1">Choose me</button> <button name="option" value="2">Choose me</button> <button name="option" value="3">No, Choose me</button> <button name="option" value="4">No, Choose me</button> <button name="option" value="5">No, Choose me</button> </form> </body> </html> Yeah, I came to that conclusion last night. (This is probably why on a related page that I started working on a while back I broke things up into 3 forms on one web page.) Yeah, that's a bummer. Okay, but why didn't my var_dump work?

I'm looking at the code I added onto @maxxd 's code, and I think the problem is that I have 2 hidden INPUTs, but apparently they don't get "paired" with their respective BUTTON, and so the code is always grabbing the *last* hidden INPUT which is not what I was trying to do! ********************************************************* Stepping back for a moment... Today I was just trying to get my head back into using Form submit buttons more like command buttons, so I could figure out how many forms I might need, and then use that information to finish designing this web page. But I think what I am trying to do behind the scenes on this web page is actually fairly complex. And I am starting to think that I have come fair enough along on mocking up my new web pages, and I should just dive into writing all of the PHP logic behind them?! There is no sense wasting time on a page like this - whether it be the HTML/CSS or the PHP when I am losing site of the larger busines problem that I am trying to solve, if you follow. I just know that I feel even more rusty with my HTML/CSS, so I thought I'd mockup all of the pages in this last module, and then code the backend stuff, but I think I've come far enough along and at this point it would be easier to just follow my use-cases and code along various business flows if that makes sense?

@StevenOliver I appreciate your suggestion, but to be honest, I'm not sure that is the best way to do things. I believe NAME should be treated like a variable and VALUE as the value assigned to NAME. You are in essence putting values into NAME instead of variable names into NAME. In addition, I am looking at my particular case, and starting to think this is a lot more involved than I originally thought... 😞

I am soooo rusty on coding HTML and PHP... 😞 Well, to be more precise, I believe that NAME is life a variable name in the $_POST array, and VALUE is the value you put into that variable. So if you have 4 INPUTs and they each had a different NAME but with them all having the same VALUEs, then as long as you didn't need to compare values, I guess that works. True, but if NAME=MEMBERSHIP_TYPE then your approach wouldn't work if the VALUES={Silver,Gold,Platinum} But what @maxxd did was slightly different, and I'm not sure why his modified code didn't work. (It seems that "Click Me, Tree!" never gets seen...

But that is part of the problem, at least two of my buttons have the same value but should do different things, thus the reason for needing either separate forms OR hdden values that are of course unique. Maybe that is part of the code I modified above?

@maxxd, Thanks for the sample. I modified your code, but when I click on the 3rd and 4th buttons, the results are off... <?php if($_SERVER['REQUEST_METHOD'] == 'POST'){ print("<p>{$_POST['which_choice_did_i_make']}</p>"); } ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Testing</title> </head> <body> <form method="post" name="firstForm"> <button id="whatever" name="click1">Click Me!</button> <input type="hidden" name="which_choice_did_i_make" value="Form1_Input1"><br><br> </form> <form method="post" name="secondForm"> <button id="whatever2" name="click2">Click Me, Too!</button> <input type="hidden" name="which_choice_did_i_make" value="Form2_Input1"><br><br> </form> <form method="post" name="thirdForm"> <button id="whatever3" name="click3">Click Me, Three!</button> <input type="hidden" name="which_choice_did_i_make" value="Form3_Input1"><br><br> <button id="whatever4" name="click4">Click Me, Four!</button> <input type="hidden" name="which_choice_did_i_make" value="Form4_Input2"> </form> </body> </html> So why aren't things working properly?

@StevenOliver, Can you please help me figure out the proper way to use hidden input values? (If I can feel comfortable with that, then using one form is less of an issue.) Any comments on the snippet I posted earlier?

Yep. So I would just use something like... <input id="upgradeNow???" name="upgradeNow" type="hidden" value="whatGoesHere???"> I don't know Javascript or AJAX, so I'll have to let my PHP script behind the web page do all of the processing. Just out of curiosity, if you are suggesting using hidden form values, then why the need for 5 forms? (I don't mind, but just curious.)

@maxxd, Wanted to make a correction... I sketched out this web page on paper a couple of months ago, and have been busy today coding the UI part. (As such, I'm a little rusty on the logic behind it.) Upon reflection, I guess the "before" and "after" sections should logically be binary... If you land on the page before your due date, I'll still show both sections, but the "after" section's buttons (and thus forms) will be greyed out since they don't yet apply. If you land on the page after your due date, I'll still show both sections, but the "before" section's buttons (and thus forms) will be greyed out since you missed your chance! Earlier I should have said that I need to show both sections to get people to see the benefits of renewing/upgrading early. My bad!

To show the user the "before" and "after" scenarios, and encourage them to renew/upgrade early. If you didn't see that the prices were going up, why would you renew - let alone renew early? Yes, I display forms and process forms all in the same script. Okay, so there are no real downsides from a PHP standpoint... (Personally I like things compartmentalized when it makes sense.) If I go with fewer forms, could you please refresh my memory how you use a hidden field to denote which button (e.g. "Checkout" #1 or "Checkout" #2) was chosen? What is the HTML or PHP I'd need? And are there any special security considerations that I need to factor in using that approach? Thanks!

Well, if I use hidden values for each button, then in theory I could have 5 buttons in one form, right? When I mocked up a similar page earlier this summer, for simplicity, I just created 3 forms since I had "Checkout", "Checkout" and "Choose Free Gift" buttons with the last one going a completely different route, and the first two representing different products and prices. That is why I was orginally think of just adding two more forms for the "before" section which will have "Renew" and "Upgrade" buttons. So in that case I'd need to use hidden values, right? Which leads me back to my earlier question... Scenario #1: I have one form, and 5 buttons each with a hidden field so my script knows what action to take. Scenario #2: I have 5 forms, each with a single submit type button, and then it's a no brainer for my script to now what path to take. Are those choices "six of one, a half-a-dozen of another" or is one way better?

For the second section, 2 of the buttons read "Checkout" so at the very lest I need hidden fields. For the first section since the labels are different, I guess I could have two buttons in one form. What are the pros/cons of having multiple forms versus one form and multiple buttons with multiple hidden values?

Hello. I have a web page that has several operations on it, and I'm not sure the best way to design it. This is a subscription page were a user can choose different renewal plans. Before a certain date, the user can "renew" for a certain lower price (operation #1), or he/she can "upgrade" for a certain lower price (operation #2). After a certain date, the user can choose from one of three plans (operation #3, #4, or #5). The way I have things design for the "after" part is just creating a form for each one, so that when a user chooses one of them, then I can take the appropriate actions. My question is this... 1.) Is it okay to have five forms on the one web page to more clearly delineate each request/operation? 2.) Or should I create one form, and then assign a hidden form value to each button so I know how to handle the selection?

And it prevents you from losing precious thoughts! What I have learned - the hard way - is that a [ quote ] tag near the end will often slurp up uncommented text at the very end - and code too - and once that happens you cannot edit things, which is stupid. When I have a quote near the end, with text following it, I try now to cut the quote after it is in, add a few carriage returns before the ending text, then paste the quote back it, and usually that works, but not always, plus sometimes I forget and then get burned. This is a pretty big bug in the forum software if you ask me.

P.S. The way this website converts [ quote ], and [ code ], tags to an object is a real FUBAR... I had to completely re-type y last post because this is this site trashed my post. nd as you can see, the [ code ] tags are still not working?! *rolls eyes*