Level 9
Another requirement: some items will need to be added multiple times, but customised in different ways by the user. So even though they are essentially the same product, they will appear in the cart as distinctly separate products.
May 9, 2016
4
Level 9
Shopping cart with (super-)flexible products?
I'm looking for a shopping cart that can contain flexible custom products and services. Each product type will be supported by a class of its own, and can contain data entered by the user to customise it (e.g. a name). Different product types may or may not be eligible to different users, hence the classes with their own functionality and rules built in. Pricing rules will also be complex.
I spotted https://github.com/Crinsane/LaravelShoppingcart on a previous post, but it appears to make the assumption that a cart item has a simple quantity, a straight-forward cost, and a few options. But maybe it is more flexible and extendible than it appears at first sight?
Anyone got any experience of this kind of highly customisable cart?
Edit: pricing rules are also important here. Prices that depend on who the user is, what else they have in the basket. Some products would only be available as upsells of other products, but again, all these are custom rules. I am geared up to writing my one entire cart for this, but if something that provides the basic framework already exists, then it would be great to explore.
UPDATE: I've taken the Moltin shopping cart as a starting point, re-namespaced it and modifying if from there. It handily fits into Laravel as a singleton service. Initial changes I'm making:
- Removing the
staticbasket storage - smells like a global to me and I see no reason for it. - Removing the restrictions on the required data elements that make up an item.
- Use a collection to store the items rather than an array.
- Separating the cart item ID from the product ID, so I can buy the same product multiple times, with different details attached to each instance.
The separate storage method it uses gives me the option of being able to store the basket in the database against the user's account rather than the session, so that the user can build up a cart over several days, and on different machines if they want to.
Level 9
Thanks, I'm studying a number of carts to see what problems they have had to solve. None of them fit my requirements entirely, but the basic underlying structures and methods will still apply.
Level 80
@consil Ignore @gauravojha as they appear to be spamming the forums to surface their own GitHub project.
In terms of flexibility, you might want to take a look at Moltin. They’re a start-up local to you and I (based in Newcastle), and offer “e-commerce as a service”—basically an API—so you can integrate it and model products in your system how you wish.
1 like
Level 9
Yeah, got the t-shirt (literally). I know the Moltin lads - right from their launch on a Super Mondays talk - must be four/five years ago. I was always interested in the fact they used PHP, since they had OmniPay linking to the payment gateways, which I use a lot. Whether that is still true given their latest funding, I'm not sure - haven't asked them about the platform.
Anyway, I suspect my complex structure of "products" is probably too much for Moltin to be of any help here. I probably could squeeze the products into the API, but would need an awful lot of logic built into the front-end cart - which is what I need to have anyway. So the Moltin API would just end up being storage and not much more, and eloquent is handling that side nicely.
Just to add, the term "products" is very loosely used here. I don't need to do any stock taking, so there is no inventory management needed. The products are in a number of tables, as they are in different structures, so I have a fun polymorphic relationship (it was that, or replicating records to a common "products" table, which could end up less robust if data fails to sync for any reason).
Please or to participate in this conversation.