E-Commerce with ProcessWire?

[Crash-n-Burn]

Has anyone done a processwire site along with an ecommerce solution?

I have been looking at:

*1) CubeCart.

*2) Avactis which has an interesting "{Tag}" system for incorporating shopping cart CMS content into an existing site.

3) OpenCart (although definitely some questionable developer antics going on there),

(*) Appear to be actively developed.

So what have people used,  Are there any that fit better than others?

[Pete]

Steer clear of Interspire - they have a good cart, but it's not been updated in ages, it's pricey and the support sucks.

One that isn't the cheapest (though is among the cheaper ones) but looks to have an outstanding API and interface is this one: http://lemonstandapp.com/ . If I ever build another e-commerce site that's at the top of my list.

[ryan]

I've used Drupal and UbertCart (now under the name Drupal Commerce), and run it alongside ProcessWire (1) so that Drupal and PW share the same user system. It enables a user to purchase a subscription product and then have access to protected content in PW. But as much respect as I have for Drupal, it drives me nuts when I have to use it. So I'm not sure I'd recommend this solution just because it's not so easy to get going on the Drupal side and I regularly battle with it when doing updates. Though prior to that, I'd run OSCommerce for a few years, and UberCart was like a revelation compared to that. So if you need a really strong self hosted commerce solution, I would definitely look at UberCart / Drupal Commerce, but plan to invest a lot of time.

Now I'm testing Shopify and experimenting with their post order hooks to create member accounts in ProcessWire (2.1). It's not nearly as powerful as UberCart, but the post order hooks and their 'app store' can fill a lot of gaps. This is a work in progress, so not much to say yet. I like what I see in Shopify so far, but like everything else, it's far from perfect.

[Crash-n-Burn]

@Pete

I took a look at lemonstandapp, and while it looks great on the surface... the backend is thoroughly incomplete.

LemonstandApp is missing far too many basic features to be considered for anyone selling more than a handful of "unique" items.

e.g. No way to manage stock for multiple versions of an item.

----> A Shirt that is Blue, Red, Pink etc. has to be 3 separate shirts otherwise you can't manage the stock level.

Now add another attribute to that product, like size, and the whole thing breaks down completely.

And then when you consider that LemonstandApp costs $300 --- you are basically paying for some pretty CSS.

I've yet to find anything better than Avactis as far as features and basic usability of the backend are concerned --- unfortunately the whole backend of Avactis is done with Tables and it looks very 1995. There also doesn't appear to be any Templates for the backend to fix the layout, and since it's tables you can't really apply css to fix that aspect.

[Pete]

Aside from that feature you need, how thoroughly incomplete is it? I've honestly not had time to check it out yet for more than a casual browse so I'm genuinely interested in hearing your thoughts.

I moved from Avactis to Interspire and traffic to the store I converted increased tenfold. Avactis is (or rather was at the time) pretty poor SEO-wise and seemed slower than Interspire, and I'm with you on the tables. Just the jump in traffic showed me that the move was a great decision, and Interspire's admin is much better and faster to work with.

Of course Interspire support is non-existent so again I can't really recommend them, unless you want to try their SaaS version - BigCommerce (but I still wouldn't recommend it as they ditched hundreds of Interspire Shopping Cart owners and haven't updated the Interspire website in... well... a really long time).

Back to Lemonstand and it does look like someone has created a module to do what you're after: http://forum.lemonstandapp.com/topic/1284-stock-by-product-attributes-the-ol-tshirt-issue/page__p__6681__hl__variations__fromsearch__1#entry6681 Apparently advanced inventory is on the roadmap too. Again, I'll stress I've not used Lemonstandapp or really had much time to look into it, but it seems like more than "pretty CSS" to me.

[Crash-n-Burn]

I couldn't say specifically, I didn't make a point by point list, but I've been testing Shopping Carts for the last couple months now. And lemonstandapp was slick, both in the front and backend for how you add and manage content.

