Shopping Cart: Commercial vs. Custom?

[leesiulung]

I finally decided to build my next site in PHP after a lenghty debate with other forum members about some of the shortcommings of PHP. That is for another discussion, but came to the conclusion that it needs a lot of improvement, but had its advantages. I frequently run into PHP sites that needs some work done so I might as well learn it better. Anyhow, my new site will have a shopping cart and I was wondering the following:

 

1. Which one? Commercial vs. Custom Made!

 

2. If custom made any suggestions for things to think about before coding? An examples is what to do if browsers do not accepting cookies.

 

3. If commercial shopping cart, any suggestions and why?

 

4. Any suggestions on how to implement this a shopping cart?

 

Currently I'm thinking either implement it using session variables  with fall back session id in URL or hidden input tags. Using hidden input tags, of course poses the problem of having to POST to the next page everytime the user navigates to another page. That is a tricky problem. Is there an easier way to do this?

 

[Azu]

If browsers aren't accepting cookies then use a server side database instead. More secure that way to.

[leesiulung]

If browsers aren't accepting cookies then use a server side database instead. More secure that way to.

 

How do you recommend keeping track of user without cookies? Hidden input tags? Session ID's in URL?

 

I'm not sure I see how is it more secure that way?

[ball420]

we use Yahoo's store editor. you can still customize everything using rtml. it's a little weird at first but we have found it to great. previously we had a cart written in python with tons of problems trying to do cross sales and coupons ya know that kind of crap but this store editor allows you to pretty much design your whole site without most of the hassels. jsut a thought

[taith]

if you get a premade one, you have to stick with their setup... their functions and the likes... if you want anything special... thats... too bad...

 

if you make one, you get full control of what you want it to do, but a) you have to debug yourself, and b) it'd take more time to set up fully

 

that much said... both routes do work, and both do have (dis)advanatages of their own... if you have more time, i suggest you make it, if you need it up and running ASAP, get a premade one...

[Psycho]

If browsers aren't accepting cookies then use a server side database instead. More secure that way to.

 

How do you recommend keeping track of user without cookies? Hidden input tags? Session ID's in URL?

 

I'm not sure I see how is it more secure that way?

 

You need to define what you mean by "keeping track of". Not sure what you are trying to do with cookies that you couldn't do with session variables - the one exception being saving their cart. BUt, you could simply require them to log in to have the capability of saving cart data. Some sites do one, some the other.

[adrian28uk]

I finally decided to build my next site in PHP after a lenghty debate with other forum members about some of the shortcommings of PHP. That is for another discussion, but came to the conclusion that it needs a lot of improvement, but had its advantages. I frequently run into PHP sites that needs some work done so I might as well learn it better. Anyhow, my new site will have a shopping cart and I was wondering the following:

 

1. Which one? Commercial vs. Custom Made!

You gain more experience from creating a custom made one.

 

2. If custom made any suggestions for things to think about before coding? An examples is what to do if browsers do not accepting cookies.

There is nothing to think about. PHP is free and is perfect for small to medium scale sites.

 

3. If commercial shopping cart, any suggestions and why?

Learn to create your own one. You will see how a basket works then from scratch.

 

4. Any suggestions on how to implement this a shopping cart?

 

Currently I'm thinking either implement it using session variables  with fall back session id in URL or hidden input tags. Using hidden input tags, of course poses the problem of having to POST to the next page everytime the user navigates to another page. That is a tricky problem. Is there an easier way to do this?

 

Use session_id to store the products in the cart table. When the user has finished shopping you delete everything from the cart where the session_id =

 

 

 

[leesiulung]

You need to define what you mean by "keeping track of". Not sure what you are trying to do with cookies that you couldn't do with session variables - the one exception being saving their cart. BUt, you could simply require them to log in to have the capability of saving cart data. Some sites do one, some the other.

 

Session variables are almost no different than Cookies other than the data/state you want to save is stored on the server as opposed to the client. In order for the server to identify what data/state belongs to who on the internet, the server sends a cookie (even for a session) to keep track of it. So in essence, using session variables require the user to accept cookies. So what I meant with "keeping track of" is essentially how do I know which session is attached to which user surfing my pages unless cookies are accepted.... See the problem.

 

if you get a premade one, you have to stick with their setup... their functions and the likes... if you want anything special... thats... too bad...

 

if you make one, you get full control of what you want it to do, but a) you have to debug yourself, and b) it'd take more time to set up fully

 

that much said... both routes do work, and both do have (dis)advanatages of their own... if you have more time, i suggest you make it, if you need it up and running ASAP, get a premade one...

 

I'm trying to figure out reasons for or against each choice. My needs are pretty simple, but would like to give the site the opportunity to evolve with a little forethought. The cart is probably the most complicated task next to security.

 

All of that said, I like the response I'm getting to this. Although there seems to be many threads about shopping carts.

[Psycho]

You need to define what you mean by "keeping track of". Not sure what you are trying to do with cookies that you couldn't do with session variables - the one exception being saving their cart. BUt, you could simply require them to log in to have the capability of saving cart data. Some sites do one, some the other.

 

Session variables are almost no different than Cookies other than the data/state you want to save is stored on the server as opposed to the client. In order for the server to identify what data/state belongs to who on the internet, the server sends a cookie (even for a session) to keep track of it. So in essence, using session variables require the user to accept cookies. So what I meant with "keeping track of" is essentially how do I know which session is attached to which user surfing my pages unless cookies are accepted.... See the problem.

 

No I don't, because you are confusing session cookies with the $_SESSION data. A session cookie is just a cookie without an expiration set. So the cookie is a "session" cookie because it expires when the session ends. This is different from session data which is stored on the server. The location of the session data is set in the php.ini file under session.save_path

 

