Joomla! VirtueMart 1.1 Theme and Template Design

By Joseph Kwan
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. The VirtueMart Engine

About this book

VirtueMart is the best shopping cart solution around for the Joomla! CMS. A VirtueMart template is a Joomla! template that is designed to create the overall look of a store. It puts in things such as a shopping cart bar, more shop-like graphics, more readable colors, and so on. A VirtueMart theme only impacts the area of the site actually controlled by the VirtueMart component. Themes work inside the overall framework. Applying custom templates and themes to give a unique look and feel to your VirtueMart web store will really attract customers! This book will guide you to build VirtueMart custom themes and templates.

Joomla! VirtueMart 1.1 Theme and Template Design explains how the VirtueMart theme and template system works and points out ways to configure the default theme. It then goes on to look at each of the major templates with an emphasis on how to customize them. It then discusses individual page groups such as product list, product details, shopping cart, checkout, and invoice e-mails in the order they appear to your customer. After-sale services like invoice e-mail, account management, and order list are also discussed.

The book also discusses the different components of a VirtueMart theme and will teach you how to build a theme from scratch. You will also learn advanced features like child products, advanced attributes, custom attributes, and product types. Topics like integration with Joomla! plugins and AJAX functions are also included. An Appendix provides a comprehensive template reference of the use and available fields of every template.

Joomla! VirtueMart 1.1 Theme and Template Design is a practical guide for all those who want to make VirtueMart work for them. It will put many advanced features of this popular open source e-Commerce application at your finger tips.

Publication date:
May 2011


Chapter 1. The VirtueMart Engine

In this chapter, we will briefly review the Joomla!/VirtueMart file structure. We will then continue to explain the presentation framework of Joomla! and VirtueMart. A high-level view of the VirtueMart engine will be presented and we will see how the VirtueMart theme and template fits in the whole system. After that, we will be able to understand the various ways to customize the VirtueMart shop and provide a list of items we need to consider before heading on a customization project.

Briefly, in this chapter, we will cover:

  • Navigating through the Joomla!/VirtueMart directories

  • Structure of the Joomla! URL path

  • Joomla! presentation framework

  • VirtueMart presentation framework

  • Roles of VirtueMart themes and templates

  • Ways to customize VirtueMart


Navigating through the Joomla!/VirtueMart directories

You should have a Joomla! and VirtueMart e-commerce site installed somewhere to follow through the rest of the book. If not, you should now install one first before reading on. From this point onward, we will assume that you can access a Joomla! VirtueMart site and can freely browse its content, either on your local computer using the file manager of your operating system or in a web server somewhere using an FTP client program. To work on the exercises, you should also be able to edit each of the files.

OK. Let's start our study by navigating through the Joomla! directories. If you look at the root of your Joomla! site, you will be amazed how large the Joomla! project is. There are totally close to 5,000 files under some 350 directories! It would be difficult to find your way through this vast structure of files, if there are no hints at all. Fortunately, Joomla! has a very good directory structure and will be easy to follow once you know its basic organization. Knowing your way through this vast structure is very important when embarking on any VirtueMart customization project of considerable size. The good news is that usually we only need to know a very small fraction of those 350 directories and 5,000 files, in particular, within the scope of this little book.

In the Joomla! root, the most important directories we need to know are the administrator, components, modules, and plugins directories (This does not mean that the other directories are not important. We highlight these few directories just because they are the directories we will reference from time to-time in this book) You will probably recognize that the last three of these shortlisted directories correspond to the three major extension types of Joomla! So within these directories, we will expect to see a series of subdirectories, each of which corresponds to an extension installed in the Joomla! framework. This is exactly the case, except for the plugins where the directories are arranged in terms of their type instead of their source.

Let's take a closer look at one of the most important components that comes with Joomla!. Navigate to the components directory and open the subdirectory com_content. The com_content component is the one that manages articles we created in Joomla!. You have probably been using a lot of this component. Within this directory, you will find a number of files and a few subdirectories. We notice there is a file named controller.php and two subdirectories named models and views. We will have more to say on these in a moment.

Let's move back to the root directory and take a look at the last important directory mentioned above. This administrator directory mimics the root directory in many respects. We see that most of the subdirectories we found in the root have a corresponding subdirectory within the administrator directory. For example, we find subdirectories named components and modules within the administrator as well. As we know, there are two main sections of a Joomla! website, also known as the frontend and the backend. The root directory and administrator directory are respectively the location where the frontend and backend files are located. While this dividing line is not rigid, we can use this as a guide when we want to locate a frontend or backend file. Since both the root and the administrator directories contain a subdirectory called components, to avoid ambiguity, we will refer to them as the root components and administrator components directory, respectively.

