one more shopping cart advice needed

itworks

i'm developing a shopping cart with all features even an administration area, and it's almost done but i still need one or two more things solved.

i appologize for all this trouble but i'm new to this php thing (i only began about 2 months ago) and i'm sure you'll help me with your knowledge and patience.

my question is about the last fase of the shopping online feature (to make the order), till now i made the functions for adding item, seeing the items in a little box, seeing the detailed cart, erase an item, change the quantity of an item, etc.

i'm using a mysql database with some tables, one of those tables is the cart (temporary) that has this structure:

email (username)
cod (product code)
qte (quantity of the item)
type (type of product)
model (model of the product)
price (price of the item)
id (an auto_increasing number)

(these data is being called from variables)

each item goes into a separate row in the table, what keeps them trackable is the email (username).

now in the cart page with the details i have a submit button to checkout (order).

what's the best way to make that order?

1-transfer the items of that user to the orders db table and erase them from the cart table? how do i group them to be part of the same order?

thanks in advance.

fenrir

hmm, one of the problems I see you running into is this, what happens if the same user makes multiple orders? If the order is grouped by the username then each order will add onto the last. You need to get a unique number associated with each order and tie that into the products bought

itworks

yes that is exactly my problem, how to group the items in just one unique order?

any thoughts in what's the best way to do this, how is this usually done?

daedlus

Just get php to generate a "random" number that 10 numbers long, as so:

substr(md5(time()),0,10);

That will generate a fairly random number, considering it's dependant on the time variable. You can use that and write a function that makes sure the numbers never repeat on a per user basis, or just make an auto-increment field that starts at 1.

So he'd order, order-id would be 1, and the next time he'd order it'd be 2. Not very impressive and kinda low-tech, especially if you plan on displaying the number, but still, it works, it's reliable, and it'd be hard to break. So I suggest using that.

For the transaction, I suggest you make sure you database isn't all MyISAM tables as they are fairly insecure. Instead use the InnoDB or even Gemini if you have access to it. BerkeleyDB is also good but since it's not as widespread support is less than optimal. Also the tables are not "really" optimized for transactions. My suggestion would be InnoDB.

How you will interface with some sort of credit agency or bank is beyond me. My guess would be to call up a big bank's headquarters and ask to speak to somebody in the IT department. They should know SOMETHING about interfacing with a bank since they are sorta working for it's IT department.

Apart from that, code, recode and make sure it's 99% bug free before releasing. I wouldn't put 100% because it's never perfect, but make sure you test it against a wide variety of computers, browsers and hack tools. VERY IMPORTANT: DO some infiltration testing. I cannot stress this enough. Get somebody to try and break in and mess EVERYTHING up, or to make a false transaction.

Before launching any application that will have money as a turning point you must make sure it's secure. Get somebody you trust to look at your code, and get them to try and break in. If they know how it's coded and they can't, you can be fairly sure it's safe (or that they can't infiltrate anything, but that's besides the point). The other people that WOULD want to mess everything up won't have a copy of the source-code on hand, unless it's GNU, and then it's a whole other ballgame.

Regards,
Daedlus

itworks

thanks a lot daedlus for all your advices, i must say that for payment methods i will only use money on delivery fot this specific project so that pretty much simplify it.

as for the type of tables i'm uding MyISAM 'cause i didn't knew about all that.

but besides all that, the problem i need advice with is still unanswered.

what's the best way to make this last checkout function?

how do i store in the orders table all rows that a certain user has in the cart table when he makes the checkout, how to group them to be part of the same order so that it doesn't become messed if a user makes two orders in one day?

thanks in advance.

daedlus

Again, I'm not certain how you'd go about to automate the process for the backend people, but I suppose you could set up a little php site that would notify you when a new order is in, and you'd have a GUI that'd let you select each order and check some sort of a "done" button, so when you send them, you tell the SQL database that it's been done and not to show this order again.

The worst thing you could POSSIBLY do is start deleting the orders when they are done. That would be very extremely horrible because you need some sort of proof that you in fact recieved the order and that you sent it, because shit happens.

The page I was talking about earlier, you could set that as an active desktop that refreshes ever 10 minutes or so, so that you'll always know when there are new orders. Your best bet for the whole database thing is make another table, that'll be just for determining which orders are done and which are not. You have to put a unique key for each order and refer back to that key through this table. My guess would be 2 rows, the order id, and the done row. As long as the done row is NULL, then you know the order is not done, and so does MySQL. It can then parse all the appropriate data using the order ID and dump it into a nice little form so that you could see what the order is and so on.

That's how I'd do it, but I'm not the best of the best, so others might have better ideas than mine. Anyways, hope it helps!

Regards,
Daedlus

itworks

that's not the way i intended to do it.

that's why i built two separate tables, CART (temporary, to store the items added) and ORDERS (to store the items that the user really want's to buy when he clicks the ORDER button).

the functions are all done, the only one that is missing is the one that formalizes the order. i'm not thinking of deleting the items just like that, they will only be deleted from the CART table after being stored in the ORDERS table, and a confirmation will be echoed to the user.

my problem rezides in the function, how to pass the items in the CART table into the ORDERS table and somehow group them to let the administrator know those items belong to the same order ('cause people can make two orders in one day, so the date doesn't solve the problem) and then after this transfer is done, delete the items from the CART table, this is what i really need help with

anyone has an idea of what's the best way to do it?!

thanks in advance.

daedlus

oooooh ok, I see what you're getting at. The way I'd do it is when the user clicks the "order" button, after having given all his contact info and whatnot, I'd have it parse the order, in the exact same maner that you'd do to display the order, except with all the rest [order id and so on], and

INSERT INTO orders (all your orders table rows here) VALUES (all the values from CART here);

Depending on how you do it you might need to use UPDATE after each order, but that's just a question of how you do it. Basically, you parse all the information from one tables into an array, and you dump all the data in the array into the other table. I don't think that is a direct means of interfacing 2 tables, but I might be wrong, I'm a little rusty on this, I've been mostly doing flatfile these days.

As for your order id, make an auto-increment field in the CART table, so that each time somebody starts a new cart it increments by 1. Of course they might not order, so your order id might climb like krazy, but that's besides the point. The point is to have a means of identifying each order with a unique identifier. This should work fine.

order_id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT

that's what I'd use as a table field.

That's what I'm thinking. I hope this helps, what little it might, and I really hope your shopping cart application works. Those apps seem to be selling like hotcakes these days, especially the modular ones with the admin interface.

In any case, hope that helped, if not, feel free to message me @ thedaedlus@hotmail.com.

Regards,
Daedlus

daedlus

By the way, in case you were wondering why I didn't just write the function and stuff, it's just because it's kinda hard to code something when I don't know how it's all set up. If you want you can show me what values go into each table and I can attempt to code something that will resemble what you want.

But I think it'd be better for you if you actually did it yourself, it's more rewarding in the end when you can say, "Hey, I made a PHP shopping cart that uses a MySQL DB all by myself". At least you didn't have to learn like I did, lol, on the fly with about like 3 days notice. That was a laugh.

Anyways, I hope I'm not too anoying, I know I sometimes stray from the point a little, but it's better to put too much than not enough.