🎉 RockCommerce is Here! 🔥🚀

[bernhard]

Hello ProcessWire Community!

I'm thrilled to announce that RockCommerce has finally arrived!

Some years ago, after building a custom shop solution, I swore I would never create another ecommerce system again. 😅

Yet here we are! After months of hard work and completely rethinking my approach, I'm confident RockCommerce will be a game-changer for ProcessWire ecommerce.

I can't wait to see what you'll create with it! 🚀

This video guides you through the Quickstart Tutorial, which was written by @Sanyaissues (THANK YOU SO MUCH!!!)

He rose his hand when I asked for beta-testers 💪😎 He had never done E-Commerce before and wanted to understand how it works - so I sent him a copy of RockCommerce and let him play and this is what he came up with!!! Absolutely remarkable! Hat off to him!

Docs & Download: https://www.baumrock.com/rockcommerce

P.S.: To celebrate the RockCommerce release, I've applied discounts to all module licenses in my shop! If you've had a successful year, this is a great opportunity to invest in yourself and potentially reduce your taxes 😉

[FireWire]

Congrats on the launch @bernhard!

[bernhard]

4 minutes ago, FireWire said:

Congrats on the launch @bernhard!

Thank you very much @FireWire - it has really been a lot of work and I hope it will be useful! 🙂 

[FireWire]

@bernhard I have a project in mind for my brother who sells things he makes online. Once I can get through a couple of projects, I'd like to build him a shop.

Many thanks for your hard work and dedication. Such great contributions to the ProcessWire ecosystem.

[zoeck]

Wow that looks great Bernhard!

I have one question. Is it possible to have several stores with separate carts in one PW instance?

I think I have to test the module soon (luckily I have a RockSuite license 😄 )

[bernhard]

Just now, zoeck said:

I have one question. Is it possible to have several stores with separate carts in one PW instance?

3h after launch and we count the first extra wish 😅

Would you mind sharing the exact use case? The cart is at the moment tied to the user's session and there is one global cart for each user. It does not sound too easy to change that behaviour but if you tell me the exact use case we might find a solution.

[zoeck]

6 minutes ago, bernhard said:

3h after launch and we count the first extra wish 😅

Hehe 🙂 Here you realize again how versatile Processwire can be used 🙂 

6 minutes ago, bernhard said:

Would you mind sharing the exact use case?

This is relatively easy to explain.
I am currently using a self-developed system in our company intranet, which is ok (the usability is not perfect), but doesn't have as many functions as RockCommerce.

We have individual “self-service” stores that run separately from each other. Examples: Company clothing, office equipment, hardware

The Products should not be mixed, even if they could theoretically be filtered individually afterwards.
The orders are processed by different departments.

[bernhard]

Very interesting! I think it would be far easier to make the cart show a warning or prevent the order if products from a different group are in the cart than really supporting different carts.

Would that be a possible solution?

Changing to multiple carts would also mean changing the logic of the cart, both on the frontend and on the backend, which is less than ideal 🙂 

[zoeck]

3 minutes ago, bernhard said:

Would that be a possible solution?

I think that could work 🙂 

Would it also be possible to make a "partial checkout" which only contains items from "category A" or "category B"?

Although I think there would then be problems removing only the ordered items from the shopping cart

[pideluxe]

Maybe you could leave all products in one cart and just inform the different departments of the order with respective products filtered by department. I don't know how the order process is done, but I'm sure, rock commerce would benefit from a flexible order processing.

[bernhard]

The cart is just a PW page and cart items are just PW pages as well - so you can do anything during the checkout process!

Every cart item just has a reference to the related product, an amount and the variation string:

So in your case you could create a form field during checkout to select the category to check out and then calculate a different price.

Actually it should even be possible to have different carts on the frontend without changing the logic on the backend. You could implement that logic on the client side with custom code. So instead of showing all cart items you would skip those having a different category!

[bernhard]

Hey @zoeck I thought about your problem and I'm wondering: Does it really make sense - for the user - to split the order into separate carts? Shouldn't it ideally be one cart for the user and one checkout, one order and then, after the order, be split into separate order emails?

That way the user does not have to place 3 orders for 3 items in the worst case, he places one order. Then 3 mails are sent to 3 different recipients listing only the products they are responsible for. What you could also do is split the order into 3 orders so that you can track for example a fulfilment status for each order. Or you add 3 different status fields to one order and track, for example, "fulfilmant_status_unitx, fulfilmant_status_unity, fulfilmant_status_unitz"

All the mentioned approaches are much easier to achieve than developing custom carts for the frontend 🙂 

[zoeck]

2 hours ago, bernhard said:

Does it really make sense - for the user - to split the order into separate carts? Shouldn't it ideally be one cart for the user and one checkout, one order and then, after the order, be split into separate order emails?

In most cases I would agree with you 🙂 but i think that it is a very special case that is adapted to our internal processes 🙂 

However, it is often the case that users first ‘collect’ items in their cart and then order them together.

Example:
The user has a new mouse and keyboard in the ‘hardware cart’, but he knows that he would like to add a headset, but needs to find out more first.
The purchasing department has announced a ‘collective order’ for company clothing, the employee would like to order something as well and therefore places the order for the clothing directly.
There is also a specific shop where recurring weekly orders are placed (food), so this plays an even greater role here.

But I think I'll have a look at the ‘partial checkout’ topic, I think that should be implementable 😉 
Then only a single cart would be necessary.

[Frank Vèssia]

great module, I like the Alpine Front End solution.

