Commerce is priced at €299 per license. A license is valid for one MODX installation, and includes all future 1.x upgrades and our standard email support.
Free development licenses are available for development and for trying out Commerce prior to purchasing a license. We also offer free 30-minute calls if you're looking at Commerce for the first time, and want to make sure it's a good fit for your project or not; send an email to [email protected] to request a call.
We offer discounts for non-profit organisations.
For Commerce we've set slightly higher requirements than our other extras.
It is possible to install Commerce without meeting all of these requirements right away, however you will be warned about the lacking configuration on the dashboard, and may not be able of switching the shop to live mode depending on what requirement is missing.
We'll continue providing support for SimpleCart until at least May 14, 2020, which is one year after the official 1.0.0-pl release for Commerce came out.
At that point we will evaluate how much SimpleCart is still being used and how we can best honour existing users. SimpleCart is still in use on hundreds of sites, so we're not going to pull the plug overnight, but phasing out support for SimpleCart is one of the options that will be on the table.
If you're planning a new shop now, we do recommend using Commerce. It's more powerful, more stable, and will be modmore's main focus in the coming years.
You can continue using SimpleCart for the time being; it is supported until at least May 14 2020, we stand behind it.
After May 2020 we'll evaluate the situation and determine a plan for moving forward. While phasing out support for SimpleCart is one of the options on the table, it is not the only possibility and there will be different factors to take into consideration. We're deliberately pushing out making the decision until Commerce has been stable and available side-by-side for a while, to see if there's merit to keeping both around, even if we consider Commerce the better solution for pretty much all use cases.
Not yet, but that's definitely something we're looking forward to changing. Our current billing engine is definitely due for an upgrade.
The primary reason we haven't upgraded to Commerce yet is subscriptions; as that's not yet available for Commerce we can't migrate all our payment handling into Commerce just yet. Watch this space, though..
Taxes in Commerce are quite flexible. They are organised around Tax Groups, assigned to your products, and Tax Rules that determine when a certain Rate Provider should be used.
The prices on your products can be considered either inclusive, or exclusive of taxes. When set as exclusive, the render_taxed_price snippet can be used to show the price inclusive based on the customers' country, which will evaluate your tax rules to show the same total price the cart would show.
Commerce separates customer-facing Catalog and the internal Products that it requires to calculate totals and handle orders by design.
The Catalog is your front-end. It's how customers browse through what your webshop has to offer, including product information, different variations, photos or videos, reviews, and so on. How you build this catalog is completely up to you: it can consist of resources, Collections, MIGX TVs, SimpleCart product resources, a POS or ERP system, custom tables or third party database... the possibilities are limited to your imagination (and skills and/or budget).
Products are rather simple objects consisting of a product's name, description, SKU, stock level, and price. These products are what Commerce does care about. When a customer sees an item they'd like to purchase in your catalog, they will add this Product to their cart.
It's possible to manage products within resources, separately, or integrated with something custom.
Commerce uses Twig file-based templates for its theming. The documentation has more in-depth information on how to use that, but here's the basics.
core/components/commerce/templates/with a name of your choosing*. For example
design2017. The name of this folder is your theme name.
commerce.themesystem setting and set it to the name of your theme.
default/frontend/checkout/cart.twig) and copy it into your own theme folder with the same name and directory structure (for example
myawesomestore/frontend/checkout/cart.twig). Only copy the files you've actually changed; this way you keep Commerce upgrades as simple as possible.
Do not copy over all template files, just the ones you have edited.
* It's also possible to place the template folder somewhere else using the
commerce.theme_path setting. See the documentation for more detailed information about the possibilities for themes.
No. Commerce has only one "theme" for the cart and checkout that adds a basic design to the default markup. This theme consists of two CSS files that are registered to the site header, layout.css and style.css. These are not meant to be themeable, but only offer a very basic interface for you to start from.
commerce.register_checkout_css system setting determines if these two files are loaded. Set it to 1 to load the files automatically on your cart and checkout pages, or set it to 0 to not load them.
We do offer a separate starter pack called Red. That is also meant as a starting point, rather than a fully designed shop, but comes with some more pre-configured resources and templates. Learn more about the Red starter pack here.
Most order-specific automation will happen through the status workflow that you define.
Whenever you manage an order and want to change its status, you will need to choose a Status Change instead of the new status. The status change controls the flow the order goes through from the customer going through checkout, all the way through the products getting shipped.
For each Status Change, you can add Status Change Actions that happen when the status is changed. These status change actions include sending emails to the customer or merchant, but with a bit of development you can also create status change actions that automatically print shipment labels, sends order and customer information to a CRM or ERP system, or does something else entirely.
Through these actions you can automate a whole lot of normally labour intensive tasks to ensure your fulfilment works at top efficiency.
Sure, your shop can be spread across different contexts. They'd all be served from the same MODX installation (on a single hostname) and a single Commerce dashboard. The product records would be shared across the MODX installations, but your catalog could be vastly different per context.
It's possible to use different themes per context, as well as setting up different cart/checkout pages with context-specific settings.
It's also possible to set a different currency per context (which requires context-specific cart and checkout pages), in which case you should also set up currency-specific product prices.
Only one Commerce license is needed for multi-context setups, as long as you only use one primary domain in the manager.
When we built Commerce, we made sure it was easy to extend and integrate, so yes you will be able of integrating it with any three-letter-acryonym system.
As Commerce is still fairly new, the number of ready-made integrations is still limited, but a list of available extensions can be found here.
If you'd like to commission an integration, please contact Mark via [email protected] with details to receive an estimate and information about the possibilities and availability.
It wont file them for you, but it does have reports and exports that will help you with that.
Most notably the "Tax Summary" report will present you with a summary of all orders in a specified time period and the tax rates that were charged. A detailed report with all order items and their tax rates is also available.
By default Commerce looks inside
core/components/commerce/templates/ for your theme files. If you'd like to have it also look in a different theme directory, such as
/assets/checkout/, you can specify the
commerce.theme_path system setting with the absolute path to your template directory.
When setting a theme path, you still need to create a folder inside that directory that matches your theme name as configured in
As of May 2019, the following payment providers are available:
Read more about each of the payment gateways in the documentation. The Roadmap has a list of other gateways we're planning or considering. Be sure to send us a feature request for the gateway you need if it's not listed or planned yet!
Yes. The developer documentation has more information about how to build custom shipping methods. Available ready-to-use extensions can be found here.
A true one-page checkout is not really possible, as Commerce requires information from the previous step to show the next. For example it's not possible to determine available shipping methods until the customer provided their address, and it's not possible to show payment methods before the order total is confirmed based on the chosen shipping method.
As the cart and checkout in Commerce automatically respond with JSON to AJAX requests, that is fairly straightforward to add and mostly depends on how you'd like things to look. An example one-page checkout theme can be found on the forum.
The Red Starter Pack also includes an AJAX cart and checkout.
Twig brings a more powerful templating language to Commerce. Simple conditionals, loops and includes are all possible in Twig, which would become a rather complicated set of snippets and chunks with the standard MODX parser.
As templates are stored in files, they're also much easier to include in version control compared to chunks.
The Twig for Template Designers documentation is a good starting point if you haven't worked with Twig before. It may be a bit of a learning curve at first, but if you're comfortable with the MODX templating it wont take you long to learn the Twig conventions.
Yes, to select organisations that meet our requirements we will offer up to 50% off on a Commerce license. For the process and requirements, see the Commerce Pricing.
If you're happy with SimpleCart, you can continue to use it. We'll still support it until at least May 2020, so you don't have to migrate just because we've got something shiny and new.
If you're doing a redesign or rebuild of a previously SimpleCart-powered shop, we do recommend looking at Commerce as a replacement.
Yes. Please see the documentation for full information on what's possible and what caveats to be aware off.
Yes, using the Country Validation module provided with Commerce you can set up a blacklist or whitelist of countries that are allowed to place an order. This will warn customers that their country is not currently supported when they try to place their order. See the documentation for more information on this module.
There is a basic address validation module available in Commerce which will make sure the required fields are filled in, and that the email is syntactically valid. It also checks if a valid country was selected. See the documentation here.
The module does not verify if an address is accurate (as in, does it really exist), but that can be added by extensions.
Yes, this is built-in to Commerce. When logged in users visit the checkout after placing an order previously, it will show their previously used shipping and/or billing address to reuse.
Additionally, the core-provided User Profile Address module will prefill the "new address" form with the information from the user profile. That can also update the address on their profile. This module is mostly useful if other parts of your site rely on the address on the profile being accurate/filled.
Yes, enable the Combine Products module to automatically combine products that get added to the cart multiple times into a single item.
With the separation of products and your catalog, there are many different ways you can build a multilingual shop.
With MODX, there are roughly 2 ways to handle multilingual sites in general. First is the multi-context approach, where different languages have their own context and resources. Secondly there is an integrated approach where a single context is used to serve different languages, for example with MIGX or Lingua to manage translations.
The Commerce cart and checkout use lexicons by default, so your cart and checkout will automatically use the right language if you set the cultureKey appropriately on different contexts. With integrated translations, you'll need to make sure the right cultureKey is set dynamically.
Product information stored in Commerce is not currently natively translatable, but we've seen people use custom products to fit their needs.
Yes, different ways of dealing with user accounts in the checkout are supported. You can make it required to be logged in, you can make it optional (default), or you can hide the account step completely. See the documentation for how this can be configured.
Yes, this is managed on the Delivery Type. You can set the shipping step to either be always shown, never shown, or that it depends on how many options are available for the customer to choose with their order.
The checkout automatically selects the first shipping method that is available, no matter how you configure the delivery type.
Because the shipping step is configured by delivery type, you can set different strategies for different types of products. You may for example hide the shipping step for digital products (vouchers, ebooks), while setting it to "depends" for physical products.
With the default status workflow that is created during the installation of Commerce, you'll find them in the "Payment Received" status change. Navigate to Extras > Commerce > Configuration > Statuses, and click on "Payment Received" in the middle column. It should have the bold text "Used on payment received" below the name.
In the Status Change Actions grid for the status workflow, you'll see two emails:
You can add email status actions to any part of your status workflow. There is for example an
emails/shipping-confirmation.twig template included in Commerce that can be used as part of an "Order Shipped" status change.
To manage the configuration of the email (the email addresses to use and template), you can go to Extras > Commerce > Configuration > Statuses. Click on the name of the status change that runs when payment is received, usually that's a status change aptly called "Payment Received", and you'll find the list of outgoing emails there. You can change the subject, email addresses, and content by editing the email status change actions.
Add header image and footer text
You can easily add a header image to all outgoing emails by setting the
commerce.email_header_url to a fully qualified URL of the image to use for the header or logo. This should be a full URL, including your site url. The default template (
emails/wrapper.twig) assumes the image to be 500x120px.
The text in the
commerce.email_footer_text system setting will be added to the footer of all outgoing emails and would typically need to include information about your registered address or terms and conditions. This setting can include HTML. If not set it will show the site name instead.
If you're happy with the basic configuration, you can change the text used in lexicons. By default Commerce is translated into many languages, so you should hopefully find the emails are already translated, but if you want to change the text you can do so from the MODX manager.
Changes made to lexicons in this way are persisted across updates.
The templates for emails are
emails/order-received.twig (for the customer) and
emails/order-to-merchant.twig (for the merchant). Learn more about templating in Commerce here.
By default, all address fields are optional.
Commerce ships with a Basic Address Validation module that allows you to mark which fields are required. It's strongly encouraged to enable this module on all shops, unless you have another module in place that validates the address exists.
To change the required fields with the Basic Address Validation module, navigate to Extras > Commerce > Modules and find Basic Address Validation in the list. Click its name, make sure the module is enabled, and enter a comma-separated list of fields in the "Required Fields" option. The full list of possible fields is available in the documentation. The module makes sure the fields have a value, and for email and country fields it does some additional checking to make sure it's a valid value.
You are currently viewing prices in a non-Euro currency. Please be advised that these prices are estimates, based on data by Open Exchange Rates.
While we offer this currency converter hoping our users find it convenient, all purchases are made in Euro, and the final amount charged can vary depending on payment provider, day, time of day and a number of other factors outside of modmore's control. There are no guarantees on accuracy and modmore nor Open Exchange Rates can not be held liable for errors.×