Razor Commerce Demo
What have we managed to bundle into this first version of Razor Commerce? The focus has been on making a good foundation with solid order flow, cart/checkout. Here are some of the features and the design concepts in place so far.
1) The shop main page is a regular PageList block that is installed when you install the package. It has a custom template for showing price, again that template activated on install. Later we might build a custom block type like Core Commerce does, like ProductList. For now using a regular PageList works and enables developers to use familiar override techniques. It's very easy certainly to edit the custom template for the product grid. There is no sorting or filtering features currently.
2) There is a product detail page. Razor Commerce has a custom PageType named product and a custom block for product_detail. This block is installed into the PageType Default. Developers can change the display by adding block templates. We also have plans for an alternative approach which involves individual blocks for each product display area. This would be a more advanced way to organize the product detail for example there would be a price_display, product_details, product_gallery, product_add_cart_form. These blocks can then be moved around in the PageType Default enabling a very customized layout without needing to code a template.
3) The shopping cart is almost a pixel-for-pixel copy of WP WooCommerce (WOO WOO!!) we're proud to be copycatters in this case because Woo rocks. The cart features a stepper for quantity updates, removal of items, subtotals and a continue to cart button.
4) Programming additions to cart is easy. We take the approach that the cart is a wrapper for an Order object. Every visitor on the site has an order created using their session ID. You can pull the current cart object at any time, and use the Order object to add item(s) to the user cart.
5) We have taken a stance on cart merges that by default we archive rather than merge anonymous carts. This is because it is a commonly reported problem in Magento and other systems that shoppers often mistakenly duplicate orders by shopping anonymously while their logged in user already has items in the cart. With Razor commerce if a user adds items to the cart as anonymous, then logs in, their anonymous cart becomes their active cart. If they already had a cart with items when logged in, we archive that order. Orders are almost never deleted in Razor Commerce, partly because our analytics system will compile data about abandoned orders which requires the orders to be held intact. Instead we archive carts, which also means that a cart that has been "replaced" by an anonymous cart can be restored to the active cart after the user checks out their existing cart. We will probably offer a merge cart feature if it requested, or somebody can build that as an addon but in our research we found merging carts is problematic more than it is helpful.
6) Our checkout is currently single page only. We have divided the checkout form into CheckoutPanes which are registered, we plan to make it possible for developers to easily add fields or register new checkout panes. We've made each checkout pane in Razor Commerce an element. jQuery validate is used to validate the form.
7) Razor Commerce already has Stripe integration. We'll also be providing non-transaction options out of the box like "Invoice" or "COD". PayPal is not supported currently, we're not sure we'll get it integrated by version 1 launch we kind of made the decision to invest the effort into the Stripe integration instead. Our Stripe integration is deep, we utilize Stripe customer creation and setup references between the store customer and their Stripe account which means we can offer single-click checkout for returning customers.
8) 100% of the checkout fields can be loaded from a stored user account if that user has the data available. All the data is stored using User Attributes, names, phone, address(es). Our goal is to make checkout swift, we use the Core Authentication form with a redirect back to checkout to login existing customers.
9) Razor Commerce does not require or provide customer registration, instead we automatically generate user accounts from the checkout data. I'm sure some shop owners will want a different approach because of a need to collect certain registration data, so this approach might become a configuration option later. For now we set it up the way we often see WooCommerce setup, where we generate account data automatically and email the customer their account details. The user is also logged in automatically so after they complete checkout they can see a personalized message with their orders summary, and a link to their customer dashboard.
Example of the field class:
// add field set $field->addSet( 'customer_address', 'Customer Address' ); // add field $field->add( 'billing_address', 'Billing Address', 'address' ); // add field to set $field->set( 'customer_address' );
Looking forward to you trying out Razor Commerce and coming with ideas on extensions.
Keep up the good work.
To facilitate that, please, all eCommerce developers, include an xls or csv import/export for products.
My game plan for getting around those issues is first off don't use ContentImporter, instead use the import($x) methods in Page, Area, Block directly. That way we can do some tests on the data first like checking if required objects exist, checking if the import is an add/update. Skipping areas with blocks that don't exist.
Currently the plan for Razor Commerce product importing specifically is that we'll offer 2 types of export/import - "ProductPage" and "ProductObject". ProductPage migration means the entire C5 page including attributes, areas and blocks. Now because we can't possibly deal with every block, and some blocks added to pages don't export or don't import, ProductPage migration will always be kind of a hit/miss affair where developers might have to edit the XML input to avoid errors, or use only in situations where they have some pretty good control over both the exporting and importing sites.
ProductObject importing will be the much more clean/reliable approach. We'll only export the Product attributes and it will be in a more human-friendly structure instead of the large trees from the ProductPages. The idea there is also that when you make a new site, you could build the product catalog by making XML product pages rather than using the interface. The downside to this approach however is the product pages would probably have a default pagetype, no blocks in areas, anything "extra" that was in pages would be lost if migrating from an existing site. Between the 2 options though developers will be able to choose what suits their product migrate best.
For our other objects, currently just Orders, Payments these are custom objects and I haven't given much though yet to how we'll handle them. It will be XML though, not CSV... I think we'll only offer XML from Razor Commerce Core, and if developers want CSV imports they can build packages that convert CSV imports to XML and then use the core migration package.
We also want to have migration from other systems, WooCommerce, Magento, Core Commerce. Again these would be extensions, so our focus is making Razor Commerce migration library easy to work with so whatever the incoming data is developers can convert it and then use a standard migrate interface.
The question mark on "catalog pages" as categories is whether this is too cumbersome for larger stores where you need to make 100+ categories. But then if you need 100+ categories you must have 500+ products. The other consideration is how would products go into multiple categories, aliasing?
A big issue in using a completely custom object is okay maybe it gives more control over the editing interface, but then how the products get displayed? We want to avoid the scenario where you make products, but then have to go somewhere else to make pages to display each product. Is it limiting to have each product be a page, well maybe but I think there are ways to work around that. For example if you wanted to have a page that displays 3 products like in a comparison table layout, could you do that with products as a collection? Sure, even though they are pages they can be loaded and displayed as data, we just maybe need a way to hide those products from catalog/tree if they are not meant to shown individually.
The project looks very nice!
As for the categories, have you checked the new "Topic List" feature in concrete 5.7?