So, you have your shiny new osCommerce installed and up and running. Maybe you’ve even got to the point where you actually have paying customers buying from it, which after all, is the whole point of the all the pain in getting it is set up in the first place.

It’s usually only a matter of time though before most osCommerce site operators start to identify things that could work better for them, or would improve the shopping experience for their customers.

Enter stage right…. The Contribution!!

Well, hopefully you all know what I’m talking about anyway, but just in case…contributions can be found at http://www.oscommerce.com/community/contributions . In a nutshell, these are code extensions of varying complexity and quality, written by users of osCommerce and then shared with the community. Together, they cover extensions for just about every imaginable aspect of your store.

As I mentioned in that last paragraph, contributions vary tremendously in both complexity and quality. The results can vary from flawless operation, to some simple mistakes the following the instructions that are easily corrected, to “Oh my god there’s no way this is ever going to work!”. Given this, there are a few things you should consider in mind before launching into your first contribution installation:-

1. Read the forum support topic for a contribution before you even download it. If there are major problems with it, you can always choose to avoid it at this point.

2. Always take a backup of your existing files and database before you begin to change anything.

3. Always put comments around the code you add such as /* Contribution x Start*/ and /*Contribution x End*/, so that you can easily identify where changes have been made. This comes in particularly useful when ignoring rule number 2 and trying to take a contribution that didn’t work back out again!

4. When a line of code is replaced or deleted by a contribution, simply comment it out for the time being using // or /* */. This will help during the testing phase and will allow you to easily see how the line used to look. This is particularly important for when you are installing a contribution which affects code which you previously changed for another contrib – in this case you have to combine the code in a sensible way or otherwise you are going to break one or both of the contribs.

5. Never work on a live store directly if at all possible. If you can, work on a spare account or folder on your server, or on a local installation on your PC. If you can’t have to work live, try and be sure to leave the critical file changes (i.e., those that will be immediately obvious to your customers if they screw things up generally) until last. This way, you can quickly undo the change that caused the problem and buy some time to think about what to do next sanely. Files that would fall into this category would be product_info.php, index.php, checkout_process.php, etc.

6. Test thoroughly. In addition to checking the obvious (i.e. that the contrib. actually does something like what it said on the tin), also do some non-regression testing. This is in fact a fancy engineering term for “check that I didn’t mess anything else seemingly unrelated up whilst I was in there”. Even if you don’t think you messed with anything near the checkout process, it’s always worth doing a quick test checkout as there are a few key files that only need an extra blank line to find its way in at the end of the file to completely nuke your checkout process, maybe costing you a few days worth of sales until someone tells you about it.

7. Finally, if you are like me and ignore rules 1 to 6, make sure that you know how to get your hands on any scheduled backup files in a hurry. You can be sure that sooner or later you are going to need them. :o)

Once you’ve uploaded any new files, made the directed changes to your existing files and made any changes to your database, it’s time to do some testing on your new functionality. If all has gone well, that will be the end of the job. If not, you will need to work out where the problem has crept in. What follows below is a summary of some of the most common problems you may encounter and how to fix them. Most often, these are caused either by small errors in installation instructions, or “finger trouble” when following them. In all cases, when you get an obvious error that generates a php error message on screen, be sure to read it carefully because most times it will tell you exactly where the problem lies.

Parse Errors. Here php is saying “I just couldn’t make any sense of this line because it doesn’t follow my rules for how things should be written”. Common causes of this are:
Missing or extra quotes “ or ‘. Check that the number each type of opening and closing quote balance.
Missing or extra parentheses (). Again make sure you have an equal number of opening and closing one.
Missing or extra curly brackets {}
Missing a semicolon ; on the end of a line
Php tags in the wrong place. All php code should be enclosed by <?php ?> tags.

File inclusion errors. If you have something on the screen which is all capital letters, for instance /catalog/includes/languages/english/FILENAME_CONTRIBUTION then it means that a definition within /catalog/includes/filenames.php for FILENAME_CONTRIBUTION has been missed. It should look something like:
define (‘FILENAME_CONTRIBUTION’, ‘contribution.php’);