There's just not much to configure, generally when I find a lack of configuration options and key features missing I lose interest. LemonstandApp just felt like a pretty Californian blonde ;-)

That's disappointing to hear about the lack of SEO for Avactis, I hadn't considered that. I really loved how Avactis made it so easy to add multiple Attributes to an item, save the attribute set as a Group, define exclusions to specific attribute pairs and handle stock for items with multiple attributes.

As well Avactis was the only cart thus far that I've seen with the "php Tag" feature for embedding cart content into an existing site.

[Pete]

LemonstandApp just felt like a pretty Californian blonde ;-)

She could have a degree in law. You never know

That's disappointing to hear about the lack of SEO for Avactis, I hadn't considered that.

The SEO comment was from a couple of years ago so it might well be fixed by now. I think part of it at the time was that it was a slow system (at least back then) and you defintely get penalised for slow loading pages as well as poorly optimised ones. So don't take my word for it - they've released several large updates since then and it might all be fixed

[spoetnik]

Any thoughts on building a native Processwire E-commerce Module?

Some elements to build, don't know whats the best solution for each would be:

Product (including variations)

Cart (database, so persistent, preferable not session based)

Order

Stock

[apeisa]

I am building one at my job. Hopefully get something solid enough to be released at January or February. I don't have need for product variants, but it will contain cart, order management, different payment methods etc.

My focus is in the backend since it is pretty trivial to build nice product listings with pw.

[spoetnik]

That sounds good!! If you need a Alpha/Beta tester, I'm in!!

[apeisa]

You find my current progress as an attachment. This is very alpha stuff, but you can play with it if you want. Not looking for feedback yet, since this is so early stuff, but soon I will.

Installation is pretty simple:

• Unzip all files to /site/modules/Shop/ -folder
  
• Go to admin, modules and check for new modules. Install Shop-module (it will install all others)
  
• Installing created bunch of new fields. Only one that is important is sc_price. Edit one of your templates (usually "product", but can be anything - if you are installing this on demo-profile, then use basic-page) and add sc_price field to your template.
  
• Then edit corresponding template file (ie. basic-page.php) and add this line somewhere: echo $modules->get("Shop")->renderAddToCart($page);
  
• Create new template file called sc-checkout and make sure it has this line: echo $modules->get("Shop")->renderCheckout();
  
• Edit your content and add some prices to your products. Then you can add those to shopping cart and create orders.
  
• Check out the Shop page on your admin, where you can manage your orders.
  

Shop2.zip

[spoetnik]

Wauw, that looks pretty impressive for an Alpha Release.

I will play with it, thanks!!

[spoetnik]

Thanks Apeisa.

I have been playing with your Shop-alpha module, and it looks promising.

I have been thinking how I could solve the Product variations, and came up with this idea;

Using Page reference.

for instance a product called "I love PW T-shirt" with references to "I love PW T-shirt, black, small", "I love PW T-shirt, black large", "I love PW T-shirt, red, small", "I love PW T-shirt, red, large"

The downside is it will be a hell of a job to add all product variations, but maybe a csv-import would ease the job.

What do you think, is this the right track??

[Crash-n-Burn]

I would recommend apesia adding in variation check, it doesn't need to have the code itself for handling multiple variations, but at least if it is there (the check) the rest could be modularized.

Example:

Instead of having a base "stock level" --- store the stock level in a variation array (that only has one member) called "base" or "root".

Then if other members (or apesia) wants to later implement multiple stock levels, it will just be a matter of looping through the multiple variation arrays.

So with a basic item like a t-shirt, that might have sizes and colors: The stock level will be stored within the 2D array:

$variation0Num = 2;  // how many loops to iterate/parse.

$variation1type = "size"      // name of the variation
$variation1max = 3;            // how many variations of type1
$variation2type = "color";
$variation2max = 3;

$stocklevel[0][0] = 1;
$stocklevel[0][1] = 2;
$stocklevel[0][2] = 3;
$stocklevel[1][0] = 2;
$stocklevel[1][1] = 3;
$stocklevel[1][2] = 4;
$stocklevel[2][0] = 1;
$stocklevel[2][1] = 2;
$stocklevel[2][2] = 3;

