Review Site User Manual
|
UNDERSTANDING REVIEW RECORDS
There are only TWO important types of record in Review Site: review records, which live in the Review table, and article records, which live in the Article table. The Article records are very simple, and will be discussed in the section to follow this one. That way, very little about them will need to be said. Once you understand Review records, Article records will be a piece of cake.
Below I will discuss the default columns that appear in your Review table. You'll be able to see how to add a new review record using the administrative Database control panel. It is also possible to simply add a new record via another database client, like phpMyAdmin. However, the Review Site Database control panel is easier to use in my opinion.
The Review table itself is prepopulated at install time with example data so that you can see immediately how it all ties together. After you understand the basic setup, then it will be time to learn how to add new columns (or delete them) and enhance the basic setup.
Understanding The Rating Scale
As you will see later in this page, the rating you assign to a review is a decimal number with one decimal place of precision. You can decide to offer ratings out of a maximum of either 5 or 10. To signify to Review Site your chosen rating scale, go to the Configure > Miscellaneous control panel and set the value of misc_rating_scale which is by default set to a value of 5:
The rating scale is used to determine graphical ratings to display, which are always out of a maximum of 5 stars, so if you are offering ratings out of a maximum of 10.0 make sure you have misc_rating_scale set to 10.
IMPORTANT: There is no check on the rating value that you enter with your review. If you enter rating values greater than the maximum possible rating value that you have selected for misc_rating_scale then your rating will be clipped to the value of misc_rating_scale.
Creating New Review Records
If you visit the administrative pages and click on the Database link in the navigation bar you will be presented with the page from which you can begin making changes to your database records. You can select the Review table from the left side menu, and also select the option to List Records. Hit the submit button and you'll get a list of the existing records in your Review table. At the top of each displayed record is an Edit link. Click on this and you'll be presented with a page that shows all column values in the record, ready to be edited.
For example, if we click on the second record, for Widget Number Two we'll get a page that looks something like the following:
So what are each of these fields used for, and what are the restrictions on the values you can supply? Don't worry about how new fields might be added. We'll get to that later. The name of the corresponding column is given in parentheses in the definitions that follow.
You will notice immediately that about a third of the column names have a product_ prefix. These columns represent plain product fields that will be not be treated in any special way.
Another third have a compare_ prefix. These columns are used on the product comparison page and are expected to conform to certain rules, which will be elaborated upon later when we consider how to add product comparison columns to the Review table.
The final set of columns with the review_ prefix are used to represent your review and rating of the product.
Some of the fields below are mandatory when you add a new product. These mandatory values are indicated with the string REQUIRED FIELD.
Those fields that have been added simply as demonstation fields have the OPTIONAL DEMO FIELD - CAN DELETE string next to them and you can delete the column using the proper method of column deletion when the time comes. See Deleting Existing Fields for that.
Fields which you are expected to use, but which are not mandatory, have the string OPTIONAL FIELD placed next to them.
ID (id)
This is simply the record number, or PRIMARY KEY value of the record. It is assigned automatically each time you add a new record and can be ignored.
File Name (file_name) REQUIRED FIELD
This is the file name that will be used to specify the URL of the page on which your review for the product appears. No need to add any file extension. That will be added automatically. It is suggested that you use lowercase and employ hyphens for the word delimiter. It is also suggested that your file name reflect the product name, which is the next field discussed. Note that you should try not to change the file name after you deploy it. If you do and the page is indexed, your visitors coming in from the search engines will come up blank the next time the (now invalid) file name is requested.
Product Name (product_name) REQUIRED FIELD
The product name is the all-important identifier of the product that you are reviewing. It appears in several places. It is used for the hyperlinks to internal pages as well as hyperlinks to the external vendor page for the product. It also appears in page titles. The maximum number of characters you can use for this field is 128. If you should need to increase this (why?) then you will have to change the column length.
Product Summary (product_summary) REQUIRED FIELD
On some of the public pages it is useful to be able to provide a short description of the product so that the reader can decide whether or not this is the product they want to know more about. The product summary might appear on the topmost page, in the Top Rated box (if it happens to be the highest rated product). The product summary also appears on the page that lists products. Because the summary is meant to be short you get no more than 255 character to use here. You could increase this by changing the column type of the Review.product_summary column, but that is not recommended. If you keep to less than 255 characters, the summary should cause no layout problems.
Product Description (product_description) REQUIRED FIELD
This generic text field is the place where you detail the product. The description appears in only one place: on the review detail page. You can make the description as detailed and as long as you think necessary. It is a TEXT column so it has no length restrictions. Use double linebreaks to represent paragraph breaks.
You can add HTML tags if you realy need to do so, but generally a better approach is to add more product columns if you need to add different kinds of product information, and then to add the associated HTML tags directly to the templates, and activate them only if the corresponding product information happens to be specified. See discussions elsewhere about how to customize templates using the Smarty markup language.
Product Keywords (product_keywords) OPTIONAL FIELD
Although search engines generally ignore keywords presented in <meta> tags, some customers have asked for a way to populate this field, so here it is. Feel free to leave it empty, and no keywords will be added as meta data.
Product URL (product_url) OPTIONAL FIELD
This is the money-making affiliate URL for the reviewed product. For example, if you are promoting a ClickBank product, the URL might look like http://afnickname.vendorname.hop.clickbank.net/?tid=reviewsite or just http://afnickname.vendorname.hop.clickbank.net/ if you don't need to add any tracking ID information.
This affiliate link will not be seen directly by the visitor. Instead, a generic jump URL is used which invokes a script that redirects to the final merchant page. No affiliate URLs will be appearing anywhere on your Review Site pages. You can recognize a jump URL on your pages because it contains the string /recommends rather than the string /reviews. Otherwise it looks like all the other URLs that appear on your public pages.
The maximum URL length is 255 characters. If you find you need to increase this length you will have to change the column type from VARCHAR 255 to TEXT. But it is unlikely you would ever need to do this.
Product Image (product_image) OPTIONAL FIELD
This variable represents the file name of a product image, such as banana-float.jpg
Images in Review Site are handled very simply. It is up to you to find images and add them to the product image directory for the application. The default path for this product image directory is the following:
/rs/reviewsite/my/skins/default/images/product
While it is recommended that you try to standardize on a width and height for your images, this is not always possible. The image specified by this variable appears on the review detail page at full resolution, so make sure you don't add large images here. A good size would be around 240 pixels wide by 240 pixels high. Keep your product image file names less than 128 characters in length.
Product Thumbnail (product_thumbnail) OPTIONAL FIELD
This variable represent the file name of the smaller version of the product image, such as banana-float-small.jpg
No thumbnailing is done by the application, so it is up to you to create the thumbnail at the size that you want it to appear on the page. In general, images that can be reduced in size to produce quality thumbnails are JPEG and PNG files. Try to avoid GIF images. They just don't scale well. Also, when you make a smaller version of an image, look for the "Make Sharper" filter in your image manipulation client. When you reduce an image in size it generally makes the thumbnailed image a bit fuzzy. You can get rid of that extra blur by sharpening the image. I find that it works great in Paint Shop Pro. I am sure your image manipulation client has a similar function.
As with the full-size product image, try to standardize on a thumbnail size. Something around 120 pixels width by 120 pixels high is good. Again, keep your product thumbnail file names less than 128 characters in length.
Price (compare_price) OPTIONAL DEMO FIELD - CAN DELETE
This variable is the first of the comparison columns that appears in our default set up. You can delete this column later if you decide you don't need it, but for now let's assume you'll be using it. Most people regard the price as an important consideration in their decision as to whether or not to purchase an item, so you'll probably want to use this column.
If you look at the column type you'll see that this is a FLOAT column with 2 digits of precision. This means that when you enter 19 as the value for the price it will be converted to the value 19.00 which specifies the price to the nearest cent. The column is a FLOAT(8,2) so it can be used to represent prices up to one million dollars. All comparison columns are OPTIONAL.
Vendor (compare_vendor) OPTIONAL DEMO FIELD - CAN DELETE
All comparison columns are entirely optional and this one, representing the vendor of the product, is another example. In this case the column is of ENUM type which allows a list of vendors to be presented in a drop down list when a new Review record is being added to the table. This column could just as easily be a VARCHAR column, which would allow the vendor name to be typed in when the Review record is being added. Because this is a comparison column, the vendor name will appear as one of the comparison values when products are compared on the comparison page. Had we not wanted that we would have added, say, a column named product_vendor instead.
 |
 |
