Shopping cart - how to pass value from select menu

ade234uk

I have created a basic skeleton for my shopping cart.
As well as listing the product you can also add product options.

For example the Football can be bought in two colours either Red or Orange
If you select the Red ball it costs £10.00 more
If you select the Orange ball it cost £15.00 more

My select menu is set up as follows. The information is extracted from the database

echo "<option value=\"".$row['product_option_price']."\">".$row['product_option_name']."</option>";

So it looks like this when you view as source
<option value="10.00">Red

Now this is the tricky bit.
When the product is added to the cart via a select menu I need to add the price to the delivery field, which I can do but I also need to display what colour they selected

At the moment, as it is a select menu it is only passing the Value for example if I selected the Red Ball then 10.00 is passed to the cart.

Do you have any ideas how I can also display what they selected so the cart page looks like this

Football
Option: Red

I hope this makes some sort of sense.

etully

Building a shopping cart is an excellent way to learn about PHP programming. One of the best.

And I'm sorry to be the one to tell you this but it's a good project because it will help you learn to avoid security mistakes like the one you're making right now.

When you build that form and send it across the Internet to be displayed on the user's screen, you are putting it in their hands. They can do anything they want with it. You hope that they are going to simply VIEW it in something like Internet Explorer, Firefox, Opera, or Safari but you don't know that they will. (True, the average person will.) But a thief isn't going to use a web browser. They're going to use a text editor like Notepad, Dreamweaver, or some other such tool. And they can change anything they want in your form. And then open it in a web browser and post it back to you and your server won't know the difference.

So they could change that 10 to -10 if they wanted. Now you'd owe him money.

And let's forget about the security hole for a second...

How could you possibly know which color football he wants? If the only thing that comes through is "10", you'll have no way of knowing whether he wants the green or the red football.

So here's the right way to do it. This solves both problems by the way.

echo "<option value=\"".$row['product_option_code']."\">".$row['product_option_name']."</option>";

So every product option gets a code. Blue is "7". Green is "11". Whatever you want. Instead of passing the price, you pass the color code.

Now if the thief wants to get clever and change the number from a "5" to a "3", the only thing he's accomplished is to change the color of his football!

And since your server will know that he wants football color #7, your script can look that up in the database to find out what color #7 is and display that color on the invoice.

And lastly, since your server will know that he wants football color #7, your script can look that up in the database to find out how much this color adds to the cost of the football.

You can never never never trust data that comes from the client side. For example, if you set a cookie with their userid, the cookie exists on the user's side. When the user visits your page again and the cookie gets passed in, you can't trust it.

Imagine a real life example: You walk into a bank and open an account. They banker says to you, "Your PHP-Bank Secret Account Number is 1111111". So you come in the next day and say, "I'd like to withdraw $100". So the banker asks you your PHP-Bank Secret Account Number and you say, "2222222". So the banker hands you $100 and deducts that amount from account 22222222. The banker thinks he's secure because nobody has ever heard of a "PHP-Bank Secret Account Number" before and he assumes that nobody will figure out that they can lie when they are asked for their number. That's not real security.

ade234uk

Of course that's how you would do it. If I assign the options numbers like you suggest then

1) It will keep the basket secure
2) And also sort out the problem I faced.

Thank you very much for your help and for your security advice.

ade234uk

I implemented what you suggested and now I can see how to create product options but most importantly how to keep it secure.

Just one last question. How would I call two drop down menus for a product. For example I might be selling shoes so the user would need to select

1) Size
2) Colour

I dont want any code solutions as I want to learn, I would like to know how you would and can go from there.

Many Thanks

etully

Excellent question. The way I handle it is to create a fairly complex table structure.

One table is a list of products. (you have that)
One table contains a list of different types of attributes.
One table contains a list of which attributes a product has.
And one table contains a list of values that go with an attribute.

For example, here are some sample data for each table:

Products
-----------------------
ID:  1,  tshirt
ID:  2,  computer
ID:  3,  pants

Attributes
-----------------------
ID:  1,  Color,    type:  drop-down
ID:  2,  Size,     type:  radio-button
ID:  3,  RAM,      type:  drop-down


Product_Attribute_xref
-----------------------
product_id:  1,  attribute_id:   1     (t-shirt has color)
product_id:  1,  attribute_id:   2     (t-shirt has size)
product_id:  2,  attribute_id:   3     (computer has RAM)
product_id:  3,  attribute_id:   1     (pants have color)
product_id:  3,  attribute_id:   2     (pants have size)

Attribute_values
-----------------------
attribute_id:  1,   value:  red      (one color is red)
attribute_id:  1,   value:  green    (one color is green)
attribute_id:  1,   value:  blue     (one color is blue)
attribute_id:  2,   value:  small    (one size is small)
attribute_id:  2,   value:  medium   (one size is medium)
attribute_id:  2,   value:  large    (one size is large)
attribute_id:  3,   value:  500 MB   (one RAM Amount is 500 MB)
attribute_id:  3,   value:  1 GB     (one RAM Amount is 1 GB)

When someone views a product, you will need to see which attributes it has. Then when you are displaying that attribute, you will need to check to see what kind of display it gets. (Drop Down, Text Field, Radio buttton.) Sometimes attributes cost extra. It's usually best to put those in the Attribute_values table. For example, red, greem and blue would get $0 because color doesn't cost extra but the RAM might get $50 for the 500 megabytes and $75 for the one gigabytes.

Now, when someone puts something in their basket, you will not only need to keep a record of what they put in their basket but you will also need to record which options they chose. This isn't enormously difficult, and it's a great way to learn to use a database (I applaud your initiative here). One tricky part is that if they have a large blue shirt in their basket already and they add another large blue shirt, you shouldn't create a new item in the basket but you should merely increase the QTY of the first large blue shirt by one. If they then add a medium blue shirt to their basket, you should not increase the QTY but instead add a new product to the basket.

You will need a few different tables to record what people have put in their baskets and what options they have chosen on their attributes. I suggest that you design that table structure out on paper before you attempt to program it. You might even want to get some opinions on it first too.

etully

Oh, one thing I forgot to mention:

Notice that I re-used the color attribute on both shirts and pants. The idea is that you can create one attribute and maybe use it on lots of different products. This way, if you find that you sells lots of items that all have the same attributes, you can create the attribute once and use it over and over.

If you found that you sold toy cars and they had a color option but it was not the same color option as the clothing, then you would need to create a different color attribute. So instead of having one attribute called Color, you would have two attributes called Color (yes, they can have the same name since they have different ID numbers). But color (with an ID of 1) gets matched to a list of colors that are available to clothing. And color (with an ID of 4) gets matched to a list of colors that are available to toy cars.

This works well for some stores where the attributes are re-used for lots of different products. (I work for a print company and lots of our products can choose from the same list of papers and the same list of inks).

A computer store is another good example of something where the same attributes get used over and over and over. (Ram, HD, CPU).

Other stores might not have ANY two products that share the same attributes and in that case, it might not make sense to have a table of attributes. It might make more sense to define a specific list of attributes for each product. So for example, EVERY SINGLE TIME you add a new product, you have to create attributes for it and create values for those attributes even if you've made that attribute before for a different product.

ade234uk

Thats brilliant. Thank you very much. I am going to have to print your tables example off, for reference.

I am sure this is one of those things that stumps people when they create their own shopping cart.

I think some shopping carts out there become to complicated. For instance oscommerce is a great cart, however there are two many options on there these days, and it misses the point of creating a simple shopping cart.

All you need to be able to do is

1) List your product
2) Upload 4 photos if you wish
3) Add your options
4) Add your price

And submit.