Items that have no variation, e.g. "base" or "root"

$variation0num = 1;  // how many loops to iterate/parse.
$variation1type = "none";   // name of the variation.
$variation1max = 1;            // how many variations of type 1.

$stocklevel[0] = 4;

At least if the check is there when adding stock (in the back end) and purchasing items (in the front end) it will make it easier for everyone involved to improve/add functionality - so that the code doesn't become fragmented with multiple implementations that are trying to solve the same thing.

[apeisa]

Thanks for the feedback guys. As you know this is very early version and there is no stock for product or anything like product variations.

I have thought about variations, and I see there two ways of doing it. One is in template level, using subpages as variables (or page references like Spoetnik mentions, but I think subpages will be better fit). You could have two templates, "product" and "product-variation", where product variation is always children of product. This is something that could be easy to do with the current release of shop module.

Other (and probably much better way) is to build custom fieldtype for price field. It would be fieldtype that would hold variations, price and stock. You could add 1-n variations and give them each unique price and stock. If we continue our t-shirt example, then I would create unique product for each different colors and then add different sizes as variations.

This is something that I am interested to build, but if we don't have project for that at our work, then it doesn't have any kind of schedule. That is the current situation.

[spoetnik]

I am looking in a totally different route, building a SOAP-client modules for Magento.

So, using Magento as the store, but using the amazing process wire as a display.

Would this be very ambitious??

[ryan]

I don't know much about Magento or what the SOAP client modules are. I have a strong preference for services built around HTTP/REST rather than SOAP. But so long as it's providing the services in some form, that means that it's probably a reasonable task to integrate. Magento also seems like a pretty solid system. Though admittedly, I've tried to install and use it before and found it a little overwhelming... Drupal/UberCart turned out to be a better fit for what I needed. But I think Magento is probably stronger overall. Let us know what you find and how it goes.

[Crash-n-Burn]

I haven't tested Magento, but throughout my months of research I kept seeing issues with it's scalability and efficiency -- especially so if you don't have a dedicated server.

Carts that I've kept bookmarks for, and like for various reasons:

• Avactis - according to an email exchange, they plan to overhaul the backend in the new year.
  Nice licensing agreements, and discounts for your clients if you are a webDev.
  
• CubeCart - I couldn't get this to run locally on windows, but it bears more investigation.
  
• StoreSprite - free version, only have to pay to get a white label (no backlinks to storesprite).
  
• LemonStand - a little pricey but not excessively, may be worthwhile when they develop it a little more.
  
• NeuCart - no demo available, excellent pricing structure: ~$50, $2 for updates. Missing stocklevel by attributes.
  
• X-Cart: haven't fully investigated.
  
• Zen-Cart: Under development again, though it went 3-4 years with nothing but a single security update. Not sure that I'd jump on that bandwagon.
  

[Oliver]

As PW is a perfect fit for any kind of product catalog, I’d love to keep the discussion going on how the several “challenges” could be overcome and the needed functionalities could be implemented through separate modules to make a 100% module based PW commerce solution possible.

There are things like shopping cart, order management, stock management, checkout and payment and - as you already said - product variations to deal with. I think with a clever architecture these things could be solved and built in a very modular and easily extendable way. Would love to hear your ideas here. And maybe apeisa also has already more practical experience to share on this?

[apeisa]

Oliver, glad that you are interested in PW-ecommerce modules.

What my early module currently does is simple shopping cart and order management. But I don't think it does those things in very modular or easily extendable way (other than the parts where it just uses PW). Stock management would be easy add on, if we stick to assumption that "product is just a page which have a price field". There are stuff like payment and shipping methods which I haven't touched yet.

I don't believe that I have enough experience to design the "PW eCommerce framework" in easily extendable way. Put what I am more than interested is to help build parts of that framework. So if we start this coordinated project between many coders, I am more than happy to participate, but not as "lead developer"