Questions:
- any support for shipment cost with custom rules
- discount code
- any way to retrive all abandoned carts?
- I guess all the customer part is up to the developer, any plan to expand in this direction?

[bernhard]

Hey @Frank Vèssia thx for your questions!

19 hours ago, Frank Vèssia said:

great module, I like the Alpine Front End solution.

Thx 🙂

19 hours ago, Frank Vèssia said:

- any support for shipment cost with custom rules

That's already built in (or possible)! I have added this to the docs for you: https://www.baumrock.com/en/processwire/modules/rockcommerce/docs/shipping/

Does that help?

21 hours ago, Frank Vèssia said:

- discount code

I've also added docs for this: https://www.baumrock.com/en/processwire/modules/rockcommerce/docs/coupons/

21 hours ago, Frank Vèssia said:

- any way to retrive all abandoned carts?

I've also added a section about this to the cart docs!

21 hours ago, Frank Vèssia said:

- I guess all the customer part is up to the developer, any plan to expand in this direction?

Like all the other mentioned puzzle pieces this can mean so many things. One might want to manage users via ProcessWire. One might want to sync users with a 3rd party tool. One might want to show custom dashboards to users on the frontend. One might want to show a dashboard in the PW backend...

I'm not sure how to proceed with this to be honest. RockGrid can be a great way to quickly create excel-like lists, which could also be great for managing RockCommerce users. But I'm not sure how much this would really belong to RockCommerce. It might be more related to RockGrid.

Then you might want to send out invoices. That could be done with RockPdf. But you might also want to make those invoices editable, and then RockPdf does not help you. Managing invoice items alone can be a pain. A simple solution could be to use repeaters, but you'll quickly realise that the UI is less than ideal. Prices do not update automatically, so you always need to save the page - to just name one problem.

I'd much more prefer having something like RockInvoice for that. With my initial version of RockCommerce that I'm using for my clients on my website baumrock.com has invoices built in. But then I wanted to use these invoicing capabilities also for my other clients that did not purchase modules from my store but ordered a website or website maintenance service.

So for the customer part the short answer is yes, I think I'll leave that up to the developer. The ProcessWire way... Unless anybody has good reasons and ideas to approach it differently?

But what you get out of the box when using RockCommerce is order management. At the moment this is just a list of pages in the page tree, but I plan to expand on this by adding a Dashboard that shows revenue stats and that shows a nice list (RockGrid again) of all the orders with hopefully helpful data (like who ordered, when, etc).

Any input or questions are welcome.

[Frank Vèssia]

59 minutes ago, bernhard said:

But what you get out of the box when using RockCommerce is order management. At the moment this is just a list of pages in the page tree, but I plan to expand on this by adding a Dashboard that shows revenue stats and that shows a nice list (RockGrid again) of all the orders with hopefully helpful data (like who ordered, when, etc).

I'm looking forward to this and thanks for the added docs!

[FireWire]

@bernhard Had a chance to tinker with the module today and am really enjoying it. Outstanding work on the fast and easy front end cart system!

I have a question about payment providers. I see Mollie has some hard coded items in the RC module, how would I go about writing a module for a payment provider that RC would work with? Since there are so many provider options out there the ability to create modules for payment providers without you needed to do extra work on your side would be great.

In my case a popular pick for payments is Stripe. I just found out that a client uses it in the billing for a platform they run, and I use it in my invoicing software as well (unrelated to PW/RC, but example of wide use). It's also difficult to adopt Mollie here with the higher fees due to being outside of the EU economic area. In my case, one year I paid Stripe ~$939+ in fees, if I was using Mollie that would cost ~$1,134+ 😵‍ luckily I don't always need to take all payments via CC but it would be even more for a real online store.

Is this something that would best be handled with hooks?

If the module concept is worth exploring, perhaps RC can provide an interface and some standard objects that guarantee RC gets the data it requires. Implementing new payment platforms could be super easy.

<?php 

interface RcPaymentProcessor
{
    /**
     * Submit a new payment transaction to the payment processor
     */
    public function createPayment(RcOrder $order): RcPayment;

    /**
     * Retrieves the current state of a payment by it's processor ID
     */
    public function getPayment(string|int $id): RcPayment;

    /**
     * Parses webhook payload, returns standardized data object
     */
    public function parseWebhookData(string $json): RcPaymentStatus;
}

Then:

<?php

use RockCommerce\Interfaces\RcPaymentProcessor;

class RcStripeProcessor extends Process implements Module, ConfigurableModule, RcPaymentProcessor
{
  // Handles implementing required RC methods, API key/authentication, HTTP requests, libraries, etc.
}

Super rough sketch, but it would let RC offload webhook parsing and payment IO entirely.

Long story short, it would be great to have a way for other people adapt payment providers without you having to type another line of code 😎

 

[bernhard]

4 hours ago, FireWire said:

@bernhard Had a chance to tinker with the module today and am really enjoying it. Outstanding work on the fast and easy front end cart system!

Glad you like it! 🙂 This was really a long way until I got there and now - finally - it feels really good and solid 🙂 

5 hours ago, FireWire said:

Long story short, it would be great to have a way for other people adapt payment providers without you having to type another line of code 😎

Absolutely! I just built it around mollie because I knew them already and I trust them and when I compared prices they were even a bit cheaper than Stripe. Plus being in the EU that's another bonus for me.

But I understand that Stripe (or any other service) might be preferable for others, so I'm super happy to add support for it to RockCommerce! Just write me a PM and let's do a meeting after Christmas?