Database table doesn’t exist errors. Again, if you see something in all capital letters like “table oscommer.TABLE_VOUCHERS doesn’t exist”, it means that a necessary change to /catalog/includes/database_tables.php wasn’t made. It should look something like:
define(‘TABLE_VOUCHERS’, ‘vouchers’);

Access denied errors. Usually this means that a file or folder wasn’t available for reading and/or writing as required. To correct this, you will need to set the permissions (CHMOD) on the file or folder concerned. Check again the instructions to see what value it should be set to.

More complicated errors need more advance techniques, such as the “print_r is my friend” technique, which I will be covering in a future article. Failing that, if your time and patience has run out, this can be a good point at which to hire a specialist to put things right for you.

OK, not strictly osCommerce customisation, but I thought we'd start with something simple before getting into the complex business of templating and advanced CSS.

One area that is often overlooked is that of the humble product listing - the text you type into admin to describe your product. Sure, you can use something like MS Frontpage to come up with a whizzy looking design for this, but these often end up over-complicated and bloated with html tags. One extreme case I saw had so many uneccesary tags in it that it exceeded the space provided for the description field and was therefore truncated, which totally destroyed the presentation of the site when displayed to the customer (it had tables in it which as a result were not closed properly).

Here then is something simple you can do with a little basic html and css. Say you want to draw some important text to the customer's attention.... If you use something like this code you can put a nice box around it:

<div style="border:1px solid #555555;background:#cccccc;padding:20px;text-align:center;">Highlighted Text within your product listing</div>

This puts the text between the div tags into a box with a light grey background and a thin dark grey line around it like this:-

Of course, you can use any colours you like - they are defined by the hex codes for the red, green and blue components of the colour. For example, #ff0000 would be pure red and #00ff00 would be pure green. If you are unfamiliar with these, search google for online rgb colour pickers to help you with getting the codes for the colours you want to use. The padding figure simply puts some space between the text and the surrounding box and the text-align setting centre justifies the text within it.

Of course, if you want to put a box like this on lots of your product listings, you don't want to have to type all that style information every time. A neat solution is to use a class for the div and then define this in the stylesheet. In the above example, you would add the following to your stylesheet (catalog/stylesheet.css or then stylesheet in the relevant subfolder of the template directory if you are using Loaded, MS2MAX, or the BTS contribution on its own) :-

.highlight_box {
border:1px solid #555555;
background:#cccccc;
padding:20px;
text-align:center;
}

You can then put the box around your text by using the following in your product listing:

<div class="highlight_box">Highlighted Text within your product listing</div>

It has been a while since I wrote in this weblog, mainly because I have been away on vacation, but it has been interesting to see the searches people have been using to find this site while I have been away.

Some of these are more innocuous than others, but 2 themes seem to be emerging:

1. How do I recover from the situation where I have forgotten my admin password?

2. How do I break into a password protected osCommerce admin?

Needless to say, I won't be writing about the second question - any hacker worth his salt should already have enough tools and knowledge to be able to break into a less well protected site.

Regarding the first question though, of forgotten admin passwords, the answer depends on what kind of password protection you are using:

A. If you are running a standard osCommerce site, without any form of administrator modification, then you will be using a .htaccess based protection mechanism. Usually, this is put in place using a "Password Protect Directories" feature within your hosting control panel. To set the username/password to a new one, all you have to do is to use this feature to remove the current protection and then put it back in place again using new details (remember to make a mental note of them!). You can also remove the current protection by deleting/renaming the .htaccess file in your admin folder, but you should remember to rename it back, or create a new one using the aforementioned procedure to prevent unauthorised access to your osCommerce admin.

