Shop-for-ProcessWire (@Apeisa)

[benbyf]

Ok, so I got as far as adding an item, viewing my cart, checking out and then not sure what should be on the /checkout/confirmation page after putting in my details, i've installed the paypal module.

Literally no idea how I'm supposed to add the paypal payment system. any help would be amazing.

[Soma]

ah, thats the issue. sorry been used to not echo'ing when referring to a modules markup.

There's no markup module that output content themself, you always need to echo it. This makes it a lot more flexible as you only get a string back and can do things with it, or use it in a own function to generate markup and send it along. For me it's bad practice/design when a markup generation method uses echo to output it directly.

Ok, so I got as far as adding an item, viewing my cart, checking out and then not sure what should be on the /checkout/confirmation page after putting in my details, i've installed the paypal module.

Literally no idea how I'm supposed to add the paypal payment system. any help would be amazing.

Not sure what you mean. I think confirmation should be the details you entered read only, then you go on with the next step (this is where payment module is run). I'm not sure what PayPal module does, but the payment module does "something" and when done showing some thank you or redirect to some other page.

[benbyf]

So after submitting your details to the checkout page containing the checkout markup it loads to /confirmation/ page which returns 404 so not really sure what I'm missing. And there isn't really documentation for implementing payment or for the PayPalpayment module

Http://www.nicegrp.co.uk/dev/hackney/checkout/

[Soma]

Strange I've never experienced a 404 there the last 4-5 setups with this module. It's done using url segments /checkout/confirmation/, checkout is a real page and confirmation the segment. 

Checkout modules doesn't handle a 404 so there must be something else in your case. does the sc-checkout template really have url segments enabled? It should cause the module installs the template and sets that option. If that's set I don't know. Maybe cause you run it not from the root in a subfolder.

[Soma]

AS far as documentation goes. I'm not sure, certainly it's spare, what the future of this module is and since it's wrapped up quickly by apeisa for simple own project, there isn't much support or development going. Although I find the readme and looking at the example payment modules enough to get it up quickly. I know this doesn't apply to all. Non experienced developers may struggle. But usually I find people scare away from modules (when they shouldn't) and think there's a lot of complexity that isn't there really. It's so simple as it doesn't requires much and works with the same API as much as you would with pages and in templates.

A Payment module here is the module run when you get to the /checkout/payment/ step, it either just saves the order and shows a message or redirects, or it builds a form you need for your payment provider etc .

Look at the simple invoice example.

https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentInvoice.module

processPayment() is the method called once you reach that point in the checkout. This can be anything that is required to do the payment.

https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentExample.module 

[benbyf]

Thanks @soma the url segmentation sorted it.

Your right, as a seasoned html/css/js designer/dev I usually rely on the docs for modules as I've as yet not created one myself and had good experiences with some fantastic modules. This one is ace and hopefully I'll be able to add to the project once I've created my first shop, I also hope to create a StripPayment option too as it would be my favoured payment system. I think the thing that confuses me most about this project is how the different modules relate and how they should be used together and what methods are available to me - a cheat sheet might be useful for modules with lots of template methods maybe?

I have successfully created and paid for an item on my dev shop so will endeavor to feedback my experience creating a published eShop once it's finished. Thanks again.

[dreerr]

Sorry in advance for "abusing" this thread for my question, but I thought this is the most official thread about Shop-for-ProcessWire

I want to develop a mail confirmation for the order placed. This should go to the customer, as well as to the admin of the site. I'm not quite sure what is the best practice for that. I'm using the InvoicePayment, so I could just fork that module, but it seems inconsistent as payment methods may change or be extended. Where would be the best place to put this?

Thanks, Julian.

[apeisa]

If I remember correctly, I did that at template level, I can check that later (not at computer now).

For all you interested in e-commerce and pw: I am working on new set of modules to create really robust base for pw e-commerce. Some of the modules will be open sourced (like general payments modules, stripe is already done, released soon) and some will be commercial. I hope to release these this summer, along with full featured shop profile.

Currently working on paid downloads and tax support.

Thanks for Nico for "pushing" me to build this, it's looking very promising so far.

[dazzyweb]

Great news apeisa. Can't wait.

[Ivan Gretsky]

I was thinking about starting an e-commerse skeleton profile myself, but I am really happy someone with more experience is already doing the job so expected and timely! If there is a way to take part in this great endeavour (like testing or just pushing that "like this" button) please let us know.

[dreerr]

Yes for me it makes the most sense to send at template level, looking forward to the solution you will publish

[Soma]

Sorry in advance for "abusing" this thread for my question, but I thought this is the most official thread about Shop-for-ProcessWire

