E-Commerce with ProcessWire?

[Soma]

Really nice to see this taking shape, thanks apeisa!

I'm currently looking into your new version and at what I've done to your previous version. Also looking at what I've done with the current shop I'm still working on. It got delayed because of missing content, images etc.

There's a couple things I'm thinking about the different parts and how they could be extended or made flexible/configurable in some parts.

Module Cart

Looks good and somehow still the needed basic functionality. I'm asking if it would be possible to include variations ( simple child-pages approach ) into the cart model? This would only require to change the following functions:

- getTotalSumFromItems()

- renderCart() // though I've done the cart rendering in a template I created "sc-cart".

In my version I just done it like this:

// see if variant page has price field

// if not choose from parent product page
if($product->sc_prize) $total_price = $item->qty * $product->sc_price;
else $total_price = $item->qty * $product->parent()->sc_price;

...

Maybe I could make a fork and try to implement those myself? What you think?

Also I see something for "shipping costs" is needed in the cart rendering, and of course in the order management. What have you planed on this?

Maybe it would in some cases be useful to have some discount based on the total cost, and no shipping costs after a minimum of total costs too.

Those are thing commonly need in shops as I see it.

Checkout Module

As with the previous version, I see you still only basic fields for the order form. I think it would require some more in most cases.

- Having a gender is questionable but definately something to consider. Event it not needed at the end it would be there.

- I would see having a "prename" "lastname" instead of full name

- Instead of address having a textarea, I think it would be better to have "address" for street, "zip", "city" and "country" separate

Regarding the order template and complete order, I think there will be some more fields needed.

- 1 field for the "payment_id" as some payment services generate a payid in addition to the order_id, that comes from the shop.

- Depending on the payment service, there's possibly some more fields that could be useful, like payment card type used, last 4 digits of card, if the order wasn't successfull theres error codes provided.

I have no idea as of now how this would be doable in the current model. I think some sort of basic set of fields that would serves for all payment types would make sense? Or would it be possible to make configurable to add custom fields to the order, so it would be dynamicly handled depending on a config and saved into a text field serialized? I have hard time seeing through this.

Also how do you plan doing the validation on the order form? I currently have the whole shipping-address-completeorder-to-payment process handled in 1 template with custom validation class.

In my current shop, once the process is complete I save order using shop API with status "not-complete". Also in same template it handles the return from the payment service, changing the state of the order to "complete". But because the payment method I use is on demand, with authorisation for the payment, I need to have a status "payed" once it's payed and "processed" once it's shipped and done.

---

Basicly I'm trying to get a clearer view of what module should provide what function. How could hook-able functions being useful here and for what?

Also I really would like to bring in my experience from the current shop I'm doing, which seems to have little different requirements than yours. And see if it could be done without touching the module codes. But I have a hard time doing so still

[apeisa]

Thanks for the feedback Soma.

Shopping Cart

I think we need to wait for repeater to ship and see how it works with variations. I have a feeling that it will be the best way to implement variations. Shipping costs: are you thinking about per product shipping or per shipping method chosen? Or both? I think shipping stuff is something I need to focus soon.

Checkout

All those checkout stuff like having only fullname, email, address are just for quick developing, nothing final there I am currently doing bunch of fields and having settings to set those as visible / hidden / required etc. After that I will build custom validation for those... I am also thinking about possibility to extend those with some custom fields.

I think I'll add payment_id, and if other stuff is needed to save from payment service, all those will go to one textarea field. I don't think we need anything custom here. This is the hard part, since Orders Management need to know how to use orders: if we make orders "dynamic", it will mean a lot of new code to orders management also.

About what should be hookable etc

I think that this is little bit hard since this is still so early and lots of moving parts. After we are more ready with very basic requirements, I think it will be much easier to see what are the pain points that many people would like to customize. Some things we already know (like what information to ask from customers) etc.

[Soma]

Thanks for the feedback Soma.

Shopping Cart

I think we need to wait for repeater to ship and see how it works with variations. I have a feeling that it will be the best way to implement variations. Shipping costs: are you thinking about per product shipping or per shipping method chosen? Or both? I think shipping stuff is something I need to focus soon.

Yes, that's certainly a good new way to do variations. Then it would be a little different dealing with the product id, as with child pages it's easy. So the id in the cart saved will match that variation.

Checkout

All those checkout stuff like having only fullname, email, address are just for quick developing, nothing final there I am currently doing bunch of fields and having settings to set those as visible / hidden / required etc. After that I will build custom validation for those... I am also thinking about possibility to extend those with some custom fields.

I think I'll add payment_id, and if other stuff is needed to save from payment service, all those will go to one textarea field. I don't think we need anything custom here. This is the hard part, since Orders Management need to know how to use orders: if we make orders "dynamic", it will mean a lot of new code to orders management also.

That sounds great! Yes the dependency of the orders management module on certain fields will make it a little harder to make it flexible, but it may could be handled as "custom-fields". Then those are only informational and there could be some sort of standard output of those on order detail page.

