Sankuru

Functional areas in Virtuemart

Virtuemart is a webshop. Therefore, it roughly has to do the following things:

• Organize a product catalog, in terms of categories, embedded categories, and product records.
• Manage shopper records, organized in shopper groups, usually, with each such shopper group, different commercial terms, of which most importantly, the product prices to which they have access.
• Implement a cart in the session. From the product catalog, the shopper can "add to cart".
• Implement checkout pages, to collect shopper billing and shipping address data, choice of shipping, and start the payment process, usually at a remote payment processor, such as paypal, sagepay, et cetera.
• Implement order processing, in which order status follows a workflow from pending, confirmed (usually meaning: "paid"), to shipped, while handling exception statuses such as cancelled and returned. Optionally, the application will send an invoice to the shopper, prepare delivery notes and other shipping documents.
• The typical entities collected in a webshop are: product, shopper, order, payment. It is commendable to interface these records to the financial accounting application that the shop owner uses to manage his overall business.

Joomla 1.6 will implement support across the board for concepts that are now redundantly implemented separately in Virtuemart.

Massive code duplication in Virtuemart after Joomla 1.6

Virtuemart used to do everything by itself. Now, it should tap into the power that Joomla 1.6 will be offering.

The product catalog should become Joomla content items

In its 1.1.x series, the Virtuemart product catalog is a separately implemented repository of categories and product records. In J1.5, it would indeed not have been possible to implement the product catalog in terms of Joomla categories and Joomla content articles. These concepts were simply not sufficiently extensible in J1.5.

In J1.6, it will be perfectly possible to implement a product catalog in terms of Joomla categories and the new, extensible Joomla content items. Therefore, the entire source code tree managing and rendering the Virtuemart product catalog will have become redundant and obsolete.

The new J1.6 subtemplate system makes the Virtuemart theme system completely redundant and obsolete. Styling will now finally be completely integrated across Joomla and Virtuemart.

Shopper records should  become extensible Joomla user records

Again, the totally rigid user management in the Joomla 1.5 series, with its notorious lack of support for ACL (Access Control), will finally morph into extensible user records in Joomla 1.6. It is not just Virtuemart that will be affected. For example, half the code base of Community Builder will also become obsolete.

There will no longer be a need to implement shopper records and shopper groups inside the webshop. Joomla 1.6 will allow you to configure that, without having to write any significant additional source code. Therefore, the entire source code tree managing Virtuemart shopper and shopper group records, will have become redundant and obsolete.

As soon as Joomla 1.6 becomes available, and as soon as Virtuemart is able to tap into the Joomla 1.6 support for its product catalog and shopper record management, these parts will automatically benefit from any improvements made by the Joomla team to the overall CMS.

In my impression, a Virtuemart component  refactored in this way, will blow the competition out of the water. The competing cart systems such as Magento, OSCommerce, or ZenCart, will no longer compete against Virtuemart in these areas, but against Joomla itself. Every improvement made to Joomla will automatically lift Virtuemart further ahead of the competition.

The cart stays entirely within Virtuemart

The cart is indeed the central specialized, functional concept of a webshop. It is small in source code footprint, but it is absolutely essential. It will remain so in Joomla 1.6. It is also the Virtuemart building brick on which the core Virtuemart development team should focus. This part is the one that most prominently sets webshop apart from the competing alternatives apart.

There is no need to add features to the existing Virtuemart cart, but there is definitely a need to make it more extensible and more pluggable. For example, implementing a custom promotion plugin ("Buy one get one for free!") in Virtuemart, currently requires hacking the cart's source code to no end.

Where are all the hooks that should be there, to plug in custom features? Where are the onCartProductAdded and onCartProductRemoved hooks? When is the core Virtuemart team finally going to add these two hooks?

Again, it is not the lack of features that is a problem in Virtuemart. We do not need Virtuemart to become some kind of unwieldy copycat of the master of bloated obesity and featuritis, Magento.

Just adding hooks in strategic places in the Virtuemart cart's source code, will be enough to lead to the emergence of an entire repository of plugins that will collectively blow all other cart systems out of the water.

