Project Detail

Description

Replicate an existing website using modern techniques ( MVC, OOP ). The existing website is built in PHP3, we need to modernise the architecture so it is easier to maintain, and so it can run on our PHP5 server. We also have a new design to be applied.

The website manages a product catalog and order system for a wholesale clothing supplier.

The website needs a CMS for managing static content and help/info pages outside of the catalog and ordering system.

There is a backend administration area where the administrator can manage customer/supplier accounts/details, manage products/categories, and mange orders.

A registered customer can login to the front end and order products to their required colour, size and quantity.

A casual visitor who is not logged in can browse the products but can not see prices or place an order.

Products are grouped into categories. There will be two levels to the category system (managed by the administrator in the back-end area).

The administrator can sort products to alter the order of appearance when browsing categories.

Products will have a title and description for display in the front end, and fields for meta tags: keywords and description. Optional PDF upload per product.Products can have multiple images. Uploaded images are resized automatically to the two sizes used in the system: full-size and thumbnail.

The system maintains a list of possible product sizes, colours and neck-styles. These parameters are managed by the administrator through the backend control panel. A product can have any of the sizes, colours and neck-styles associated with it, preferably by a muliple select form element.

For each size associated to a product, there is an additional measurement for the chest size. This data is associated to the product and corresponding size, visble when viewing the product in the front end.

Products can be designated as featured products, meaning that they are eligible to be displayed on the home page. The home page will display x number of featured products.

Products can be related to other products, so when viewing a product in the front end, there is a place on the page that says: "You might also be interested in ...". There should be unlimited relationships, and all products are eligible to be related to any other product.

Customers are assigned to groups, allowing the administrator to enter price variations per user group. There should be provision for unlimited groups in the system, but for a start, there is "wholesale 1", "wholesale 2" and "retail".

Each product will have price variations for white products vs coloured products, so that white products can be a different price from coloured products, and prices for these vary depending on the customer group.

There can be multiple products per order, and any quantity/size/colour/neck-style.
Eg: one order may contain:
30 red turtle-neck jerseys size M
20 blue no-collar jerseys size L
etc

Each order shall display the order number, total price, ordered date, customer name, customer group title, email address, customer order reference, customer notes, delivery address and products. Products in an order shall display:
- product title
- product category
- size
- neck style
- colour
- quantity

The administrator can manage product prices with a quick-form. This allows them to choose a product to edit, and then presents a form displaying all user groups and the prices for that product for each user group, and two prices per user group: white and colour (as explained above).

The administrator can view/edit/add customers. Existing customers are listed and paginated alphabetically by the first letter of the business name. Parameters per customer:
- password
- username
- company name
- customer price group
- address 1
- address 2
- address 3
- phone number
- fax number
- email address

Distributor details are managed in the backend by the administrator:
- Company name
- contact person
- address
- phone number
- fax number
- email address
- company website url

The administrator can upload a pdf file containing the full product catalog, and this can be downloaded from a link on the home page.

Casual visitors can browse the products/categories and prices are displayed according to their default user group (retail). There is no self-registration on this website, user accounts are created by the administrator. Registered users can login to the website front-end and will only see prices associated with their user group.

Users can order in two ways:

Fast order: Ajax built order form. Select a product, then size, neck style, colour, and quantity. Any number of products can be added to the order with this form. The form also has the following fields:
- Customer order number (customer enters their own reference for use in their financial software)
- email address for order confirmation
- order comments

Standard order: Browsing products, you can add a product to your shopping cart. Logged-in users can checkout instantly and the administrator will charge their account.
- Customer order number (customer enters their own reference for use in their financial software)
- email address for order confirmation
- order comments

System architecture shall use PHP for logic and XHTML/HTML for the templates. XHTML/HTML templates must not contain actions belonging to controller or model roles. CSS and JavaScript must be kept in external files. mod_rewrite is preferred for browsing categories/products for SEO purposes, to encapsulate url parameters.

Eg:
http://domain.com/products/view.php?product_id=122
should be something like
http://domain.com/products/122/view.php
... to remove the parameters from the query string, as search engines often ignore dynamic urls.

Please discuss any proposed framework/s with me via the private message board.


Additional information submitted:

07/09/2008 at 23:31 EDT:
Correction to following statement:
"Casual visitors can browse the products/categories and prices are displayed according to their default user group (retail)."

... actually, prices are not displayed on the website until the user logs in, so casual visitors (not logged in) do not belong to a pricing group.