Has Legs (compare_has_legs) OPTIONAL DEMO FIELD - CAN DELETE
This column, which is of ENUM type has possible values of only 'Yes' and 'No'. Columns of this type have especial importance as comparison columns. When an ENUM has only 'Yes' and 'No' as possible values (or NULL since it is an OPTIONAL field value) the value itself will be replaced by a graphic on the product comparison page. Either a green tick, or a red cross, will be used to represent the actual value. This makes it easy to see at a glance which features are present and which are absent when comparing products.
 |
 |
 |
Compare Quality (compare_quality) OPTIONAL DEMO FIELD - CAN DELETE
This example comparison column is another special ENUM type. Its values take one of three possible strings: 'Gold', 'Silver', or 'Bronze' (or NULL since it is an OPTIONAL field value). When this is the case, the value itself will be replaced by a graphic on the product comparison page. The graphics are trophy cups, representing "great", "OK", and "not so great" ratings for the feature in question, in this case quality. This makes it easy to see at a glance which products have great features. Whether it is more suitable to use a Yes/No column, or a Gold/Silve/Bronze column will depend upon how variable the nature of the feature happens to be. If a web hosting company offer, or does not offer SSH access, that's a Yes/No feature. How much disk space they offer is much more variable, and a Gold/Silver/Bronze characterization would be better for that.
Compare Quality Comment (compare_quality_comment) OPTIONAL DEMO FIELD - CAN DELETE
Sometimes it is very useful to be able to add a comment that puts the Gold/Silver/Bronze rating into context. For example, take the web hosting company example. You may wish to add the number of gigabytes of disk space to the page as a separate field OR you might prefer to combine it with a Gold/Silver/Bronze rating so that it stands out. To do this, simply add a comparison column of the same name as the Gold/Silver/Bronze comparison column but with a _comment suffix added. In this case the comment will be placed directly below the trophy cup with which it is associated.
Compare Height (compare_height) OPTIONAL DEMO FIELD - CAN DELETE
This example comparison column represents a height, which is a physical dimension. This column happens to be of FLOAT(6,2) type since this is suitable for representing numerical values with precision to two decimal places.
In this case it is also useful to be able to add some extra information about the value. In particular the units in which it is measured (e.g. meters). How this is is done will be elaborated upon when we discuss how to add new comparison columns to the Review table.
Compare Weight (compare_weight) OPTIONAL DEMO FIELD - CAN DELETE
Exactly the same comments apply here as for the example height column.
Review Rating (review_rating) OPTIONAL FIELD
Although the idea is that you should be adding a review for every product that you enter into the Review table, the review columns themselves are not mandatory. When you do get around to adding a rating value for your review, you need to supply a 3-digit value in the range 0.0 to 5.0 if you are rating on a scale of 5 stars maximum, or 0.0 to 10.0 if you are rating on a scale of 10 stars. The rating scale itself is specified in your configuration file. Change it from the default value of 5 if you intend to rate on a scale of 10.
Review Summary (review_summary) OPTIONAL FIELD
This column, which can hold a string of up to 128 characters, is used to provide a one-sentence summary of your review. Think of it as your review title: This Widget Blew My Mind. I Now Use It Every Day.
Review Pros (review_pros) OPTIONAL FIELD
This column, which does not have any restriction in the number of characters that can be used (but no more than 200 or so are recommended) is used to convey in summary form the things about the product that you really liked. These pros appear only on the review detail page.
Review Cons (review_cons) OPTIONAL FIELD
Same comments as for the Review Pros field. These are the things about the product that you did not like. Again, just a summary.
Review Text (review_text) OPTIONAL FIELD
This field is used to present your full review. It can be of any length. Use two consecutive linebreaks to introduce a paragraph break. Don't add HTML tags to your review. Well, you can, but you should probably try to avoid that.
Is Validated (is_validated) REQUIRED FIELD
This variable determines whether or not the product is added to the public pages. Unless you specify 'Yes' for the value, the product appears only on the administrative pages for editing purposes.
REVIEW COLUMNS SUMMARY
Hopefully you'll agree that the columns are pretty easy to interpret. Once you have clicked around the public pages and got a feel for how it all works with the default widget data, you can then think about adding your own additional product columns, and comparison columns, appropriate to your chosen product niche.
I recommend that you leave the default comparison columns in place until you have added your own and seen them work as expected. That way you you'll be able to see where you are going wrong if things don't pan out as expected. If you follow the specified protocol for adding new columns, it should work.
Adding New Product Fields
Although your Review table already has several columns meant to be used to characterize the products that you will be reviewing, almost certainly you will want to add additional columns to represent other aspects of the item. For instance, if you were dealing with software reviews you might want to add the download size of the software to the product detail page (the page on which your review would appear).
You can add extra columns in Review Site by going to the Database control panel. Look to the left side of the page and you will see a pair of drop down menus. Select the Review table from the first, and the Columns option from the second. Click on the button and load the page of column definitions for the Review table.
The attributes associated with each column should be fairly self explanatory. But let's consider one in detail, the Review.product_summary column. Here are the attributes associated with it:
Position 4 Column Name product_summary Column Type VARCHAR(255) Not Null Yes Form Display Product Summary Form Type TEXTAREA Form Regex Search Weight
Note right off that there is no Search Weight in any of the columns found in Review Site tables. The Search Weight parameter is used in other applications for text indexing purposes. In Review Site, all indexing is achieved with FULLTEXT searches. That is, a FULLTEXT index is added to a table and MySQL does all the hard work of figuring out how to find records that match a search query. So ignore the Search Weight attribute. It is not used.
In the case of the product_summary column, the Form Regex value is also not specified. But for some other columns it is. The Form Regex, when specified, is a regular expression that is applied to values that are feed into the database. If the value is in conflict with the regular expression, the record won't be added (or updated). As an example, an INTEGER column might have a regular expression of ^\d+$ which means that the input must be an integer or it will be rejected. When a regular expression is not specified, no check is made against the input, and it will be added to the record provided that it does not conflict with the actual column type.
Attributes Explained
Now that we've explained the attributes that you can generally ignore, here's what remains:
- The Position attribute specifies the column position in the table. You have control over that only when adding a new column, after which time it cannot be changed.
- The Column Name is specified when you add the new column. I recommend you always use lowercase when adding column names.
- The Column Type is the MySQL column type. You should learn more about column types if you do not know much about them. However, if you stick with the suggested column types discussed elsewhere you should be fine. In this case a VARCHAR(255) column allows up to 255 characters of text to be added to the column. Suggested column types that may be used in Review Site are: TEXT, CHAR, and VARCHAR for textual fields, ENUM for selection of one element from a list, SET for selection of multiple elements from a list, INT and FLOAT for whole and fractional numbers respctively, and DATE, DATETIME and YEAR for for date related values. These 10 column types should be sufficient for all your needs. Please stick to them.
- When you set the Not Null attribute to Yes you are saying that a value MUST be supplied when a record is INSERTED or UPDATED. Such fields are mandatory, such as a product name, and in Review Site, the product summary is mandatory.
- The Form Display is simply the label that is used on forms to identify the form element, and add meaning to it. This is generally a cleaned up version of the column name, which uses capitalization and white space.
- The Form Type specifies what kind of form element is used to collect column values. In Review Site, all records are edited from the admin area, so the Form Type specifies the nature of form elements found on the Add and Modify pages. Form Types that you should stick to when using Review Site are: TEXT, TEXTAREA, SELECT, CHECKBOX, RADIO, and DATE. These should be sufficient for all your needs. Other Form Types that may be present, but not suggested for use, are those used in other applications more complex than Review Site.
The above represents a summary of the column definitions. You can learn more about how to add specific column types to your Review table by visiting the section on ADDING COLUMNS TO A TABLE, which goes into much more detail.
New Product Column Requirements
One thing that ought to leap out at you when you study the column definition page is that most of the column names are prefixed. The product-related columns are all prefixed with one of two strings product_ and compare_
You will have to FOLLOW this convention if you want to add new product columns. Otherwise your new columns will not be recognized by Review Site as representing product data. The columns prefixed with product_ are generic columns. You put some data into the column, and it is displayed somewhere on you pages. Nothing overly special about it.
The columns prefixed with compare_ are a little different. You can display the information held by these columns in just the same way you would do for the product_ columns. However, the compare_ columns are recognized as those that should also be specifically presented on the product comparison page. So read the section that follows this one and learn the difference between the two types of product columns before you start adding your own columns.
So, let's consider for the moment a regular product column with the prefix product_. If you want to add a byte-size variable to the table, you would want to name it something like product_byte_size.
In this case, since the number of bytes is an integer, you would elect to specify a Column Type of INTEGER, and a Form Type of TEXT with a Form Length of 10 (for a maximum of 10 digits input). If you wanted to add a regular expression check which allowed either an empty field or a sequence of digits as input, you would use ^(|\d+)$ as the value for the Form Regex. Because you are allowing an empty field for this column value you would also select No for the value of the Not Null attribute.
Note that you have to give your columns some thought before you add them to the table. Will values be mandatory? What column type best represents them? What Form Type is most suitable for collecting the data? You will need to study the section on ADDING COLUMNS TO A TABLE to get this down. But once you understand how it works, you will find that adding new columns is very easy.
You will find the Add Column link at the bottom of the column definition page when you are ready to get started adding new columns.
Adding New Product Fields To The Templates
After you add a new product column to the Review table you will be able to edit existing Review records and add in the value for that field. However, the new values do not magically appear on your public pages. You MUST add the relevant markup to your templates in order for the new data to appear.
For instance, on the Review tab pages, where product information is presented in the most detail, the content of the pages is controlled by the review.tpl template. You will have to edit this template and add the requisite tags for the data to show up.
Let's say that you added a Review.product_byte_size column and you have populated several of the records with this information. Maybe there are some for which you do not know the value, and those have been left empty. In your review.tpl template you will find a Smarty loop like the following in two places:
[% foreach from=$s.review_info item=review %] some stuff in here... [% /foreach %]
The first loop is used on the product list page to present information on the first few reviewed items. The second loop is used on the product detail (or review detail) page. There is only one element in the loop in this case, but the methodoloy is the same. Both times, inside the loop the $review variable represents a hash (data structure) with all the values of the columns associated with that record from the Review table.
So, inside the loop I can fetch the byte size value using some code like the following:
Byte Size: [% if $review.product_byte_size %] [% $review.product_byte_size %] [% else %] n/a [% /if %]
It's that simple. Well, for simple column types like string and numeric it's that simple.
If you have values that are represented by SET columns, you'll have to work a bit harder since the returned value is a comma-delimited set of values from the list of possible values for that column. So if you had a Review.product_varieties column of the SET type that allowed you to select varieties from the list: 'pro version','deluxe version', and 'free version', then a particular product might return 'pro version,free version' as the value for that column. The Smarty templating system is not the most mature technology, so if you wanted to break this string into parts and format the components separately, then you'll have to put in some work to get it done.
Adding New Comparison Fields
When you look at the Product Comparison page you will see a number of different features compared with one another, from one product to the next. All of these columns are specially named in the Review table. They all have the prefix compare_
You should study the comparison columns that come with the default install. Some of these are FLOAT columns because they are being used to represent numbers, like dimensions, or price, both of which are best characterized using numbers with decimal places. Typically, the other column types that get used for comparison columns are the ENUM and the SET column types. Both of these are used in connection with lists of values. However, a comparison column can have any column type. Common sense suggests that the values of your comparison columns are numbers, or short segments of text, so FLOAT, INT, VARCHAR, ENUM and SET tend to be the column types that you'll want to use for comparing features at a glance.
Unlike the regular product_ prefixed columns, when you add a new comparison column, it immediately appears on the product comparison page. The reason for this is that it is easy to figure out where the column is supposed to go. It simply slots into the tabulated featured, in the same relative position in the table as the column appears in the table. So order your comparison column as you would have them appear on the product comparison page. If column Review.compare_has_legs is in position 11, and column Review.compare_quality is in position 12, then the Has Legs icon will be appearing directly above the Quality icon.
There are two particular types of columns that you'll find very useful when doing product comparisons. These are specially-treated versions of the ENUM. One allows you to indicate whether a feature is absent or present. The other allows you to characterize the feature as great, OK, or weak in your opinion. These two types of ENUM make it very easy for the visitor to assess the features of a product at a glance.
The Present/Absent ENUM Type
If you want to indicate the presence or absence of an important product feature, the way to do it is to make the comparison column an ENUM column with the two possible values of Yes and No. Review Site will recognize this column as a present-or-absent type column, and add special icons to the product comparison page to indicate at a glance whether or not the feature is present. The icons used are these ones: |
|
If you look at the default product comparison fields you'll see that there is a column named Review.compare_has_legs. The column definition used to create this column looks like this:
|
The last two attributes, relating to hiding the form elements, are irrelevant, and not used in Review Site, so you can ignore these entirely.
The important points to note are that the Column Values attribute contains just two values: No and Yes. These are the values stored in the table when a record is added or modified. For simplicity, the Form Values are given the same values. However, the Form Values are never displayed for this special ENUM type. Instead of seeing Yes or No appear on the page, the corresponding Present/Absent icon will be used. So the actual values of the Form Values attribute are not important here. Just use No and Yes, as shown above.
Note also that the Not Null attribute is set to No. This means that you are not required to specify a value for this column. The Default value should be left blank in this case. If you do add a Default value, it will be used to populate the column in the absence of an input value. So only specify a Default if the field represents a mandatory value (a required value).
Finally, note that the Form Type is SELECT, which means that a drop down menu will be used to collect the value for this ENUM column. The other option is to use CHECKBOX, but SELECT has the advantage that you cannot accidentally check a box and then not be able to uncheck it. I recommend you stick with SELECT menus for ENUM columns.
The Gold/Silver/Bronze ENUM Type
The other special ENUM type, which is used to characterize a feature as great, OK, or weak, is similar to the Present/Absent ENUM type, but this column takes one of three possible values: Gold, Silver, or Bronze to represent the rating of great, OK, or weak. These are the icons that are used to represent these ratings:
|
|
|
If you look at the default product comparison fields you'll see that there is a column named Review.compare_quality. The column definition used to create this column looks like this:
|
Once again, the Form Values aren't going to be displayed, because the icons are going to appear instead. However, you do need to specify values, so just mirror the three values that appear in the Column Values attribute. If you use anything other than Gold, Silver, and Bronze for your ENUM column you will not get the special behavior of this comparison column type.
Adding Comparison Column Comments
If you look at the comparison columns in the default installation you will see that the Review.compare_quality column has a companion named Review.compare_quality_comment. When you add a column named after a comparison column, but with an appended _comment suffix, the column will be treated as a comment that should be included along with the comparion value. So when you attach a comment to one of the iconed ENUM columns, the comment appears directly underneath. This is useful, in particular, for qualifying the ratings of great, OK, and weak. Comments aren't always needed, but they can be useful. Your comment column should be short VARCHAR column. For example, here is the column creation form for the Review.compare_quality column:
|
Note that in this case the Column Type is VARCHAR with a maximum length of 32 and that the Form Type is TEXT with a maximum input length of 32. You can bump this up to 64 if needed, but these comments are supposed to be short because they appear on the product comparison page. The Not Null attribute is also set to No so that comments are optional and not required.
Adding New Review Fields
You probably don't need to add new columns that relate to your review. The currently review_ prefixed columns should be enough to adequately cover everything you need to add for your review. However, you can add new review columns if you like. I refer you to the general section on ADDING COLUMNS TO A TABLE.
Just remember to prefix the new review-related columns with the string review_ so that they can be grouped together in the Smarty $review data hash that is made available on the review pages. Then you can fish out the relevant information by using the corresponding tag. If your new column was named Review.review_date then you can access this information (within the loops for which the $review hash is defined) with a tag like this:
[% $review.review_date %]
Formatting the date is another matter. Study the Smarty templating system if you are going to add fields to your tables that need to be formatted after being extracted. The complications that arise when you make customizations of this nature are beyond the scope of this manual. If you cannot figure out how to do something like this, then don't add complex columns to your table. Stick with what you can handle.
Deleting Existing Fields
Deleting a column from a table is very easy. The Delete Column link is found at the bottom of the column definition page for a given table. Be sure that you want to remove the column from the table, and its value from all records in that table, before you go ahead and do it. Once a column is deleted, there is no getting it back.
Product Images
If you think I have already covered the topic of product images, you're right. I have. But it is better that I repeat this information in the manual than to repeat it a hundred times in the support forum, which I have no intention of doing.
Product images are treated very simply in Review Site. There are two special columns in the Review table that are used to specify the file names of product images. These are Review.product_image and Review.product_thumbnail
These two columns are to be used to specify the file name of a "large" and a "small" version of a product image. So, for example, stauer-mens-watch.jpg and stauer-mens-watch-small.jpg
Note that these file names do NOT include any directory path information. The reason for this is that the location where they will be found is already know, and it is specified below.
The suggested sizes for large and small images are 240 pixels by 240 pixels, and 120 pixels by 120 pixels respectively, but it is entirely up to you. No attempt is made to scale images in any way.
If you specify file names for these image columns, then the corresponding files are expected to be found in the following directory, and it is up to you to put the files in there, before you specify that they be associated with a particular Review record:
/rs/reviewsite/my/skins/default/images/product
Other Images
If you decide you need to add more than the main product image to the page you will have to understand how the review.tpl template works so that you can modify it.
The task that confronts you is to:
- Add columns to the Review table to store all the information about the image that you might want to add to the page.
- Add Smarty tags to the review.tpl template to format the data into an <img> tag.
At a minimum You'll need two extra Review table columns, which we will call product_image_2 and product_image_2_description. See the general section on ADDING COLUMNS TO A TABLE if you aren't sure how to add new columns.
I would make the image URL column a VARCHAR(64) and the description column a VARCHAR(255). Those sizes ought to be large enough to capture the data for those two pieces of image data. You should also set the Not Null attribute to 'No' for these two columns so that you can elect NOT to add the data if you do not have a suitable image to use.
Once you have added those two new columns, you can populate them by editing Review records using the Database control panel.
Finally, you are going to need to extract the data and add it to the review.tpl template. You might add something like the following in whatever spot in the template seems appropriate for the image. I personally would probably use a floating table element so that when the image is missing, it is filled in with text, either from the product description field, or from your review:
[%* extra code to appear somewhere in review.tpl *%]
[% if $review.product_image_2 %]
<table style="float: left; padding-right: 10px; padding-bottom: 10px;">
<tr><td>
<img src="[% $s.images_url %]/product/[% $review.product_image_2 %]" border="0" />
</td></tr>
[% if $review.product_image_2_description %]
<tr><td>
[% $review.product_image_2_description %]
</td></tr>
[% /if %]
</table>
[% /if %]
Something like that. This assumes that you are adding the image to the SAME directory used to store all your primary product images, and that when you enter the value for product_image_2 into the Review record, you simply add the image file name. If you store your images elsewhere, then you might want to simply add the relative URL for the value of product_image_2, and adjust the Smarty code accordingly:
<img src="[% $review.product_image_2 %]" border="0" />
It's up to you to figure out a system that works for you. Remember, the Smarty templating system was employed so that you can do virtually WHATEVER you want to your templates. You can do extremely complex constructions, but it's up to you to get the logic right.
Of course, the basic process of adding columns and then adding corresponding Smarty code applies to ANY kind of extra data you want to add to either Review or Article records. The Review Site tables have the most basic fields added to them upon installation, but you can always add more if you have the need for them. It will depend on your niche.
Next Section: UNDERSTANDING ARTICLE RECORDS
« Table of Contents | Obtain Review Site »
Copyright © 2008 Random Mouse Software. All Rights Reserved.