I want to develop a mail confirmation for the order placed. This should go to the customer, as well as to the admin of the site. I'm not quite sure what is the best practice for that. I'm using the InvoicePayment, so I could just fork that module, but it seems inconsistent as payment methods may change or be extended. Where would be the best place to put this?

Thanks, Julian.

The place for that would be in the PaymentModule of your choice.

https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentInvoice.module

This is just a basic example module and you would add what you need after the order save, or just create your own invoice module. I'm not sure what you mean with in template level, but that makes the least sense to me.

[Macrura]

@apeisa - great news about ecommerce...!

I'm trapped now for last 3 weeks on prestashop project..no other viable choice for this, but hard not to feel frustration at every turn, changing things, adding features, when compared to PW.

Main problem with turnkey ecommerce systems (have done serious in-depth testing on Shopify, Magento, Lemonstand, Volusion, Opencart) is that they tend to work for a very narrow set of ecommerce business models, and takes some serious muscle to get them under control and into something that matches the specific need of the project. (Gotta say though, Prestashop is turning out to be the best of the bunch)... Main things that would have made this one easier in PW:

1.) Associating specific images to child products (product variant matrix - color/size combos) would have been 10x easier, faster, and more efficient; could have been almost automatic; with PS it's labor intensive and clicky...

2.) Uploading, managing and resizing images - 10x easier in PW... PS has no drag and drop uploader, image resizing is somewhat arcane, system doesn't really crop to size;

3.) Serving different images based on user agent, and also serving retina images - almost impossible with PS..

[benbyf]

looking to create a shop site soon and was wondering whether I should hold fire after all the activity here recently if the the PW shop module is going to get superseeded. i need Stripe payment and multi-postage modules sp would it be worth making them for teh new system or go for it now??

Thanks

[apeisa]

What you mean by multi postage modules?

Macrura: yes, what comes to building product catalogs, there ain't better solution than ProcessWire. Also about flexibility: I have something called "DeliveryModules", which modify the checkout process: what information to ask, what to do after payment, how to deliver the goods etc. I think it keeps things simple per shop: for example no need for tons of postal related options, if you only need email address from customer and deliver the goods digitally.

[benbyf]

yeah basically, was looking for something that allows for postage options per item, and by group (say if you've ordered 3 of the same thing the postage maybe be cheaper)

[Jonathan Lahijani]

@apeisa - great news about ecommerce...!

I'm trapped now for last 3 weeks on prestashop project..no other viable choice for this, but hard not to feel frustration at every turn, changing things, adding features, when compared to PW.

Main problem with turnkey ecommerce systems (have done serious in-depth testing on Shopify, Magento, Lemonstand, Volusion, Opencart) is that they tend to work for a very narrow set of ecommerce business models, and takes some serious muscle to get them under control and into something that matches the specific need of the project. (Gotta say though, Prestashop is turning out to be the best of the bunch)... Main things that would have made this one easier in PW:

1.) Associating specific images to child products (product variant matrix - color/size combos) would have been 10x easier, faster, and more efficient; could have been almost automatic; with PS it's labor intensive and clicky...

2.) Uploading, managing and resizing images - 10x easier in PW... PS has no drag and drop uploader, image resizing is somewhat arcane, system doesn't really crop to size;

3.) Serving different images based on user agent, and also serving retina images - almost impossible with PS..

I agree with what you've stated.  I've also worked with various ecommerce systems including:

• Magento: too overengineered, excruciatingly difficult to theme, slow, only makes sense sites that would take advantage of all its complexity; fun fact: it's 8 million lines of code, and the team consists of 8 developers; I believe the version 2.0 rewrite has been in the works for almost 4 years now
• Shopify: good but working with a remotely hosted / SaaS ecommerce system has its limitations. i also don't like how the catalog system is structured.
• Lemonstand: never worked with it but they went the remotely hosted / SaaS route
• OpenCart: looks nice on the outside, but once I dove in, I didn't like how certain things worked
• Prestashop: same as Opencart
• Volusion: SaaS and it sucks
• BigCommerce: SaaS; never used it but probably a good competitor to Shopify
• WooCommerce: not bad, however I've moved away from WordPress and since it's a WP plugin, it feels very second class, clunky and uses WP's architecture.  it doesn't have a refined feel to it.  also, a lot of functionality that should be built into it comes via extensions.  given how the prices of extensions have sky rocketed for woocommerce, expect to spend around $500 to $1000+ dollars to bring it the features you will eventually need, that then may have issues with successive WP and Woocommerce updates... plugin hell.  makes more sense to go with a dedicated ecommerce system where everything is built tightly together given those reasons.
• CS Cart: looks good, but I did some research and now I forgot why I didn't like it

If I were to go with a dedicated ecommerce system, I'd either go with:

• Spree: Rails based solution. Got recently funded by GoDaddy with $5 million.  Open source.  Very promising and big names behind it.  Built in a way where integrations can be done nicely.
• Sylius: Symfony based system.  Looks promising as well.

I don't take on too many ecommerce projects these days, however if I do, I keep it simple with ProcessWire + FoxyCart + OrderDesk.  It's a simple but extremely flexible approach since ProcessWire makes it easy to build out a catalog that conforms to a site's unique catalog structure and product types without bending backwards and having to override a bunch of things.  I'm interested to see what FoxyCart version 2 brings to the table.

I'm also patiently awaiting Apeisa's system.  Need any beta testers or perhaps some general feedback Apeisa?

[benbyf]

so is the current PW-shop going to be developed further or a completely new module, still wondering if I should wait for the update or carry on with the current implementation.

thanks for the list above @jlahijani

cheers

[Nico Knoll]

I think it's more likely to be completely new as it  is more a bundle of different modules which combined are making a great shop "module".

[Beluga]

@jlahijani: that's a valuable summary you've got there.

Have you reviewed Sellvana? Its co-founder is the former lead technical architect of Magento. I wonder, if he has managed to avoid overengineering this time

They've done some webinars:

Theming

Module development

An early review from a Magento perspective

[pwired]

Thanks jlahijani for listing up those ecommerce systems. I have tried a few of them my self

and ended up with OpenCart. I found that it has a very easy accessible and understandable

backend for a shop owner to work with. It is a very fast ecommerce system, like processwire

it uses php both directly as a language and a framework. The inside structure of OpenCart

is similar to processwire and you can code OpenCart as freely as with Processwire.

http://jumprit.wikansaged.com/opencart-theme-a-guide/

OpenCart: looks nice on the outside, but once I dove in, I didn't like how certain things worked

Can you mention some things you don´t like how they work in opencart ?

[apeisa]

I hope to open beta testing soon - planning to open it first for just one or two person and then after that start selling it with 50% off beta pricing. Yes, this is totally new system, no single line from current shop module used.

Yesterday I got file downloads working. Couldn't use PW:s pagefiles, since those would have been public (because product page is public). So I ended up having general "downloads" section, where shop admin can add/edit/remove file downloads, and then new "downloads fieldtype", which allows attaching those downloads to page. This method has one drawback: adding file downloads is two step process (first add file into downloads section, then go edit product to attach it). There are some good sides also, especially if same downloads are found from mulptiple products and the files are updated every now and then.

File downloads work by "codes", which are unique for each file and each order. You can set rules how long codes are active: for n or unlimited downloads or until certain date or always. There is also possibility to "re-deliver" digital downloads order from shop admin, so customer gets new email with fresh download links.

[pwFoo]

Sounds good. 

Would be glad to read a feature list

Have to build a shop with invoice, paypal payment gateways.

Also file download could be a needed feature...

Would be great to separating design / template for easy styling.

[apeisa]

As for feature set: my aim is not to solve each and every e-commerce situation there is. I would consider this more for "small shops" at this point, haven't tought about scalability for hundreds thousands orders for example.

Here is short feature lists what I have so far and what I am planning for release:

E-Commerce modules:

• Shopping cart
• Support for different delivery modules (these changes whole checkout process, what fields to ask from customer, what to show after payment success / fails etc. Currently I have done "DeliveryEmail" which only asks email address from customer and then sends email confirmation with possible download links. I will implement more general "DeliveryPostage", where we ask postal addresses also)
• Support for different payment methods (currently stripe implemented, looking for paypal too for the release - payment methods are independent, so they can be used in other projects too than only this shop)
• Admin page to manage downloads
• Fieldtype to attach downloads to products (products are always pages)
• Since products are pages, support for variations etc are easy: just use repeaters or PageTable.
• Admin page to manage orders: printing packing slip, mark them as delivered etc... (50% done)
• Admin page for simple monthly reports (todo)
• Multiple taxes and taxes for products (todo)
• These E-Commerce modules are planned in a way that first you build your product catalog (just using ProcessWire) and then install these modules (only those modules you need). So in a way these are quite a "transparent" glue there.

Shop profile (might implement this after the beta period):

• Starter profile for "full featured" shop: product template, categories, tags, product search, related products etc... Can be used as a standalone shop or just for educational purposes (look how certain features are implemented and add them in own store).

[Nicolas]

@jlahijani: that's a valuable summary you've got there.

Have you reviewed Sellvana? Its co-founder is the former lead technical architect of Magento. I wonder, if he has managed to avoid overengineering this time

They've done some webinars:

Theming

Module development

An early review from a Magento perspective

I'm currently building an ecommerce website with Thelia. It's Symfony based, easy to theme and to develop for. This second version is quite young but the roadmap looks great.