[leesiulung]

No I don't, because you are confusing session cookies with the $_SESSION data. A session cookie is just a cookie without an expiration set. So the cookie is a "session" cookie because it expires when the session ends. This is different from session data which is stored on the server. The location of the session data is set in the php.ini file under session.save_path

 

I might have not been clear or specific enough in my language so please excuse me. Unfortunately, English is not my mother tongue. Anhyhow, I do understand that session data is different from session cookies. What I'm saying is that session data is tied to the session cookie. The first time a session is established between a browser and a server, the server sends a "session cookie" to the client browser that gets stored for the duration of the session. Upon each request of a web page from there on by the browser, the session cookie information is forwarded to the server. That is how the server recognizes the client browser. So without the user accepting that session cookie there is as far as I know or can think of right now, how the server will be able to track what request belongs to what session data.

 

Cookies can also store all the data without storing information in sessions, in which case the data is transmitted to the server on every request.  So in essence sessions and cookies accomplish the same thing with minimal difference yet much higher exposure to security risk.

[Psycho]

I might have not been clear or specific enough in my language so please excuse me. Unfortunately, English is not my mother tongue. Anhyhow, I do understand that session data is different from session cookies. What I'm saying is that session data is tied to the session cookie. The first time a session is established between a browser and a server, the server sends a "session cookie" to the client browser that gets stored for the duration of the session. Upon each request of a web page from there on by the browser, the session cookie information is forwarded to the server. That is how the server recognizes the client browser. So without the user accepting that session cookie there is as far as I know or can think of right now, how the server will be able to track what request belongs to what session data.

 

Have you ever tested this? I did a test by creating a page to store sessin data and cookie data. I then set my browser to not accept any cookies. The cookie data was not saved, but the session data was.

 

 

[leesiulung]

Have you ever tested this? I did a test by creating a page to store sessin data and cookie data. I then set my browser to not accept any cookies. The cookie data was not saved, but the session data was.

 

I tested this a long time ago with ColdFusion and setting the browser to reject all cookies. At the time it never found the session. To solve this issue I had to set the session, redirect the page immediately afterward and then check if I could find the session data on the redirected page. If session data was not found, cookies was turned off....

 

I don't know if this has changed since then, since browsers do different things and implement non-standard things all the time. I will give it another whirl to see what happens and report back.

[leesiulung]

Ok, so it took  a while for me to test this session cookie out and I apologize. Anyhow, the results are in and my browser rejected the session cookie. Testing procedure:

 

1. Set all security zones on browser to High on IE7 (yes, I like IE and no I'm not a MS fanboy)

 

2. Set browser to reject all cookies

 

3. Use the following code:

 

filename: setsession.php

<?php
session_start();

$_SESSION['session_exist'] = 'SESSION SET';

echo '<a href="checksession.php">check sessison</a>'; 
?>

 

filename: checksession.php

<?php
session_start();

if(isset($_SESSION['session_exist'])) {
	echo 'Session is SET: ' . $_SESSION['session_exist'];
} else {
	echo 'Session is NOT set';
}
?>

 

Note, that when I tested this on a server running locally on my computer it accepted the session cookie. However, when tested online with server on the internet it rejected the session cookie. I'm not sure why it would accept the cookie on a local instance although it shouldn't even considering it is most likely from a trusted source. However, I haven't bothered to look into this.

 

[attachment deleted by admin]

[Psycho]

That's interesting. I tested it on an external server and it worked.

[SammyGunnz]

Use a commercial one. Especially since they provide constant updates to the code to accommodate any changes payment gateways/processors make. Not to mention, having to provide support and maintenance. 

 

All my clients are currently using:

 

http://www.turnkeywebtools.com/products.php?p=sunshop

 

Written in PHP and loaded with plenty of support for diferent shipping methods and Payment options. They have an online demo you can check here:

http://demos.turnkeywebtools.com/ss4/admin/login.php (Admin)

http://demos.turnkeywebtools.com/ss4/ (Shop)

[leesiulung]

That's interesting. I tested it on an external server and it worked.

 

What settings and browser did you use? For instance in IE I had to specifically set to reject all cookies and not just the zones (in fact I don't think the zones matter, but I did it anyhow).

 

Use a commercial one. Especially since they provide constant updates to the code to accommodate any changes payment gateways/processors make. Not to mention, having to provide support and maintenance.

 

All my clients are currently using:

 

http://www.turnkeywebtools.com/products.php?p=sunshop

 

Written in PHP and loaded with plenty of support for diferent shipping methods and Payment options. They have an online demo you can check here:

http://demos.turnkeywebtools.com/ss4/admin/login.php (Admin)

http://demos.turnkeywebtools.com/ss4/ (Shop)

 

That is expensive at $250 per year. How easy is the integration process? I'm concerned I spend more time figuring out how to integrate and tweak the cart than actually just building myself. Then again it might have lots more features that I need but did not think of ahead of time.

[Psycho]

That's interesting. I tested it on an external server and it worked.

 

What settings and browser did you use? For instance in IE I had to specifically set to reject all cookies and not just the zones (in fact I don't think the zones matter, but I did it anyhow).

 

I was using IE6 and I went to Tools < Internet Options. On the Privacy tab I clicked the Advanced Tab and I placed a checkmark in the ckeckbox to Override Automatic Cookie Handling and then selected the options to block First-Party and Third-Party cookies. Also, I did NOT place a checkmark in the ckeckbox to Always Allow Session Cookies.

[leesiulung]

This probably won't work, but worth a shot.

 

Try setting all your zones to HIGH  and setting the browser to block cookies by using the slider. I don't remember how this is done in IE6, but probably similar to IE7.