Basic configuration of osCommerce, concluded
(Page 1 of 5 )
If you're setting up your site to handle online sales, you could do worse than to use osCommerce. This article, the third of three parts, explains how to configure the software to get you up and running. It is excerpted from
Building Online Stores with osCommerce: Professional Edition, written by David Mercer (PACKT, 2005; ISBN: 1904811140).
Logging
Logging can be a very useful, if not critical, tool for maintaining a system's health. Logs can be used to record just about any action or change in state of an application. Most changes within an application are really of no interest to the average person, but certain things are useful to record in case you need that information at a later stage. Like any good system, osCommerce gives us options to create and monitor certain actions within our application. This ability comes with a caveat, however. If left untended, logs can become resource hogs, taking up gigabytes of space in a surprisingly short amount of time.
Accordingly, you need to decide what information you want to record, and then work out a good management strategy for maintaining that information. Also, logs should be kept in a secure place—you don't really need to air your database query history to the world, or worse, have it modified by someone. The options presented to us by osCommerce, along with the settings used for the demo site, are shown here:
Since development is taking place in a Windows-based environment in the case of the demo site, we have added a Windows path value for the Log Destination setting. This means that the log file, which is set to store and display the Page Parse Time, will be created and held in the admin folder.
"What, oh what are you doing?" Some of you may cry out. Holding the log file in the document root will allow people to access it from the web server. Haven't we just said that the log files need to be kept out of reach of prying eyes? Well, yes, one can access this log over the web server on the development machine because we haven't secured our admin tool yet. Later, when we deploy the site (most likely to a Linux-based server) this path will need to change to something more suitable. In any event, holding it in the admin folder will still not be too much of a security risk because we need to secure this entire folder anyway.
After browsing around the site a bit, we can look at what is created in the designated log file to see the type of information we are storing. To be honest, this information is not really relevant to you at the moment, so unless there is a reason for recording logs during development, you can do without it altogether for now:
It is recommended that you leave the Store Database Query setting as false all the time unless you have a really good reason for needing it, and you know exactly how you are going to deal with all the information being stored. These logs can grow very quickly and take up a lot of space, causing problems for your site's performance if you're not careful.
Finally, remember to make a note of all the settings, in this case the log-file path, which you will need to change come deployment time, and add the files to the development_notes folder, which you created earlier.
Cache
A cache is implemented as a directory of web pages, which are held separately from the rest of the pages. The purpose of this cache is to allow the server to quickly serve cached pages instead of querying for the page afresh each time it is requested. This has implications for the speed of delivery of pages and therefore impacts positively on the customer's experience. It is recommended that you do use caching on your live site for this reason.
For the development site, however, it's not a good thing, because we want to see the results of changes (configuration or customization, or straightforward hacking) that we make to our pages every time we load them. Using a cached version of a page might not reflect the changes we have implemented, as that page would not been refreshed yet. This can often cause confusion and frustration, so for now, leave the cache entirely.
Once you have deployed the site, it is a good idea to switch caching on only after all your testing is complete for exactly the same reason. To do so, simply set the Use Cache value to true, and pick a folder to save the files to. By default this is /tmp/, but you need to be careful in this case to ensure that you are getting the right tmp folder on the host's site. Entering something like ../../tmp will probably avoid any resource clashes with other users on the same web host—another little note to go into the development_notes folder.
Don't worry if you don't understand this completely at the moment. The only thing is to remember to leave caching off during development and testing, and switch it on, using a folder exclusive to your site once the site is live.
Next: Email Options >>
More Web Authoring Articles
More By PACKT Publishing
|
 This article is excerpted from Building Online Stores with osCommerce: Professional Edition, written by David Mercer (PACKT, 2005; ISBN: 1904811140). Check it out today at your favorite bookstore. Buy this book now.
|
|
/ 5 
