I was all geared up to talk about Kentico 12: I was going to do a folder compare of the MVC installer vs the Portal Engine installer option, see what differences there were in the admin interfaces. Turns out, there are no differences - Despite what the installer makes it look like, there aren't two versions of Kentico 12's filesystem, the MVC one just preinstalls a MVC site fro you to build on, and wires it into IIS. If you don't need that, you seem to just be able to pick Portal Engine, and when you're ready to make an MVC site just create the new site, and you won't have any missing features from your Kentico install.
That's great for upgrades, since it means there won't be separate base codebases, but it does leave me with less of a topic to talk about this month than expected.
Instead, let's look at another thing I've been looking at.
Shopping Carts!
One of the most common adjustments I have seen requested in Kentico shopping carts from clients, is making an adjustable final cart.
By which I mean, the standard process in Kentico is:
- Add items to Cart
- Fulfull shopping cart steps
- Shopping Cart becomes an Order
- Pay for order
The problem with this is, if the user has gotten to the Pay for order step, their shopping cart is gone, and the user can't adjust those items anymore - if they want to edit their order, they need to create a whole new one and re-add everything.
In playing with a few example cases, non-Kentico: Amazon, Etsy, and GOG, I can see what they mean. In all of those apps, if you get to the final step and add something, there's a way to add that item to the existing cart... Amazon just does an ajax-check every time you perform an action (but if you hit 'submit' without doing an action, it just submits the original item and not the new one). GOG just sticks to the original order as long as you stay on the order page, but it still displays both items in the cart and you can click 'checkout' to be taken to the order page for both items. Etsy does the same thing as Amazon, but without ajax: If you refresh the final page, the new item appears.
Compare this to Kentico ECommerce, where once you're on the payment step, there's no built in mechanism (refreshing, an action button, etc) that'll update that order. You have to restart the checkout process with a new shopping cart.
Based on the above inspiration, it looks like the options are, essentially,
- Create an Order object as normal but also keep that information in the Cart (until the order is completed), and be sure to refresh the Order based on the Cart - if items are added/deleted/adjusted, follow suit in the matching Order. This of course has the problem that the objects are still separate, so you have to manually sync them when displaying info to the user, and when completing the order.
- Create an Order object as normal, and lock down the shopping cart, using the Order for everything instead - you'd need to customize all of the shopping-cart-process components (add to cart button, shopping cart page, etc) to look for the Order and if it exists, use that instead of the cart. This prevents any synchronization issues, but is more complex.
- Customize Kentico to collect the payment before Kentico thinks you've completed the shopping cart process, and after the 'payment' step manually complete the order and have a dummy payment page that just submits your already-supplied data.
- Accept that Kentico is what it is, and submit an Ideas.Kentico.com idea for it.
None of the clients we've talked to about these options have actually gone through with them. The site I've seen actually pursue this on their own chose a completely different option, and managed to turn their site into an update nightmare because of it - they essentially created an entire 'persistent shopping cart' layer on top of Kentico's shopping cart and order objects, and kept it in sync with Kentico's Cart/Order throughout the process.
I want to create a test case of each of these cases, to make sure they're all possible and hopefully identify a best one, but I haven't had the time lately. I think, at least in the latest versions of Kentico, the process would be:
- For this one, give the Cart an OrderID property, and adjust any cart editing components to update the cart and the order at the same time - add to cart, the shopping cart control's delete/update fields, any Customer/cart info classes, billing/shipping, etc.
- This one sounds like much more of a pain to me - it requires the same steps as 1, except you also have to customize the *display* components, because you're actually displaying the order data itself, and you have to prevent the shopping cart from being modified when you're 'in the order'.
- The way I think this can be done most easily, is by just adding a dummy 'final page', and having a modified payment form (that doesn't try to look at a completed order) on the penultimate page, and save the form info so that it runs on load of the final 'step' page, which would just look like a 'thank you' page instead.
- You'd have to figure out PCI compliance, since you're ever-so-briefly storing credit card information serverside (whether in-memory-only or otherwise), but aside from that that would keep it as a shopping cart (and therefore, adjustable) until the Submit of the final step.
- You'd want to have a test on the payment page's onsubmit to make sure that they didn't modify the order in another tab, like a hash or something (If they did, you should let them re-confirm so they don't accidentally order the wrong things)
- But even all that is probably easier than 1 or 2.
- There's some good arguments for 'don't let the user do this - once they're paying for an order, they're paying for a specific order they've created, don't let them adjust it while paying'. But clients want what they want, and 'most large sites seem to not have this restriction' is a pretty solid argument. Good luck with this option.
Has anybody tried to do this, either by one of the options above, or a different way?