196 replies to this topic

[apeisa]

Thanks Ryan! I didn't realize we can use same selectors there on modules too! PW surprises all the time

That makes a lot of sense to me. I have never build interfaces or abstract classes before, only read and used sometimes. I agree that this is pretty ideal place to use one. This will probably end like a horrible mess, but I will try

[ryan]

Actually abstract classes / interfaces are there to help avoid messes. You could get along just fine without them, but using them keeps things in order and lets you make assumptions about objects rather than having to check that they meet some criteria on your own. If you say that something has to meet an interface and it doesn't, then PHP throws a fatal error. That helps to avoid messes before they start. There's not much more to it than that. The terms "abstract" and "interface" sound technical, but luckily the concept is simple.

[apeisa]

I just pushed a big update. I did some more refactoring and have renamed the old modules:

• ShoppingCart
• ShoppingOrdersManagement
• ShoppingCheckout (You can now choose from all the installed payment methods which one to use.)

And now there is one new module included:

• PaymentExample (which let's you choose: I have already paid / Send me an invoice)

There is still lot to do, but this is starting to take shape. Now this creates unpublished order right after you fill your shipping details. After successful payment it will be marked as published and maybe paid (depending on payment method).

I haven't given any thought about which methods should be hookable, what should be default shipping details, how default checkout process goes etc... Also code needs still a lot cleaning and security stuff etc. But if you guys see something wrong in big picture, now is pretty good time to say it

[apeisa]

And if someone is thinking why I save current carts in database (and not just use session) is that I would like to offer possibility for logged in users to save cart and get back to it after session is long gone. Also offer nice possibilities in future to see where people stop their shopping process (is it at checkout or even before that).

[apeisa]

I haven't given any thought about which methods should be hookable, what should be default shipping details, how default checkout process goes etc... Also code needs still a lot cleaning and security stuff etc. But if you guys see something wrong in big picture, now is pretty good time to say it

Just realized that checkout steps array is just a mess. Will implement that flow much better now that I got this together.

[Oliver]

You’re a machine, apeisa! Thanks for sharing your insights here. I hope I’ll find the time soon to have a closer look at your code. Especially how you deal with modular payment modules. Have been thinking about this a lot as I’m currently trying to work out a similar solution to handle login modules for signing in users with social networks etc.

[apeisa]

Thanks Oliver. It is actually very simple (payment methods), and I am just streamlining that code. It will be super simple to build payment methods. It was clever thing to save order (as unpublished) before payment, no need to save state etc... Also offers possibility to try paying again like week later, if you fail at first time.

[raydale]

@Apeisa this looks great! The more I am getting into PW at the moment the more I am seeing that an eCommerce solution seems to be one of the last large pieces of functionality that PW lacks at the moment. Practically everything else is possible (okay - Forums might be another one but there are many more us cases for eCommerce).

For what it's worth I really like the way you are going about it, by building a simple set of functionality and then expanding over time. So many eCommerce systems out there try to do everything and end up being buggy and bloated - therefore doing nothing well.

Are you planning a simple PayPal gateway to serve common needs or are you leaving this up to the individual to build these gateways?

I should get some time to test this module over the next week or two and can help with anything up to the point of programming (coding is something I'm not particularly good at).

[apeisa]

Thanks raydale!

Yes, I am trying to keep it as simple and streamlined as possible. I think that PW makes it easy since I don't have to touch the front end / product catalog at all.

I think few features that I am thinking of that should be in "core" implementation, but I haven't touched at all yet:

• Currencies (I think first just that you can choose the currency, later maybe multiple currencies)
• Taxes
• Stock levels (should support variations)

Are you planning a simple PayPal gateway to serve common needs or are you leaving this up to the individual to build these gateways?

There should definitely be a PayPal gateway as a module. I am not sure if I will build that, since I cannot add any hours from my day job into that (we don't need paypal with our customers), but I really don't think that it can take many hours, so I could do that at some point. I will build Finnish bank gateways first and one local integrator (www.verkkomaksut.fi). We mostly pay directly from our bank account here in Finland and many doesn't even have a credit card.

[apeisa]

About variations: I think that soon it will be as simple as put sc_price field to a repeater. Tadam

[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'/>&nbsp;";
        $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.