Also what I have implemented is a little search field to search for a payment,order id. Just as an simple process function. I think it also would be cool to have a per year or month, day filter in the overview. Just as example.

About what should be hookable etc

I think that this is little bit hard since this is still so early and lots of moving parts. After we are more ready with very basic requirements, I think it will be much easier to see what are the pain points that many people would like to customize. Some things we already know (like what information to ask from customers) etc.

You're right. We should wait until things are more settled. It's also easier to see as you move along. I'm sure it will be great! I don't want to bother or interupt. I think once you got the most basic version finished, it will be a lot easier for me or others to help coding and extending if needed.

[apeisa]

Soma: you might want to try the newest version. Field settings doesn't work yet (it seems that pw doesn't like fieldsets on admin, posted about that on another topic), but you can play with defaults on getDefaultData() function on Checkout-module. I still want to make the flow cleaner, but this is starting to take shape.

Oliver: I created another example payment method so if you want to take a look how I did the module implementation. Super simple really, but works nicely.

There are two parts. First:

$paymentModules = $this->modules->find('className^=Payment');

That snippet finds my installed Payment modules. I use that to render dropdown to choose a Payment method.

Then the other part is like this:

$paymentmethod = $this->modules->get("{$order->sc_paymentmethod}");
return $paymentmethod->processPayment($order);

