Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
Sindarin wrote:But you can't maintain that data with a cookie though as it always expires sometime.
True. Which is why cart data should be stored in a database table, not in a cookie or session or hidden variable or anything else that's transient. Having statistics about which products have been viewed, which have been added to a cart, which have been removed from a cart, which were most popular during a special offer, which were viewed most by existing customers, which were most popular during a holiday period, etc is very useful for planning what to promote and offer in the future.
There's a HUGE amount to ecommerce applications. Writing a good one is probably the most difficult task for any web development team. In the one I maintain there are 6 tables just for the user's cart. It's massively complex.
There's a HUGE amount to ecommerce applications. Writing a good one is probably the most difficult task for any web development team.
I would say enterprise CMS would top the charts as they essentially act as web based operating systems and wrap shopping cart functionality, as well as forums, blogs, etc.
Joomla is insane...slthough I will admit writing a internationalized shopping cart is not trivial. With all the tax laws, shipping/handling, price variations, etc. I felt more like an accountant than a developer when I worked on one.
onion2k wrote:True. Which is why cart data should be stored in a database table, not in a cookie or session or hidden variable or anything else that's transient. Having statistics about which products have been viewed, which have been added to a cart, which have been removed from a cart, which were most popular during a special offer, which were viewed most by existing customers, which were most popular during a holiday period, etc is very useful for planning what to promote and offer in the future.
I don't think logging the statistical data you mention means that data should be the same as the cart data. I often maintain the cart in the session because of its transient nature. Saving statistics and saving the cart between session are separate concerns that I have found complicate the cart code.
I don't think logging the statistical data you mention means that data should be the same as the cart data. I often maintain the cart in the session because of its transient nature. Saving statistics and saving the cart between session are separate concerns that I have found complicate the cart code
This is what I was thinking. I'm not sure how far you all got with that devnet store (or what other projects you worked on) but the last I worked with just logged the product ID, timestamp, etc whenever it was bookmarked or viewed. Much like a CMS would when you visit the page before display.
A customer visits the site he gets a cookie with a unique id hash. We will use that to identify the customer. Each time he pushes add to cart, we insert a row in a table called customer_selected_products containing:
customer_id (grabbed from cookie we set earlier) | the product_code or title (something unique to identify the product he chose)
When he pushes checkout then we go through the database match the id stored in his cookie with the his rows and select the products from the database possibly storing them in an array.
That way his choices remain in the database for customer data even if he doesn't checkout and the cart is cleared if he clears his cookies. (should be his choice after all) but his choices remain anonymously in the database for us to compare.
Please share your thoughts.
The only thing I don't know is how the bank/merchant receives the data over their secure checkout page. Session variables? cookies? GET? POST?
(I've never worked with any bank/merchant though.)
arborint wrote:
I don't think logging the statistical data you mention means that data should be the same as the cart data. I often maintain the cart in the session because of its transient nature. Saving statistics and saving the cart between session are separate concerns that I have found complicate the cart code.
So you duplicate the data? Or you only compile stats at checkout or something? I'm interested in how you handle reporting on conversion funnels, abandoned carts, whatever you want to call it.
Sindarin wrote:I have a concept:
A customer visits the site he gets a cookie with a unique id hash. We will use that to identify the customer. Each time he pushes add to cart, we insert a row in a table called customer_selected_products containing:
That's called the server session pattern, what's wrong with PHP's implementation?
Not a very helpful post maybe, but I'd definitely go for an existing solution. Not only is it a huge amount of work to get it up and running, planning etc. But then you have the security aspect of it all.
Not a very helpful post maybe, but I'd definitely go for an existing solution. Not only is it a huge amount of work to get it up and running, planning etc. But then you have the security aspect of it all.
Are you the only developer on this project?
I am good at planning as long as I know what I'll need to use. I don't see any security pitfalls with this as I am not willing to process credit card information through my code.
I don't think it's that big amount of work as I recently made a fully functional CMS with a lot more parameters to take account of. And yeah I am alone.
I probably am, but I can't know for sure until I have tried. The CMS I was making felt the same, but now I can make the whole thing in a couple of days. Like all things it's a matter of practice. If I get the grasp of its concept I am pretty sure I could figure that out as well.
Never delete cart data from an online store. That information is incredibly useful regardless of whether the customer actually bought anything.
But you can't maintain that data with a cookie though as it always expires sometime.
I've been reading about sessions and cookies, I think I understand the concept, but I can't figure out what to store for example when a user clicks on "Add to Cart " and "Checkout".
Sessions and cookies are very very simple. IMO
Also. What if the user has cookies disabled? Maybe sessions would be a better way to go for transient information.
I'd say go for it. Yes its hard, but time cannot be created or destroyed, only be allocated. So why not pursue your dreams? You may fall in the process, but if you get back up eventually you'll learn to walk instead of crawl, and run instead of walk. Creating a basic store is actually not that hard, I've done it several times. Since you have a working CMS you just need to be able to store a single photo + price with each page, call it item instead of page, make a basic cart class that stores items in a session, and implement a checkout routine that collects info and stores it in a table. You can administer the thing thru phpmyadmin until you feel like creating yourself an admin panel.