Dissecting front page, part 3

Let’s continue the front page analysis after a longish pause. The previous article finished the left column and now it’s time to move onwards with the rightmost part of the page.

This part of the front page concentrates mostly on the reviews. Oddly enough, majority of the current visitors tend to find their way to the reviews using search engines. Maybe I write reviews from such locations or places that are interesting, but still not covered by any major travel review site.

The reviews provide also good opportunity to add some semirandom content to the front page to keep it fresh for those people that visit the site several times between two journal entries.

The topmost part of the right column has buttons for changing the size of the fonts (13). In Internet Explorer, there is yet another button for adding the page to favourites. If anybody knows how to do this trick in other browsers, please let me know.

The font change is done by switching the active stylesheet in JavaScript. The used fonts are defined in very small stylesheets that import a shared stylesheet that has all definitions not depending on fonts. This arrangement eases up editing and saves bandwidth.

The Reviews section (14) shows three random reviews from the most frequently visited categories: Restaurants, Accommodation and Shopping. There is a MySQL clause that is executed in a loop to produce the data. The topmost review is cut after two paragraphs and the two others have only one paragraph.

The review header (15) contains a link to the appropriate review category and basic information about the reviewed location. The title of the review is a link for the whole review. There is a similar link at the end of each review, coupled with a link to the reviews front page.

The Recent Reviews section (16) contains six latest reviews in the database. These are selected with one MySQL clause that sets them in the correct order based on the timestamp inserted by WordPress. Only a few fields are read and the clause has limit keyword to read the desired number of rows. The read information is prettyprinted in a loop. The data is shown in an HTML table as floats were broken in some browsers and the table just fits better for showing tabular data.

More Reviews (17) drop-down box is created again in a loop that iterates through rows resulted from a MySQL query. The query itself is complex as it has to join an SQL table onto the same table. This had to be done, as the review countries and cities are stored as WordPress custom fields. If I would have just shown cities or countries, I wouldn’t need this complexity.

The result set is ordered by the country and the city, in alphabetical order. The loop iterates through cities and when the country value changes, it prints out the previous country and all the cities in a data structure that it has been creating. Now the data structure is cleaned and new cities are piled there, until a new country pops up or the result set is exhausted. The number of reviews per country is just a sum of the reviews in cities in that country.

The big numbers (18) are generated by an SQL clause that counts the various review types from the database. The results are stored in array, and the number is picked using the name of the type in PHP code. Very simple code with lots of HTML embedded.

The bottom part of the right column contains an internal banner ad (19) that hopefully lures visitors to the other parts of the site. These adds are written into one PHP file that has simple random statement to select the correct code to be shown. There is a bit of logic to prevent ad pointing to the current section. Every Nomadig.com section has a unique identifier that is known by the PHP scripts, and that identifier is checked against the identifier in the ad. If they match, the next ad is chosen instead.

This pretty much covers the cover page. There is one additional perk that is not easily visualised: There is a small pane under Other Nomadig.com Services. This pane is used to balance the left and right columns. The length of the content changes for every page load and thus the HTML may have blank spots. There is no good way to instruct browsers to stretch a div vertically to cover everything, and thus there would be areas that show pure white — the background colour of the page. This wouldn’t be a problem if the text background would be white, too. This is not the case here, so I had to do some JavaScript magic.

There is a small JavaScript snippet after that balancing div that calculates the vertical position of that div and the vertical position of the Sections div at the end of the left column, and adds their height to those numbers, respectively. This provides me the position of the lower edge of the divs. If they are not equal, and usually they aren’t, the column with smaller number will be stretched with JavaScript to fill the rest of the space.