ProcessPayment(Page $order) is required from every payment method (I am using abstract class instead of interface, since I wanted them to have $this->completedUrl automatically.

[Soma]

Thanks apeisa, you rock! I haven't got the time to take a lock at new version. I'll at weekend.

I got a little snippet you might find useful, and consider implement it.

public function ___executeSearch() {
	$this->fuel->breadcrumbs->add(new Breadcrumb('../', 'Orders'));
	$this->setFuel('processHeadline', $this->_("Order search result"));
	$id = (int) $this->input->post->searchquery;

	$result = new PageArray();
	$result = $this->pages->find("template=sc-order, id=$id, include=all");
	$result->import($this->pages->find("template=sc-order, sc_payid=$id, include=all"));

	$out = '';
	if(count($result) > 0) {
		$out .= "<h2>" . sprintf( _n("found %d order", "found %d orders", count($result)), count($result) ) . "</h2>";
		$out .= "<ul>";
		foreach($result as $order) {
			$date = date($this->config->mydateFormat,$order->created);
			$out .= "<li><a href='../edit/?id={$order->id}'>#$order->id, #$order->sc_payid, $order->title, $date</a></li>";
		}
		$out .= "</ul>";
	} else {
		$out .= '<p>'.$this->_("No orders found").'</p>';
	}

	return $out;
}

// i didn't use PW field style, but simple form markup on top of order overview

$out .= "<form action='./search/' method='post'>";
       $out .= "<label>Payment ID: </label><input type='text' name='searchquery'/> ";
       $out .= "<input type='submit' name='submit' value='suchen'/>";
       $out .= "</form>";

[apeisa]

Thanks for the snippet Soma, I will implement that for sure! I will probably add more options, to search with customer name etc.

BTW: if you are interested (and have time), ShoppingReports would be nice independent module that is needed. Something to get overview on your sales weekly / monthly / yearly and maybe by product etc.

[Soma]

Your welcome, yeah some more search options would be great.

Yes, that would be a great addition and fun to do module. I don't know when I will have time, but would like to participate. I would also first have to try and look at the current shop module and maybe start with something simple first and extend further step by step.

[apeisa]

Support for stock levels added (with a shop wide setting to allow/disallow negative stock). Also now all settings do work (thanks to Ryan's fix on core).

[Oliver]

I can't wait to finally test it tonight or maybe tomorrow. I'll fork the latest version and dive into it to experiment with some features, as I have also an actual use case in mind. It's a really exciting thought, being able to build online-shops with such a powerful API at hand. Hopefully I'll be able to contribute at least some thoughts and ideas to this.

[apeisa]

Good news Oliver. I am very happy to get any feedback, even very minor changes to make code better. There are lot of compromises, since I don't handle OO coding that well.

Also, haven't really focused on security yet, so that is something that I hope everyone takes a very critical look.

[apeisa]

Created first real payment method: https://github.com/apeisa/PaymentSuomenVerkkomaksut (It is most popular payment processor here in Finland). It was quick one, since they have good docs, REST api and even nice PHP Class.

[diogo]

I was not following this topic because I wasn't thinking of building an eCommerce site so soon. But today I was asked if I can... So, Apeisa, do you think this module will be usable for production anytime soon? Or I should look for a solution like Magento or LemonStand?

Not wanting to make pressure here. Just asking

[apeisa]

I think it all depends about your needs. There are lots of stuff missing what you might need. Like discounts, taxes, reports, customer accounts, PayPal integration etc... Then of course I need to check that I don't have any security holes.

But the functionality that there is seems to work nicely. I recommend installing and testing

[diogo]

I will. Thanks!

[spoetnik]

Installed the Commerce module in a MAMP Pro (mac) environment, and when adding an item to the cart I get an error message:

Warning: Cannot modify header information - headers already sent by

Line 35 of ShoppingCart.module

Session->redirect( ) ../ShoppingCart.module:35

Strange, because I had the same install (backed it up, restored it at home) on Ubuntu and everything was alright ?!?

Any suggestions?

[apeisa]

Hmm.. Hard to say why it is giving that error, because that redirect is happening in init() method of an autoload module, so no real output could have happened before that from templates at least. Sometimes those are because of whitespace after ending ?> tag. How is your other code? Any other modules installed?

Have any others got this running on MAMP? I myself have windows 7 with apache, mysql and php running locally.

Do you get any more detailed error messages with debug=true?

[spoetnik]

No other 3-th party modules installed. My code is probably horrable, I am not a skilled programmer, more a copy/past guy.

It is just for testing, so not a big deal for me.

@apeisa, If you are interested I could send you a backup of my site including a DB-dump, so you can test it? Again, it's nly for testing and fun for me, so no big deal at all.

[diogo]

There are lots of stuff missing what you might need. Like discounts, taxes, reports, customer accounts, PayPal integration

You think customer accounts should be integrated on the ecommerce module? Couldn't they be simple users of PW with a "customer" role?

EDIT: I still couldn't install and play with this. I will soon, and report back. Also, the ecommerce work that I was proposed to do, is much bigger and complex than I thought, but I would still love to be able to make it with PW.

[apeisa]

What I meant with customer accounts are stuff like "my orders", "my addressbook" etc. Granted, most of these things will be something that will never be in Shop core.

I already tie the order and current user. So that is in certain way done.

[ryan]

Antti, I've been sacrificing forum time for PW development time, and just wanted to apologize I've not been able to actively participate in this more. But I wanted to let you know how impressed and interested I am in this. I already have all kinds of plans for using this and getting more involved, and am thinking it will be perfect to use for the DI bookstore. This is the coolest and biggest PW project to come along, and I just wanted to explain my lack of posts in here. The reason is that I'm about to jump into a work schedule (this week) where I'm not going to be able to do anything major with PW for 6 weeks, other than fix bugs and make 2.2 official. Though I'll be developing [a site] in it, rather than developing for it, so I guess that still counts as ProcessWire time. But I've been redirecting my forum time to put out a couple new PW features ahead of schedule (primarily repeatable fields), to hopefully buy some patience for the weeks ahead where I have to focus mostly on another project. But once that is done, I am looking forward to building a store and participating in the project.

[apeisa]

No other 3-th party modules installed. My code is probably horrable, I am not a skilled programmer, more a copy/past guy.

It is just for testing, so not a big deal for me.

@apeisa, If you are interested I could send you a backup of my site including a DB-dump, so you can test it? Again, it's nly for testing and fun for me, so no big deal at all.

Sorry spoetnik, I missed this last time around. If you want to, then send me a private message with a download, I will take a look.

[apeisa]

Also, the ecommerce work that I was proposed to do, is much bigger and complex than I thought, but I would still love to be able to make it with PW.

Be careful. Scope can get easily out of the hands on what comes to full-blown ecommerce. Multiple payment gateways, Integration to accounting software / stock management app / ERP, custom reports, different taxes, personalization for different customer groups, discounts etc... What we will be using this module at our company will be for very simple needs. We will stay out of the very customized eCommerce, since that is pretty much own world.

[apeisa]

But I wanted to let you know how impressed and interested I am in this. I already have all kinds of plans for using this and getting more involved, and am thinking it will be perfect to use for the DI bookstore. This is the coolest and biggest PW project to come along, and I just wanted to explain my lack of posts in here.

Thanks Ryan! I think you had few too many superlatives there

The reason is that I'm about to jump into a work schedule (this week) where I'm not going to be able to do anything major with PW for 6 weeks, other than fix bugs and make 2.2 official. Though I'll be developing [a site] in it, rather than developing for it, so I guess that still counts as ProcessWire time. But I've been redirecting my forum time to put out a couple new PW features ahead of schedule (primarily repeatable fields), to hopefully buy some patience for the weeks ahead where I have to focus mostly on another project. But once that is done, I am looking forward to building a store and participating in the project.

I have been amazed the speed how fast processwire has developed in last few weeks. It is hard to keep up and I haven't even tested repeater yet, not to mention field width... I think we will have enough to do with these all new features for the six week easily. So thank you about the great progress with PW, can't wait for possibility to show those features to clients and start building new stuff using them.

It will be great if we have more stores build on top of this. It will be few weeks when I start building our first one and I think I have all the needed features for that. Probably will add some simple reporting in.

[Pete]

I'm with Antti - not had a chance to keep up lately with so much other stuff going on and it's been amazing to see all the new things that are coming out lately - good work!

I will have a large(ish) PW site up and running by the time you're back and will definitely be playing with this e-commerce module for the next project

[Oliver]

As e-commerce is such a large topic with so many features to discuss etc., I think it would be worth an own forum like language support. I think we will have a lot separate threats regarding products, payments and all the other features. Something like “E-Commerce in ProcessWire”.