Orchard Core support

[bleroy]

The question of e-commerce modules for Orchard Core pops up regularly. I created the orchard_core, where folks can make pull requests for this work.

Let's use this issue to track the work and establish priorities.

The minimum viable feature set is:

• Product part
• Shopping cart
• Checkout
• Base infrastructure for payment, plus one implementation (Stripe)
• Order content type and management screens
• Workflow activities

After that, we can start porting:

• Base infrastructure for shipping, plus one implementation (TBD)

[MatteoPiovanelli-Laser]

Hi, I have not touched Orchard Core much, and not at all recently.

Having coded on Nwazet for O1 quite a bit I have a few opinions:

• ProductPart as is has too much stuff in itself: for example, I don't think that Price and Inventory belong there, but they should rather be separate components (likely parts) that attach there as needed. I think that ProductPart should only have a SKU, and probably no other property.
• The payment infrastructure should come with a "null" payment implementation, for store that "sell" products for free.
• OrderPart right now is I think too complex and rigid: making changes and additions to it from other features is troublesome.
• Globalization: B2C ecommerces in the EU should display final prices (including tax); B2B ecommerces in the EU sometimes may not; B2C ecommerces in the US display price before tax, because taxes there change on a state-by-state basis. And this is just an example I know.
• The checkout process should have easy ways to inject behaviour between steps (e.g.: you changed your address, so we must recompute taxes; we have an inventory integration, so right before payment I check the items are still available), or even inject steps (e.g. select gift wrap).

These are just off the top of my head.

[Skrypt]

It is common to have a different catalog of products per region so yes, I agree that price should not be attached directly to a product. Same goes with inventory for the same reason. Normally B2B requires the users to login to display prices mainly because you want to have different prices per retailers/business and also because a B2B should never sell to simple customers. You don't want to be a competition against your own retailers by displaying a lower price (wholesale price) than what's the standard retail market price. On B2B websites you will often instead see : "suggested retail price : $99.99 USD".

[bleroy]

That's great feedback and a good opportunity to get those right. The module was initially designed for a small-to-medium US-based business, so this sounds like a good re-calibration of the requirements. We do have multiple prices available in the current version, through extensions that have been added over time, but a re-foundation seems to be in order. Shall we build some abstractions around pricing, and let implementers of those abstractions provide their implementation? We could still ship those with a default single price implementation that corresponds to the current behavior. I suppose in light of the suggestion to have a null payment option, this would go hand in hand with a null price provider (no need to provide a part for that, I think).

OrderPart: can you detail what the problems are and suggest a solution?

Checkout: do you think using workflows more generously for this process could help?

[petedavis]

As another idea to help getting started with the module. Nwzet.Commerce could have an OrchardCore web project that can be run from the repository, and a recipe that can be used to have a basic configured store with some test widgets. That way you could see the module in action by just checking out the code from github and running the web project just like the blog and agencey demo sites in the Orchard Core repo.

[MatteoPiovanelli-Laser]

Price for products: I agree with @bleroy regarding having price abstractions, and I also agree with the fact that a part for price is not needed by default. I also think that such abstractions should support different ways to interact with price there, for example by "injecting" discounts and such. We should also be able to have several implementations available on a tenant: for example, I may need a basic price on some products, and tiered pricing on others. Price abstractions should also be able to "interact" with the shopping cart and the checkout process.

OrderPart: My issue there is basically the same I have for ProductPart: I think too much information is being stored in a single object, and I'd rather see it spread around in more. For example, it has credit card information, but a payment may involve no credit card. There are workarounds and ways to handle that, as I did in the VAT PR where I added an interface to add stuff to the table being displayed in the order view. I think those that currently are workarounds should really be the norm, and we should have the most basic order objects, with all the other info being tacked on them.

Checkout: I think the nicest thing would be a chance to design/configure it as a "workflow". Meaning, different features may provide something similar to workflow activities that can be combined together to build the checkout process for the shop. This concept is still embryonal in my head, so I can't explain it clearly.

