PHP 5 e-commerce Development- P25 ppt

Chapter 4
[ 103 ]
One important aspect of this code is that, each set of attribute values is cached, and
then added as a tag for the template engine after the attribute sets themselves have
been converted into tags. This is because the template system processes the tags in
order, so if it doesn't do the attributes rst, it won't nd the tags it generates, which
are replaced with the attribute values, as explained in the next section, Templates.
Templates
We have looked into how to alter the framework to use different templates
depending on if the product has customizable attributes. The next stage is to
actually make these templates.
We need a template for the product with attributes. This template requires a
nested loop of template tags: the outer loop of template tags will be to generate
a drop-down list for each attribute, the inner loop to generate the attributes for
each of the attribute drop-down lists.
<h2>{product_name}</h2>
{product_description}
<p>Cost: &pound;{product_price}, number in stock {product_stock}
. Weight: {product_weight}Kg.
</p>
<p>
<img src="product_images/{product_image}" alt="{product_name}
image" />
</p>
<! START attributes >
<select name="attribute_{attribute_name}">
<! START values_{attribute_name} >
<option value="">{value_name}</option>
<! END values_{attribute_name} >
</select>
<! END attributes >attributes > >

This is the same code as our product template, with a select eld. A drop-down list
is generated for each set of attributes associated with the product, and then list items
are generated where appropriate.
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Product Variations and User Uploads
[ 104 ]
A look back at simple variants
We discussed simple product variants earlier. One advantage that they have over
multiple variants becomes obvious when page design becomes a concern. If we were
to have a system that utilized simple variants, we could display a simple table of
product variants on the "main products" page, listing the names of products, cost or
cost difference, and a purchase button.
Of course, this is something we could look at implementing as subproducts, should
we wish to.
Giving users control
Along with giving users a choice for products in our store, we may also wish to give
them some control over the products; for example, this could include:
Uploading a photograph or image, for our Juniper Theatricals store; this will
be for customers to order and purchase customized novelty t-shirts
Supplying some custom text, again for our Juniper Theatricals store; this will
be for customers to customize their novelty t-shirts with a punch line of their
own, to t into the products template
•
•
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Chapter 4
[ 105 ]
How to customize a product?

We need to make it possible for our customers to customize the product through
both le and image uploads, and then entering of free text.
Uploads
If the product is to allow the customer to upload an image, then the template
requires a le upload eld within it, to facilitate that. We are only going to look
at allowing a single le upload for each product; if a product required multiple
images, for instance print media, where back and front designs may be required,
the customer can compress them into a single le. It may be worth considering
implementing multiple le uploads per product at a later stage, should the
requirements of our store demand it.
Custom text
The simplest way to handle custom text is to have at most one free text permitted
per product. This would simply involve having an extra eld in the table to contain
items held within a customer's basket, relating to the value from this eld, and also a
eld in the products table indicating that the product can accept free text as an input.
For many situations, this should be sufcient; however, let's look at a potential way
we could support multiple text elds. In our Juniper Theatricals store, we will want
to advertise customizable t-shirts for sale, with novelty text or images within them. If
the customer is to supply some text, we may wish to provide them with options for
entering text for the front, back, and perhaps even the sleeves, or below a logo, which
may appear on the breast of the shirt.
If we have an additional eld in our products table containing a list of free text
attributes, we may wish to collect it from the user, and then generate text boxes for
each of these attributes, and the submitted values could be serialized into an array
and stored within a single eld in the customer's entry for the product in the basket
items table, when we develop that in Chapter 6.
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Product Variations and User Uploads
[ 106 ]

When viewing a product with custom text inputs, the appropriate text boxes appear
within the view, as the following screenshot illustrates.
Limitations to this method
This method obviously has limitations. Primarily, because we store all of the custom
text inputs available and their values in a single database eld, instead of one per
value, it isn't going to be easy to search for product purchases based on the values
submitted into these. Another limitation is that all of the text elds would need to
be text input boxes, and we could extend this to support both input boxes and text
areas, among other relevant and useful input boxes.
Maintaining uploads
In Chapter 6, we will look at processing these uploads; however, we will also need to
consider maintaining them. If a le is uploaded and a product is added to a basket,
and that basket is never converted into an actual order, we will want to remove that
le. Similarly, once an order has been paid for, and processed fully, we would also
want to remove it.
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724
Chapter 4
[ 107 ]
Security considerations
There are also a number of security considerations which we must bear in mind:
By allowing customers to upload les, we could be open to abuse from
someone repeatedly uploading images to our server. We could implement
time delays to prevent this.
Which types of les will we allow customers to upload? We should check
both the type of the le uploaded and the le extension against a list of
suitable values.
What would the maximum le size be for les customers upload? If we set
this value to be too large, our server will get lled up quickly with custom
les, or could be abused by someone purposely uploading very large les.

What safeguards are in place to prevent customers nding uploads of
other customers?
Database changes
To allow customers to customize products, we obviously need to make some changes
to our database structure to indicate that a particular product is customizable, and
can be customized either by the customer uploading a le or entering some text.
Extending our products table
The changes required to our products table are actually quite simple; we only need
to add two elds to the table:
allow_upload (Boolean): This eld is used to indicate if the customer is
permitted or able to upload a le when adding the product to their basket.
custom_text_inputs (longtext): This eld is used to hold a serialized
array of free text elds, which we may wish to collect from our customers.
The following SQL query will modify the table for us:
ALTER TABLE `content_types_products` ADD `allow_upload`
BOOL NOT NULL, ADD `custom_text_inputs` LONGTEXT NOT NULL ;
•
•
•
•
•
•
This material is copyright and is licensed for the sole use by jackie tracey on 23rd February 2010
953 Quincy Drive, , Brick, , 08724