Now, let's work our way a little bit down the directory tree to see how VirtueMart fits into this framework. Within the root components directory, you will see a subdirectory called com_virtuemart. Yes, this is the location where you can find all the files used by VirtueMart for the frontend. Under the com_virtuemart directory, among some other files and subdirectories, you will notice a themes subdirectory. You will find each of the VirtueMart themes you have installed there. The themes directory is the major work area throughout this book. From now on, we will refer to the com_virtuemart directory under the root components directory as the root VirtueMart directory or the frontend VirtueMart directory.

Within the administrator components directory, there is also a subdirectory called com_virtuemart where the backend VirtueMart files are located. Under this main directory, there are four subdirectories named as classes, html, languages, and sql. Obviously, these directories will contain, respectively, the class files, HTML files, language files, and SQL (also known as database) files. Actually, the classes and html directories have a deeper meaning than their names suggest, as we shall see in a moment.


Structure of the Joomla! URL path

Before leaving our high-level exploration of the Joomla! tree structure, let's digress a little bit to study how a Joomla! URL is built up. While the Joomla! directory structure is so complicated, the URL used to access the site is much simpler. Most of the time, the URL just starts with index.php?. (If you have a Search Engine Friendly or SEF system enabled, you should turn it off during the development and testing of your customization, or at least turn it off mentally while we are talking about the URL. You can turn off SEF in the Joomla! Configuration page.) For example, if we want to access the VirtueMart (frontend) home page, we can use the following URL:


Similarly, the URL


will bring up the VirtueMart backend control panel, if you're already logged in. All other Joomla! URL, in fact, work in the same way, although many times you see some additional parameters as well. (Don't forget to replace your_joomla_live_site in the above URL with your domain name and the Joomla! root directory, in case the site is not installed in the root.)

