Basic configuration of osCommerce - The Administration Tool
(Page 2 of 4 )
Having an online tool like the one shipped with osCommerce is of great value and advantage to us osCommerce users. If, for example, you had undertaken to build your own site from scratch, then no matter how well you built your site, it would probably be prohibitive in terms of time taken to develop a fully functional online administration center to go with it. This would mean effectively that you are doomed forever to modify your database manually, or go searching for default settings within the actual pages of your code.
Thankfully that scenario is not one we need to consider, and the only real challenges for us are to learn how to use the admin tool effectively, and to understand the behavior of all the settings. Don't be fooled, though; if we make changes to the default settings without fully understanding the consequences of the changes, there can be some unexpected and untimely surprises, and surprises in the programming world are never good! The administration tool goes a long way to helping us make our decisions though, and it even provides a sentence or two outlining what each given option means—although this is often insufficient to fully appreciate the effects of changing the setting. The following screenshot shows the administration tool, open on the My Store page of the Configuration section:
All the pages in the administration tool have several common generic features, which you should be aware of. First, There is a navigation bar running along the top of the screen, which allows us to jump to the Administration home page (this option is presented again on the far right of the bar), the osCommerce homepage (Support Site), as well as our actual osCommerce site's homepage, held in Online Catalog. Nothing too life-threatening there, but useful if you want to jump around to find information, or test the results of your modifications.
Next, all the setting options that are available for us to use are categorized and stored in the box on the far left of the screen. This chapter concentrates on only the first option, Configuration, because the other options all overlap specific topics that warrant their own chapters. Clicking on a heading category—for example, Configuration—will bring up its list of options, and clicking on these subcategories will bring up a page containing all the setting options for that category.
The category setting options are displayed in the center of the screen in a tabular format, and each option is a link that will bring up its own edit option and description on the far right of the screen. So, for example, in the previous screenshot the setting we are looking at is the Store Name, and clicking on the edit button will bring up the following page, which we can use to enter text and save the new setting:
Clicking the update button will then take us back to the settings page, which should now reflect any changes we have made. That about explains how we go about configuring the site. The rest is really about understanding what effect the changes will have. Of course, as with anything, there is also a good way and a bad way to go about making changes. Most of you should be able to guess straight off that the good way will involve some sort of verification process to ensure that our changes have the desired effect.
Now, for something as simple as deciding on the store's name, there is probably little that could go wrong, so don't feel you have to waste time verifying every single change you make. However, you should make it a point to check results after a certain number of easy modifications, as well as verify the more complicated settings (if possible) as and when you make them. This is really good practice—not only from a theoretical point of view, but also from a practical one—because it is likely that you will need to run exactly the same suite of tests when you deploy your site to ensure everything is working properly on the real live server.
Another important point to consider is that some of the settings you make will apply only to the development machine and will need to be modified again to suit the live system.
You will need to make a note (a physical one, not a mental one) of the settings that are likely to change when you deploy the site to the live server. Save your notes in a file called configuration_settings.txt and leave it in a folder entitled development_notes somewhere where you will find it again.
For example, E-Mail Address in the previous screenshot will not be root@localhost when your site is live. If you have already purchased your domain, and are aware of what your email addresses, among other things are, then you can enter these settings into your development machine now. If you know that you want your emails to come from something like staff@contechst.com, then entering this value into your development version of osCommerce is fine because it will save you having to change it during deployment and won't really affect anything on your development machine.
Of course, these configuration settings are not the only things that are subject to change between the development machine and the live server. Keeping tabs on what will, might, and probably won't change is definitely a valuable practice. Of course, this book will discuss deployment in a later chapter, and will lend support in this area by providing checklists of tasks to perform in order to ensure that your live server is functioning properly. More about that in Chapter 11 on Deployment and Maintenance; for now, let's concentrate on the task at hand…
Next: My Store >>
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.
|
|
/ 6 