The checkout process and JForm

The checkout is a configurable wizard leading the shopper through one or more forms, in order to collect address data, shipping option chosen, payment option chosen, and send the shopper on to the remote payment pages of Paypal, SagePay, 4B, Moneybookers, or any other payment processor chosen.

Joomla 1.6 will implement an extensible JForm class that will natively support user form input all across joomla. This will also make large swats of source code redundant in the existing form components, such as Fabrik, Breezeforms, Chronoforms, and many other alternatives. They all redundantly implement their own version of JForm, which has now become obsolete.

Just like the forms components, Virtuemart will also be able to throw away large stacks of source code files, which today implement support for the checkout forms, but will become redundant in Joomla 1.6.

Order processing stays entirely within Virtuemart

The order list part in Virtuemart is where the warehouse staff of the webshop get their data to proceed with picking, packing, and shipping. It is a small but essential functional element in the webshop. This is where the order confirmation email, status update notification emails, notifications by sms, pdf invoice emails, and other order processing artifacts get produced within the workflow it implement.

Again, we need more hooks here. Extension developers should be able to add plugins onOrderStatusChanged. Now, we need to hack the core source code for this. It has to stop. We really need our onOrderStatusChanged hook to trigger the custom procedures the webshop owner wants.

Interfacing requires the emergence multi-disciplinary teams

Users want their Quickbooks, Great Plains, SAP, OpenBravo, OpenERP, or other tools to do their financial management; and they want Virtuemart to interface its product, shopper, order, payment, and invoice records to these systems. That is what they all want.

In order to meet these demands, we need to map the Virtuemart entities to their counterparts in these financial management systems. What is lacking today, are the experts in the counterpart financial systems, who are interested in working with people from the Virtuemart world, in order to make it happen.

One way to facilitate the emergence of multi-disciplinary teams, would be to have at least a (virtual) meeting place:

• Virtuemart -- Quickbooks
• Virtuemart -- SAP
• Virtuemart -- Great Plains
• VIrtuemart -- OpenBravo
• Virtuemart -- Et cetera

This would allow people from the Virtuemart world and people from the financial counterpart world to meet and discuss on how to go about interfacing, and finally meeting the user demand for this.

Virtuemart versus Magento

By tightly integrating with Joomla 1.6, Virtuemart will be a much smaller, but at the same time, much better Virtuemart than before.

Rather sooner than later, Magento's everything-but-the-kitchen-sink approach will start crumbling under their massive EAV (database within a database) spiralling complexity and database performance problems.

Furthermore, there is absolutely no need whatsoever, to match Magento feature for feature. It would be the wrong strategy. It is the Virtuemart Extension Repository that should match and exceed Magento feature for feature.

As I argued above, core Virtuemart does not need more features at all. On the contrary, it needs substantially fewer features. The way to move forward, is not to add more features, but to add more hooks through which the extension authors from the Virtuemart Extension Repository can add the features, the user base is clamouring for.

Conclusion

By implementing the right strategy, and by preparing for Joomla 1.6, the Virtuemart core team can attain several commendable goals:

• Substantially reduce the Virtuemart source tree's size.
• Benefit from Joomla's increased extensibility to make Virtuemart also substantially more extensible.
• Finally start adding hooks that Virtuemart extension developers have so long been clamouring for, and finally increase Virtuemart's own extensibility.
• Stop adding features, whistles and bells to the Virtuemart core, but instead, manage a third party extension repository comparable to the Joomla JED (Joomla Extension Repository)

Joomla 1.6 will create a fantastic opportunity to make Virtuemart more competitive, and to drastically improve Virtuemart's ability to take on the competitive threat from Magento, ZenCart and others.

The Magento team, however, will have to keep going it alone. There is no CMS team covering their back. At the same time, Magento will have to address the consequences of their past strategic design mistakes.

Therefore, in terms of timing, Virtuemart is now perfectly positioned to implement the strategy that will make it gain the top spot, and confirm the leading position it rightfully deserves in the webshop world.