About the "challenges". I think that multiple product variations, product options etc. could be best done with few fieldtypemultiples.

[ryan]

Count me in to help anywhere needed too. I don't consider myself an ecommerce expert, so not really sure on best approach with a lot of things, and don't think I'd be the right one to lead such an effort. When you get into supporting multiple gateways, shipping methods, currencies and such it becomes quite a complex thing. As a result, I've always delegated ecommerce to other software. Currently I run Drupal UberCart and Shopify. I've also run OSCommerce in years past (what a mess that is). The thought of having a PW-based solution is attractive.

[Oliver]

Yeah, I’ve been dealing with a xtc:commerce (a osCommerce fork) and it’s a incredible mess, too. Every “module” you want to implement needs you to change stuff in core files. But at least I got a good impression of the complexity of a shop system and how the different features influence - or corrupt - each other.

I’m definitely no ecommerce expert either. Nor am I a really good coder, rather a hobbyist. But I’ll spend some thoughts on this as I have a project coming up that could be a opportunity to experiment with several ideas.

apeisa, I’d love to learn more about your shopping cart and order management. Maybe you’ll find the time to put your approach into a few words?

[Soma]

I'm currently setting up a simple shop, using the module apeisa started. It had to go quickly, so I had no time to wait for further progression on this. But I wanted to share my experience these days with you guys.

It is really a simple shop with products that have color variations. The payment method will be credit cards using a external service (little like paypal). Since they have already an order management, it doesn't even need the orders management apeisa started implementing, but it will be good to additionally save orders in PW.

As for the variations I created sub pages on the product, so I changed the cart functions to look for if the variation has a price, else it takes the price from the parent.

The cart saving feature in the custom module table is great, but I doesn't need address, so only session id and the serialized cart will suffice. And the saving order using a template with the needed fields isn't touched but in my case it does need a lot more fields than apeisa started with. So the gender, address, city, country can be entered.

As for the module to keep it flexible, I think it is best to leave out all hard coded "html" and "forms" generation of the module code. So I have the sc-checkout template all the logic of the process. So I'm able to code the shopping cart the way I need it, and just request the items array using the public module function. I didn't even used the renderAddToCart like function to generate the "add to cart" form fo a product, as it is simple to code a form to my needs and just have the product id in there, and the action url to the cart page. So only really function to handle the cart are necessary.

I'll be glad to help with this module, and I'll share the project once it's done next week.

[apeisa]

Great to hear that this was help for you Soma. I agree with you, all logic and html should be separated (not sure how well my start does that, since that is quickly coded). On top of that I think we should allow good defaults for render functions, which should be easy to customize (or just build own markup like you have done).

How you handled the variations is pretty much how I have always thought of doing that. Although I think that cleanest way in long run would be to build new fieldtypeMultiple which holds all the variations. Since there are things like additional options (think checkbox: "add extended quarantine 199€") then using child pages for things like that also would get messy.

Eager to hear how my module worked? Did you find any bugs or some code that didn't make any sense?

[Soma]

I don't understand exactly how it could get messy, but maybe you're right.

No I didn't encounter any errors, just added as function to get total items in cart. And I removed all of the cart, checkout form, add to cart markup genrating functions, as I don't really need them. And I added some more fields to the installer for the order template. Also as mentioned I added simple variation price check in the add to cart functions, was pretty easy and I think you've done a great job. I agree there could be some sort of markuup generation tools in there, but then it should be configurable or still one still being able to completely code their own in the templates. It is the case for another CMS we use at work that has a great sho module already built in. And it has no markup generation functions at all only helpers and method for adding, updating, removing from cart and saving the orders for use in the orders management.

Edit:

Oh and I thought the logic you got together with the markup genrating function, to add and render the checkout process was very hard to track and understand with all the post/get vars starting from the entry point in the renderCheckout function. That's what I simplyfied a lot by having some logic of it in the template. That way I'm not bound to it and can make the process of the ckeckout the way I need it.