[khoshroomahdi]

checkout should be modular to support different ways to pay in every region.

[jeffolmstead]

@bleroy do you know if this discussion has proceeded? I have utilized this tooling on Orchard Project and loved it / extended it and am now looking at Orchard Core as primary platform to move forward on. I am wondering whether you think it would be harder to fork off this existing platform or simply set up a new repository for Orchard Core. I would like to keep under collaboration with Nwazet.Commerce, it is just that some of the above changes are significant enough I am wondering if it will be more of a hassle being a fork rather than a fresh start which borrows code from this current module where appropriate. Look forward to thoughts.

[bleroy]

Hi Jeff, I appreciate your time and efforts as usual. As far as I know, nothing really happened after this conversation, but I would be more than happy to help in any way I can within what little free time I have.

My current opinion would be that given how different Orchard Core is, it is probably going to be faster to start clean and build the MVP in a new repo. That's not to say there won't be code re-use. There should be a lot of that, but I would rather move stuff carefully onto a clean slate than the alternative. It's also the opportunity to re-think some assumptions like has been started on this thread.

[jeffolmstead]

Excellent, completely in agreement then. Now just the methodology:

1. Who will set up the Repo
2. What will the Repo be called

As for who will set it up, I am fine with anyone in this thread heading up the Repo, lot of great minds here. I can set up a repo though I am not the best organizer, better contributor.

As for the name, is it wrong to call it Orchard.Commerce? I am always a little hesitant using the name Orchard in a module because that confuses new users who think it is part of core. I don't think calling it Nwazet.Commerce will work due to confusion with original Orchard module (though maybe Nwazet.CoreCommerce or something like that).

[Skrypt]

Right now working on Orchard Core Beta 3 is taking most of my time but I'm pretty sure I will contribute to this module since I will require it eventually. I have nothing against Nwazet but if we restart from a clean module I'd rename it OrchardCore.Commerce. Noisette? Nutcracker?

[bleroy]

OK, so it's done. You're going to love it. I had a quick chat with Sébastien, and boom: https://github.com/OrchardCMS/OrchardCore.Commerce

Jeff, Matteo, and Jasmin, you have commit rights.

[jeffolmstead]

Sweet! Game on. Now to get organized...

[bleroy]

Added a readme to establish the goals of the project, and explain the temporarily empty repo... LMK if I missed something, and feel free to edit as necessary.

[MatteoPiovanelli-Laser]

Are we moving the discussion under that repo then? And are we working off orchard core's dev or master?

[bleroy]

At some point, yes, we should. Good question about the branch. I'd say master, and if you ever need a dev feature, do it in a clearly-marked branch. What do you think? Do you have something specific in mind that would be better with dev?

[MatteoPiovanelli-Laser]

I was just asking. I haven't played with core in ages. I'll spend a few nights getting back into it, then I'll have a better idea of what is going on.

[Skrypt]

I'm not sure about master branch. Some people have reported that it was not stable. I'd prefer that we just fork dev branch and just rebase/merge when absolutely necessary. There's a lot of changes in dev that happens that would take a lot of time to get otherwise too.

[jeffolmstead]

@Skrypt has hit on a concern I had too with master, the framework is developing so fast at these early stages that if we don't at least start out targeting "dev" we will be playing catchup all the time. Does that cause us an issue down the road as to what version of Orchard Core particular releases are targeting?

[Skrypt]

As long as we are not RC there's no real version to worry about I think. Normally OrchardCore.Commerce version 1.0 should target OrchardCore 1.0. Everything before that is development and should be expected to be less stable. Though, depending on when we will start implementing this module; I'd say it would be maybe safer targeting master when Beta 3 will be out. But for now I think dev branch should be the go to since we are closer to Beta 3 than Beta 2.

[bleroy]

Yes, you're right. I checked with Sébastien, and he confirmed dev is the way to go.