When it comes to designing a content management system from scratch it is important to think ahead and try to anticipate the needs and changes of your client. If you build a system that is rigid yet inflexible you will suffer for it when your client demands changes. The trick is to create a system that is fluid and easily changeable – dynamic.

To put this into some perspective we’ll take our “Complete Computers” as an example.

Say for example the client initially wants to do this:

• Create a computer part
• Choose Image for part
• Write a description for part
• Write a title for part
• Set price for part

These are the bog-standard things that should be implemented for the computer parts.

However what if you have implemented this and in a couple of months the client comes back saying that he wants to also be able to apply a discount to all products? In this case let’s say he wants to implement a 15% discount on all products.  With the way we originally created this, it would mean that the client would have to manually discount 15% from each and every product. This gets frustrating if the client has 100’s of products that he now has to spend ours on changing.

The easiest way to escape this conundrum is to set a modifier on the entire “price” column for every product when it is outputted. So in the front-end the discount is applied Perhaps with a piece of code such as:

<?php

$sql = “SELECT * FROM catalog_products WHERE productid = ‘4′”;

$res = mysql_query($sql);

while ($row = mysql_fetch_array($res, MYSQL_ASSOC)){

$price = $row['price'];

$multiplier = 0.85; //discount of 15%

echo “£”.($price*$multiplier);

}

?> 

This is easy enough to do but wouldn’t it have been better to anticipate this kind of functionality beforehand?

What you need to ensure is that you have the bases covered before you finish your CMS. Ideally you should always have the basics laid down that any store might require. That is build in the sort of functionality that is expected of a store. Discounts, VAT changes, Shipping costs. All manageable by the client in the admin section.

I find it easier to implement these sorts of much-needed bits of functionality before you move onto the bespoke side of things. This is only part of what I mean by thinking ahead – the rest I will cover in my next post “Building and Testing our database” where we will cover our sample stores database and also try to cover our bases so that we do not need to return to the client in a months time to implement obvious changes.

Hello all, and welcome to my guide on creating a bespoke content-management system (CMS). My name is Rob and I form part of the e-commerce development team here at e-commercewebdesign.co.uk – part of the CreareGroup.

What I wanted to do for my first post was basically jump straight in at the deep end. I am going to give you a step-by-step guide to creating a bespoke CMS. Hopefully this will help you learn the ways of PHP/MySQL as well as understanding the nature of the customer’s site and anticipating any future changes and building in improvements as we go.

Of course what we need is to create (or at least plan out) an example website that requires bespoke functionality.

The most common request that we have had to incorporate into bespoke CMS designs is a “stage system”. What I mean by stage system is the systematic building of a complicated order. This could be the building of a kitchen, a conservatory or even a computer. To simplify it a bit – a bespoke CMS is only really needed when the product on sale is in itself bespoke.

So this is what we will be doing. We will be building a computer shop – “Complete Computers” – one that is bespoke and which allows us to select the hardware and software and we may even go so far as to personalize it – simply to show extra functionality on the part of the order process. We will also be validating each stage so that it only proceeds when each stage is completed to a satisfactory standard by the user.

The steps I will show you in this series of blogs will include all of the following and probably a lot more.

• Thinking ahead – covering your bases when it comes to database design
• Building and Testing our database
• Creating and Separating the front-end and back-end systems
• Creating the stage system
• Creating the session
• Creating the shopping cart
• Implementing the payment gateway

There are more areas to cover than this but hopefully this will give you all a taster of what is to come. If you have any suggestions or questions about any of this then don’t be afraid to post.

Thanks and hopefully you’ll look forward to my second instalment in a few days time – most likely called “Thinking Ahead” where we will go over all the possibilities of what our store could entail.

It is important to have a virtual shopping basket or ‘cart’ viewable at all times so users feel like they have it ‘with them’ whilst they are browsing your site, and it also keeps them aware of what’s in there and that they can add or remove items at will, just as in real life.

The Amazon shopping basket is great example:

The blue colour makes it stand out perfectly and its slim design makes in non-obtrusive. The details are kept brief and important showing quantities, prices and a product title which when clicked upon takes you to the product you’re buying – a nice touch. A very important feature is the ‘edit shopping basket’ button which is nice and clear and assures the user that they can always add or remove items nice and easily.

The two ‘Proceed to Chekout’ buttons are also very prominent here and are located near the shopping basket because it’s likely that you’d want to check what’s in your basket before checking out.

One final point I’d like to make about shopping baskets is to keep the name consistent. Don’t go switching between cart, basket or trolley at will as it could confuse less experienced users. The basket is there to reassure and to be convenient to users, following these guidelines and taking a page out of Amazon’s book will help you on your way.