Actually, the index.php script is the main entry into your Joomla! site. All major requests to the frontend start from here (major requests only since there are some other entry points as well, but they don't bother us at this point). Similarly, all major requests to the backend start from the file administrator/index.php. Restricting the entry point to the site makes it very easy to control authorized and unauthorized accesses. For example, if we want to put the site offline, we can simply change a configuration in Joomla! and all components will be offline as well. We don't need to change each page or even each component one-by-one.

Understanding the structure of the Joomla! URL is pretty useful during the development and debugging process. Sometimes we may need to work on a partly live site in which the Joomla! site is already working, but the VirtueMart shop is still under construction. In such cases, it is common to unpublish the menu items for the shop so that the shop is still hidden from the public. The fact that the menu item is hidden actually means the shop is less accessible but not inaccessible. If we want to test the VirtueMart shop, we can still type the URL on the browser by ourselves. Using the URL


we can bring up the VirtueMart home page. We will learn some more tricks in testing individual shop pages along the way of our study of VirtueMart themes and templates in this book.

One simple application of what we learnt about the URL can be used when customizing Joomla!. When working with VirtueMart projects, we will need to go to the VirtueMart backend from time-to-time to modify the VirtueMart settings. As we all know, after logging in, what we have on the browser window is the control panel page. We will need to point to the components/virtuemart menu before we can open the VirtueMart backend home. This is not a complicated task, but will be very tedious if repeated every time we log back into the site. Can we make Joomla! smarter, to open the VirtueMart home by default when we log on? Yes, we can. The trick actually relates to what we talked about so far. If you want to customize Joomla! to open the VirtueMart backend by default, you can stay with me for the following warm-up exercise. I understand some of you may not want to change the default login page. Feel free to skip to the next section directly if you want to, as this exercise does not relate directly to the rest of this book.

Exercise 1.1: Making the Joomla! backend default to VirtueMart

  1. 1. Open your favorite text editor. Navigate to the Joomla! site root.

  2. 2. Open the file administrator/includes/helper.php.

  3. 3. At around line 44 (the actual line may vary from version-to-version), change the code $option = 'com_cpanel'; to $option = 'com_virtuemart';

  4. 4. Save the file.

Open your browser and log in to your Joomla! site. Alas, you should see the VirtueMart control panel instead of the Joomla! control panel.

This simple exercise demonstrated that sometimes a useful change does not need complex coding. What we need is a little knowledge of how things work. I bet you probably understand what we have done above without explanation. After login, Joomla! will automatically go to the default component, hardcoded in the file helper.php. For standard Joomla!, this will be the com_cpanel component. In Exercise 1.1, we have changed this default backend component from com_cpanel to com_virtuemart. Instead of VirtueMart, we can certainly change the default to other components such as community builder or MOSET.


Joomla! 1.5 presentation framework

Since VirtueMart is a Joomla! component, it cannot exist outside Joomla!. So before diving into the detail of the VirtueMart engine, it pays to take a brief look at how Joomla! actually works. While an understanding of the presentation framework of Joomla! and VirtueMart may be useful for themes and templates development, it is not essential for the actual customization design. In case you don't want to bother with the detail of Joomla!/VirtueMart engine, feel free to skip to the section Roles of VirtueMart themes and templates. (For those more practically oriented readers, you can even skip directly to Chapter 3, Product List Templates, as you can always come back to these theoretical discussions afterwards.)

Joomla! emerged from version 1.0 and later developed into 1.5. In this upgrade, Joomla! has been basically rewritten from the ground up. A presentation structure called Model-View-Controller or MVC has been adopted in Joomla! 1.5. While a detailed explanation of the MVC structure is out of the scope of this book, a basic understanding of its working will help us understand why and how VirtueMart 1.1 behaves in the way it is right now.

Joomla! is a web application. Each page of Joomla! is in fact a text file consisting of HTML code. Depending on the detail parameters of a web request, Joomla! will generate a dynamic HTML page by combining data stored in the database and site configuration data stored in various PHP files. In the early history of dynamic web pages, program code were written in a way that HTML tags are mixed with presentation logic in one place. The spaghetti code, as it is sometimes called, makes maintenance and extension of the coding very difficult. As the basic structure of a dynamic web page is better understood, more and more new coding patterns emerge to make the life of a web developer easier. The MVC presentation framework is one of those patterns that have been proposed to build computer applications. This framework has gradually become the standard pattern for building web applications and has been adopted by many open source web projects.


In the MVC presentation framework, the job of building a web page is divided into three main tiers. The backend tier is the data that is stored in the database (strictly speaking, there is no prescribed data storage format though a database is a natural way to manage the data). We need to grab data needed to build the web page. This tier of the job is done by the Model, which describes how data is stored and how data can be retrieved from the data server.


The frontend tier determines what and how data is presented on the browser. This is the job of the View. For a given dataset from a Model, there can be many different ways to present the data. Let's say, we have a set of statistical data, for example. We can present this data as a bar graph or a pie chart. Each of these presentations is called a View of the same Model.


Now statistical data is just a set of numbers. How can we convert them into a bar graph or a pie chart? That is exactly how the Controller comes into place. A Controller is a routine specifying how to convert the Model into various Views. One major advantage of this separation of data (Model) and presentation (View) makes changes to the application much easier. We can change the presentation independent of the underlying data and vice versa.

So, in the Joomla! 1.5 world, we will have a set of Models which interface with the database, a set of Views to tell the browser how to present the data, and a set of Controllers that control how to convert the Model into the View. According to the best practice, all Joomla! 1.5 components should follow this same structure. Thus, each Joomla! 1.5 component should have two subdirectories called models and views. Also, the root directory will contain a controller.php which extends the Joomla! controller's capability. This structure is revealed as we look at the contents of a Joomla! component which we had done previously. However, because of historical reasons and others, not all components follow this best practice. VirtueMart is one of those exceptions.


VirtueMart presentation framework

VirtueMart 1.1 was conceived during the time of Joomla! 1.0.x when the MVC structure was a new introduction to the computing world and was not yet widely adopted. In particular, why Joomla! ultimately decided to pick the MVC as its presentation framework is not clear at the time. However, the VirtueMart development team already understands the importance of structuring the web page building process, especially on the separation of data and presentation. Actually, this concept has been used in VirtueMart 1.0.x, although it is not implemented as fully as in version 1.1. Without a standard framework by then, they chose a very similar structure with three data, presentation, and controlling tiers but different nomenclature. Of course, the detailed working of the structure has many differences from the MVC framework, especially from a theoretical point of view. Nevertheless, this presentation structure works on the three-tier structure without a well-defined name for each of the tiers. So, you may not find these tiers named explicitly in the official VirtueMart developer documentation. However, the presentation framework still adheres to a close pattern as a Joomla! 1.5 component.

The class files - Data tier

In the VirtueMart world, data manipulation is the responsibility of class files located in the classes subdirectory, which we looked at briefly while navigating through the Joomla! file structure. The class file starts with a prefix ps_ (probably derived from the historical name phpShop) followed by the data name. Let's go back to the VirtueMart file structure we've been looking at in the first section of this chapter. Navigate to the classes subdirectory under the VirtueMart administrator directory. You can see a lot of files starting with the ps_ prefix. Most of these files define a class in the data tier of VirtueMart. So you will expect the ps_product.php file to handle the product data, ps_shopper.php to handle the shopper data, and so on.

The templates files - Presentation tier

On the other end of the framework is the presentation tier, which is responsible to send back the HTML to the browser for display. VirtueMart 1.1 adopted a very flexible template structure where the major HTML code is separated from the data and processing logic. These template files are placed in the frontend VirtueMart directory and have been grouped into sets under the structure called theme. A VirtueMart theme is basically a collection of template files which control the frontend look of a VirtueMart shop. Thus, you can compare template files to a similar structure like a Joomla! view. Different template files will present VirtueMart data in different ways. For example, you can change the product listing page of the shop from a vertical list of items to a tabular view of items by simply changing one of the templates. For an example of how this can be done, you can refer to Chapter 3, Exercises 3.7 and 3.8.

The page files - Business logic tier

So far, we haven't touched on the processing logic where data is converted into the presentation. In VirtueMart, we do not have controllers. Instead, the processing is done in the page files located within the html subdirectory under the VirtueMart administrator directory. All the page files are named in the pattern of {module}.{page}.php where module is a section of functions in VirtueMart, as we explained in the introduction.

Before we carry this similarity too far, it should be noted that VirtueMart is not actually implementing the MVC framework. So it deviates from this separation of data and presentation principle from time-to-time, as we shall see. Many times, the output of HTML code mingles with the data processing logic in the class file, making customization very difficult.

Let's look again at the real VirtueMart administrator directory for more insight. By navigating to the html subdirectory under the VirtueMart administrator directory, we can see a lot of files named in the pattern {module}.{page}.php. We see, for example, files such as shop.cart.php, shop.browser.php, checkout.index.php, admin.show_cfg.php, and so on. .php of course is the file extension which tells us (and also the operating system) that this is a PHP script file. {module} is the name of a VirtueMart module. {page} is the page name within the VirtueMart module. From the name shop.cart.php, we know this page belongs to the shop module and has a page name cart. Actually, this is the PHP script responsible for the processing of the shopcart page. Similarly, shop.browse,php will control the processing of the browse page, also part of the shop module. On the other hand, checkout.index,php will control the major logic of checking out. checkout is another module in VirtueMart and the name index suggests this is the starting page for the checkout process.

With all the background information, we will be able to appreciate the importance of themes and templates in the VirtueMart engine. When you type a VirtueMart URL on the browser (that is, URL that consists of index.php?option=com_virtuemart), the browser will send the request to the Joomla! site. After some initialization and routing code, the Joomla! engine will feed the request to VirtueMart for rendering the main part of the page.

The first thing VirtueMart will do is the section of initialization, including loading some basic classes, setting up the session, checking the permissions of the user, and so on. It will then check whether the request includes a pending function that needs to be done. If there is any, it will invoke the function before processing the page.

After the function is complete, VirtueMart will pass the processing to the HTML page (for example, shop.cart) requested. The page will load the relevant data using the appropriate class file, combining it with the session and/or configuration data already loaded. All necessary data will then be fed into the relevant template file to generate the HTML code that needs to be passed back to Joomla!. After a further filtering process by Joomla!, the HTML code will be sent as a response back to the browser for display.


Roles of VirtueMart themes and templates

It should be clear by now that template files control the HTML display on the browser. So the color, font style, font size, data field arrangement, and layout are the major jobs of a template. By invoking a different template file, the browser display will look very different. Depending on the nature of an HTML page, the final HTML code may be generated by one or more template files. The product detail page (usually referred to as the flypage), for example, makes use of several template files and its appearance will change when any one of the templates change. We will work on the details of this in Chapter 4, Product Details Templates.

Since the final look of a page may vary with a group of template files, it is important that the templates are consistent with each other. Mix and match of various template files may work sometimes, but will definitely seem not so well-organized and professional. Furthermore, the output of a template also depends on various configuration settings of VirtueMart. So there is a need to group the template files into a full unit. Each of these full units is named as a theme in VirtueMart.

The original intention of the template system is to separate processing logic from the final presentation. So you will find that most of the templates only take care of presentation, that is, the look of the final browser page. However, as highly diversified customization demands come up, more and more processing logic is introduced into the template. Initially, the processing logic is added by amateur developers into the template because they are not aware of the importance of separating the data from presentation. However, soon even professionals will find it necessary to place some processing logic into the template file when they do customizations.

There are two major reasons to introduce logic into templates. The first one is to restrict the changes made to the core files. Often, when processing logic changes, the presentation will need to be changed to make use of the new logic. So each change will involve both the processing logic in the HTML file as well as the presentation code in the template file. Putting the processing logic in the template will avoid the changes in the HTML file and thus reduce the number of modified files.

The second reason for putting processing logic into a template is for backward compatibility during version upgrade. As the major role of template files is for presentation, essential changes to the template are less frequent than the HTML pages. This is especially true for security upgrades. Template files are less prone to security problems and compelling changes are usually not needed. Restricting changes just to template files will affect customization less during version upgrade.

Due to the need for restricting changes to within the template file, VirtueMart even introduces a new way to extend the core functions using theme starting from version 1.1.4 onwards. In the previous section, we explained that the ps_ class files in VirtueMart handle most of the data logic. From version 1.1.4, all the ps_ class files can be overridden using a custom-built class file by putting that custom-built file in the theme directory. A new configuration item is added to VirtueMart to enable the new feature. This means that in case we need to modify or introduce new logic to the data model, the modifications can be done through a custom file in the theme. Since these custom files are not core files, they will not be modified during version upgrade. The new feature thus helps to reduce the impact of version upgrade on customization. Unfortunately, this feature only applies to class files, but not to HTML files. So, in case you need to change the processing logic, you cannot override the HTML file using a theme. Instead, you will either need to overwrite the HTML file with your changes or place the logic in the template file, if that is an option.


Ways to customize VirtueMart

Basically, there is an infinite number of ways to customize VirtueMart. This is in fact the beauty of using an open source shopcart system like VirtueMart. As we have seen, extensions to VirtueMart are welcome by the development team themselves. That's why VirtueMart has been built in a way to enable easier customization. Nevertheless, there is a range of complexity in customizing VirtueMart. While there may not be a definite limit on the customization possibilities, whether a VirtueMart customization project is advisable will be tightly coupled to the cost of its implementation. If the cost of customization is more than building a brand new shopcart, for example, there is no point in pursuing the customization.

That being said, there are still lots of customization possibilities that are worthwhile and is within the reach of an average designer who may not be comfortable working with PHP code initially. So let us have a look at the ways we can extend VirtueMart.

Textual changes

Sometimes you just want to change the text that is displayed on a certain page. This is especially the case when you are using VirtueMart in a different language environment. VirtueMart does come with several language files, but the translation may not suit you. And even when your site is totally English, you may still want to replace a text or two to fit your client's or your own shop's specific needs. There are two ways you can do this.

On one hand, you can modify the language file that comes with VirtueMart. This will involve finding the appropriate language file that contains that specific language element you want to change. VirtueMart language files are placed in the languages subdirectory of the VirtueMart administrator directory. The language files are further subdivided into modules, with each language having its own .php file. You should first look into the common subdirectory where language elements used in more than one module are placed. Open the language file in an editor and search for the text you want to change. If you cannot find it in the common subdirectory, you need to look in the individual module directory. For example, if you need to change text on the browse page, then you will look into the shop subdirectory to see if you can locate that language element, since the browse page is controlled by the shop.browse.php file and so it belongs to the shop module. We will demonstrate how this can be done in Exercise 1.2. Customizing language elements is discussed in detail in Chapter 5, Changing the Look of VirtueMart.

Exercise 1.2: Customizing a language element

In this exercise, we are going to customize two language elements found on the Product Listing page, as shown in the following screenshot:

As an example, we are going to change the text for Browse and Sort by. As we shall see, the Product Listing page is actually processed by the module page shop.browse. So we will expect these language elements to be found in either the shop language file or the common language file. These are the two files we are going to search for these two elements.


  1. 1. Open your favorite text editor. Navigate to the VirtueMart administrator root.

  2. 2. Open the file languages/shop/english.php.

  3. 3. Open the search dialog of the editor and search for the text Browse and Sort by. You will find the text Browse in line 21 with an element name PHPSHOP_BROWSE_LBL. Change the text from Browse to Product List. The text Sort by, however, is not found.

  4. 4. Save the file and upload it to your server.

  5. 5. Open the file languages/common/english.php.

  6. 6. Open the search dialog of the editor and search for the text Sort by. You will find the text in line 405 with an element name PHPSHOP_ORDERBY. Change Sort by to Order by.

  7. 7. Save the file and upload it to your server.

  8. 8. Go to the frontend of your site. Browse to any Product Category Listing, and you will see the text changes.


  1. 1. In this exercise, we changed the language elements in the shop module. You can apply similar techniques to any other module.

  2. 2. Sometimes you may have more than one language element that contain the search text. Make sure the element value matches exactly with the search text and is not a substring. Also, the case of the two text elements must also match. In case of doubt, you can test it by trial and error.

If your site is just with a single language, you don't need to bother changing the language file. You can go to the template file and change the element directly. We will be doing this from time-to-time in the exercises that will be presented in later chapters. (See, for example,Chapter 3, Exercise 3.1 and Exercise 3.6)

Sometimes, you may want to add static text somewhere on a certain page. You will be able to do that by determining where the appropriate place is. There are probably various areas where you can insert the text. To maintain backward compatibility, it is advisable to insert the text in a template instead of the VirtueMart page or class file as far as possible. This may not be possible, but it is something worth considering before making any changes.

Sometimes, the text you want to add is dynamic, meaning that the text may be different depending on the specific situation. For example, you want to add a certain text to the browse page depending on the shopper group. Then you will need a PHP if construct to achieve this. We will be doing this in some of our exercises (See, for example, Exercise 3.5 for use of the if construct).

Layout changes

Layout changes are those that involve moving elements around on the page or changing the style of an element. For example, you may want to make the product name look bigger. Or you want to display the price before the product SKU and so on. These are all layout changes that can be easily done once you locate the template file that needs to be modified.

For styling changes, you can either add the CSS style in the template file or modify the theme CSS file. Sometimes you can even change the style by modifying the Joomla! template CSS. Obviously, there are pros and cons for each of these approaches. While considering what to change, you should also think of future compatibility. It may be better to restrict the number of modified files to a minimal, but that also depends on other requirements as well.

Layout changes can also be dynamic. You may want to use one layout under a certain condition and another layout if a different condition applies. You may, for example, want to use one CSS style for products in a certain category and a different CSS style for products in another category. This again will involve PHP coding. We will also be doing some exercises of this kind in later chapters (See, for example, Exercise 3.6).

Frontend behavior changes

Frontend behavior changes are changes that involve JavaScript running on user's computer. You may come across a JavaScript that can create a reflection effect for the product image. Adding this kind of behavior is actually pretty straightforward. Usually this is accomplished by putting the JavaScript in the template file and modifying one or two HTML elements. The JavaScript can also be added to the theme.js file or included by other means (See Chapter 5, Changing the Look of VirtueMart, and Chapter 9, Theme Customizations, for details of using JavaScript when making behavior changes).

Another example of behavior changes is changing the Ajax add-to-cart pop-up. Some people find the time that the pop-up appears too short or too long. This can be adjusted in the theme.js file or in the template file (See how this can be done in Exercise 8.2.).

Modifying available template fields

Each of the templates will have a set of available fields that you can use. Sometimes you may want to display the same information in a different format. Examples of this kind of change are the product_availability and product_thumb_image fields. Many magic touches can be done in the template itself without involving changes to the VirtueMart class or page file.

Adding data fields

From time to time, you may want to add a data field to your shop. If you sell books, for example, you may want to add fields such as publisher and author. Adding data fields like this is not as simple as it may seem. First, you need to modify the database table, usually through a phpMyAdmin session. Then you will need to modify the class file to accommodate the new fields. You also need to modify the product form used in the backend so that the fields can be displayed and edited there. You will need to add this to the VirtueMart page file to pass it to the template. Finally, you will need to modify the template to actually display the field.

On the other hand, it will be much easier to add a new user field since VirtueMart allows adding/customizing user fields used in the frontend or backend. You should use the Admin/Manage User Fields menu option to update the user fields. (For a detailed discussion about customizing user fields, please see Login/Registration and Shipping Information in Chapter 6, From Shop Basket to Final Checkout.) If you need some detailed control on the user field behavior, this can be accomplished by modifying the class file or page file. In case the user field will need to be included in the order e-mail, the corresponding e-mail template will need to be modified as well.

Adding data fields to other data tables such as product category or order is also possible. The complexity of such kind of customizations will depend on the exact requirements.

Due to the complexity and technical skills needed in adding data, discussion of this type of customization will need to be done in a different book.

Modifying processing logic

The processing logic in a comprehensive shopcart like VirtueMart is definitely very complex. While VirtueMart is already very versatile and can cater for many actual applications, there are still areas that may not fit your specific needs. In that case, you may want to modify the processing logic to make VirtueMart work for you.

For situations like this, the best strategy would be to restrict your modifications to one single module. For example, if you just need changes in payments, you can probably develop your own payment methods. Anyhow, you should note that most processing logic resides in the page file and cannot be changed in a template. And the undertaking may involve complicated programming. So, the most part of this type of customization will be outside the scope of this small book. However, you may still find a few exercises that will involve modification of the page file, especially in Chapter 10, Additional Customization Possibilities. But those modifications definitely will be brief.

Creating a new theme

Sometimes you may want to develop your own theme, providing very different functionalities and style. Or you could even plan to sell your final design. To make it less intrusive to your user, creating a new theme is probably a good idea. This type of customization is the subject of Chapter 8, VirtueMart Theme Anatomy, and Chapter 9, Theme Customizations.

Integrating with an external system

VirtueMart is an online web store application. It does not provide accounting and customer management functions. Many users wish to make VirtueMart work together with their existing data system seamlessly. In that case, an integration system will need to be built. VirtueMart was intended to have an import/export system for that purpose. But unfortunately, the module is not well-developed and will need lots of effort to make it work.

Other customizations

There are many other types of VirtueMart customizations. We can create new VirtueMart page files to display what we want. For example, we could have created a new page for displaying manufacturers called shop.manufacturer. We can also create a new VirtueMart module called wholesaler to display pages only for a special group of shoppers. We can create new pages like wholesaler.browse, wholesaler.product_detail, and so on under this module. We can create new templates for the new page files and modules according to our needs and imagination.

How to create and integrate these pages with the bigger VirtueMart system, however, will be totally on our own.

Certainly, many real-world projects will be a combination of several of the customization types outlined previously. If you plan to customize VirtueMart involving a few of these areas, you need to have a thorough plan before you start. Otherwise, you may soon find the project becomes too big and is unmanageable.


Before starting your project

This brings us to the last section of this chapter. Before starting your project, you need to sit down and do some thinking and planning. You will find that the following steps can help to clarify your project needs and steps to meet those needs.

Determining the scope of project

First of all, you need to think about the scope of your project. Is it just a simple change of language elements or layout? Is all of the data already available? Do you need to modify the database or the class file? Do you need to change the processing logic? What modules will be involved? Will the change be done on a VirtueMart core or on a Joomla! module or even on Joomla! itself?

Sometimes a seemingly simple task may involve many modules of VirtueMart and can become very complex. The tax system, for example, involves several important areas of VirtueMart from the product list up to checkout. Any changes to the tax will thus not be a straightforward thing.

Locating file that needs modifications

When you are aware of the modules that may need change, you should drill down to the files that needs changes. Are modifications restricted solely to template files? Which template file contains the code that needs changes? There are close to 80 template files in the default theme. Locating the file to change may not be easy. If case of doubt, you can refer to the Appendix, VirtueMart Template Reference which contains a reference to all the template files. You can also use the technique described in testing and debugging to locate the page file that you will need to look at.

Assessing your skills—determine whether to do it in-house or outsource

Now you have an idea of the scope and the files that may need changes. But how are you going to make the modifications? Many modifications will be straightforward, especially if you are already comfortable working with HTML code. However, for more complex coding, it is better to leave it to the professional. If you have a team, probably someone in the team can be able to help. Otherwise, you will need to consider outsourcing. Professional help for small jobs are actually very affordable. You can consider using freelancers in the many online freelancer agents. Just be careful not to base your choice only on the lowest bid. Just like building a home, you won't want to compromise your safety by paying less.

Back up data and files

No matter how you are doing the job, whether in-house or outsourcing, it is always a good idea to back up your site before starting any modifications. For very small projects, such as changing the layout of a page where a database is not involved, you can just create a backup of the files that will need to be modified. You can even delay the backing up process to a time after the development has started. For projects of considerable size, however, you will need to have a full backup of the site.

Assessing impact on the site

As not all servers are created the same, it is not unusual to develop, test, and debug your customizations on your actual server. In that way, you can be sure the server configuration will be the same when you go live. If your site is already live, there is a lot more consideration. During development and testing, the site may be affected. So you need to assess the impact on the site. By carefully planning for the modifications, it is possible to restrict your changes to files that are not in use, at least in the initial stage. You can also do the development and testing at a time when there is less traffic.

Doing development and tests on a live site is not always advisable. In such cases or if you want to reduce the effect on your live site to a minimum, you should consider making a clone of the site. Cloning a site is not difficult. It just takes time. Many hosting packages will allow you to create subdomains from your main domain. Say your live site has a domain You can create a subdomain like You can then copy all the files from the live site to this subdomain site and do development and tests there.

If you cannot create your own subdomain, you can also create a subdirectory under the main domain. If the subdirectory is called test, then you can access the development site using the URL While the subdirectory site may look less professional than a subdomain site, the working is basically very similar. In both cases, you need to remember to change the site URL in the VirtueMart configuration.

Consider future upgrade compatibility

Another important point you need to consider is future compatibility. If Joomla! or VirtueMart issues an upgrade, how will that affect your customizations? Joomla! upgrade usually does not affect your changes, unless it is a major version change (such as from version 1.5 to 1.6). If it does, most probably it will affect the whole VirtueMart community and you should be able to find some help from the VirtueMart forum. More often than not, VirtueMart development team will issue a new version to support any new Joomla! version that will impact VirtueMart. But of course, there will be a time lag between the issues of the two upgrades.

The concern regarding version upgrade is very different, if there is a new version for VirtueMart. If it is a major version change (say from 1.1 to 1.5) where no patch is available, your customizations will probably be severely affected. A complete revision will then be mandatory. If this is just a minor version change, VirtueMart will usually provide a patch for each of its previous versions. You can then compare the list of files in the patch and the list of files you have modified. You are safe if none of the files overlap. Otherwise, you will need to merge the lines of code by hand.

To reduce the impact of version upgrade, you should try to limit the number of file changes as much as possible. The smaller the number, the less probable you will be impacted by a version upgrade. Usually, VirtueMart does not upgrade template files. So if your changes are all in templates, your customization will less likely be affected by a version upgrade. You can also further decrease the impact by creating a new theme for your customizations.

Implement design

We don't have much to say about implementation at this point. The principles of implementation is too big a subject to deal with in detail here. As we work on the exercises, we will mention some general principles here and there though. However, our emphasis will remain on the specific design detail instead of the general principles. The only thing we need to mention is making a comment. You should mark the area of modifications in the file clearly, making comments as appropriate. This will be useful later when you want to do further modifications or a version upgrade is needed. For large projects, you should make a log of all changes or even keep a bugtrack. Of course, each of these extra steps will cost additional time and money.

Testing and debugging

After the coding is complete, you can start testing and debugging. Testing and debugging is also a big subject in itself and cannot be covered in detail here. We will note by passing a few suggestions specifically for VirtueMart debugging.

First of all, you should have PHP error reporting turned on during development, if that is possible. For an operating site, many web hosts prefer to turn off error reporting. This is in fact a best practice for live sites to avoid exposing site detail when an error occurs. However, testing without error reporting will be difficult and more time consuming. So if possible, turn error reporting to maximum. There is a Joomla! configuration that is supposed to control this. However, if your PHP configuration does not allow such kind of configuration change, the Joomla! configuration may not work. You may need to have your web host help to turn it on or, if your hosting allows, modify the php.ini file to allow this.

You can turn on VirtueMart debugging in the backend configuration to show some basic debug data. The debug checkbox is on the Global tab, in the Core Settings section. A similar setting is also available in Joomla! Global Configuration. The debug data can sometimes help you determine what's wrong with the code, but not always. Even with all this information, often the error cannot be identified until you print out some critical variables. So be prepared to make lots of use of the print statement to help debugging. We will give some further guidance on this as we work on the exercises.

One useful feature of the VirtueMart debug information is the filename that is involved in the data logic of a browser page. When debug is turned on, VirtueMart will print out the filename of the PHP script that controls the processing logic. This will help to locate the file that you will need to modify in case that information is not easy to guess.

Going live

Going live does not need any explanation. You just upload your code to the live site and things should work. Otherwise, you may need to remove the code from the live site and go back to the development site for testing.



In this chapter, we have navigated around the Joomla! directory and looked at the file structure of VirtueMart. We then explained the working of Joomla! through the model-view-controller model and compared this to the VirtueMart presentation framework. The roles of templates and themes in the VirtueMart pages were discussed. We then presented a list of possibilities for VirtueMart customizations and things that need to be considered before starting a VirtueMart customization project.

In the next chapter, we will take a look at the default VirtueMart theme and see how to configure it to change the look of your VirtueMart shop.

About the Author

  • Joseph Kwan

    Joseph Kwan has been a professional programmer for 12 years. He has thorough understanding of all major web technologies including HTML, XML, CSS, XSL, PHP, ASP, .NET, JS, AJAX, Apache, MySQL, MSSQL etc, on both Linux and Windows system. In the past 5 years or so, he has specialized himself in Joomla!/Virtuemart. Besides customizing/building many Joomla! components and modules, Joseph is also considered one of the few Virtuemart experts who know the system from front to back. He is highly regarded in the Virtuemart community and is renowned for building robust and quality extensions to Joomla!/Virtuemart. Joseph is also very active in the forum. He works from Burnaby, BC Canada.

    Browse publications by this author
Joomla! VirtueMart 1.1 Theme and Template Design
Unlock this book and the full library for $5 a month*
Start now