B. If you are using a session based access control modification, such as that used with CRE Loaded for example, you will need to run some queries on your database in order to get out of the situation. Firstly, get yourself into phpmyadmin, or whatever database management tool you use and have a look at the admin table. You will see that the password is encrypted - you could use some kind of brute force tool in an attempt to break this, but the quicker way of dealing with things is simply to replace this entry with one of known values. If you go ahead and delete the entry from this table and then run this query (note this may need to be adjusted slightly if your database columns don't match the count of this particular query) :

INSERT INTO admin (admin_id, admin_groups_id, admin_firstname, admin_lastname, admin_email_address, admin_password, admin_created, admin_modified, admin_logdate, admin_lognum) VALUES (1, 1, 'Default', 'Admin', 'admin@localhost.com', '1060bdf4e47bc8b4ab3fb0cfea9ef70b:77', now(), now(), now(), '6');

then this will reset the username/password to the default values at installation, which are admin@localhost/admin.

OK, so maybe we need to start with the basics on this one. With these days of paranoia over being hacked in one way or another you would think the obvious things would be covered by most people, but only today I found another longstanding live osCommerce store that didn't even have it's admin password protected in any way. This store owner must have been lucky up until now, but the law of averages states that sooner or later someone more dubious than myself would have come along and take advantage of this fact.

But what is the interest of an open admin for a hacker anyway? Surely, if you don't store credit card information in your database, there is little of use to them, other than just causing upset by deleting/changing things and generally messing about with the smooth running of your osCommerce store?

These kinds of attacks are of course quite obvious to both the store owner and their customers, and are relatively quickly noticed and corrected. What is more concerning are the steathier attacks that take place. Once such serious of "attacks" I witnessed involved a store where credit card details were not taken on the site; instead a payment processor was used for this purpose. However, the credit card module was being mysteriously enabled "all by itself" and orders were being deleted as soon as they had been placed. Eventually, this was found to be due to an duplicate, unprotected admin installation which had been forgotten about, which the attacker was using to enable credit card payments and then note the customers details before the store owner knew anything about it.

So, how should you go about protecting your osCommerce admin? There are a couple of ways to do it.

Directory Protection - if you are using something like cPanel, Ensim or Plesk, then you should find this feature in your hosting adminstration panel. It will cause a pop-up dialog to be displayed in your browser whenever you try and access the admin folder or any folder below it. The good thing about this kind of protection is that it is controlled by the webserver directly and therefore it is difficult to hack to gain access to the password.

This disadvantages are that it is difficult to know if someone has been repeatedly trying to access you admin by guessing your password (without checking your webserver access log) and an attacker can have an indefinitely number of tries at this.

Therefore, as with all password protection methods you should choose a password that is difficult to guess/crack, with a reasonable number of characters and avoiding words found in a dictionary. "5@yf6*we" is a good password "password" is not!

Administration Contributions - Another method to use is to implement one of the admin contributions, such as Admin with Access levels. This provides session based access control through php/mysql.

With such a solution, better auditing and hack protections can be implemented, although these are not always used. Locking down the system down so that logins can only be made from a particular IP address and sending notifications of failed login attempts to the administrator all help to protect your system and maintain awareness of what's going on.

The rule of choosing a strong password still applies with this solution, but also you should choose a password that is unique for this purpose. You should never use the same password for your database access, osCommerce admin, or cPanel login. This can mean the difference between a relatively minor compromise or a major incident.

To illustrate the point, I have seen unsecure servers where it has been possible to view the configuration files for php driven sites in other accounts. By looking for the username and password used for the database connection it has then been possible to login to the cPanel account for that user because the details were the same. In this situation it only takes a matter of seconds before an attacker can do anything on your webhosting account that you can.

It is worth remembering that such protections discussed above are not in themselves infallible. I have seen cases where a server had been compromised through an account other than the one on which the target osCommerce site resided. Through poor configuration of the server, the attacker was then able to access the webspace of any account on the server and edit files where permissions allowed. The admin login.php file for the target osCommerce site, which used an adminstrator contribution had been altered by the attacker so that the password e-mailed to him whenever the administrator logged in, thereby granting him access to the admin interface directly. Note that if directory protection had been used, it might also have been possible for the attacker to remove this protection if the permissions on the .htaccess file were not set correctly. There are ways to avoid such problems and also to check the basic security of the server on which your site is hosted - these I will cover in a future article in which I will show you some common hackers tools which you can use to check this for yourself.