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.
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.
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.
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.
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.
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 www.yourdomain.com. You can create a subdomain like test.yourdomain.com. 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 http://www.yourdomain.com/test. 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.
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.
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.
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.