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.