NOTE: Much of the below won’t make sense unless you actually click through the Version 3.0 website. A lot of the descriptions below do not apply to the current version of the website.

You can still peruse Version 3.0.

What is it about physical injury that motivates me to do web development? A serious flu while in Banff put me out of commission for about a week and that’s what sparked the Version 2.0 redesign. This time, it was a lower back injury incurred the day after the Mammoth trip. This little incident put me out of physical activity for over 3 weeks and this is what I spent most of that time (plus a lot of additional time) doing.

So what’s the big deal about this version? After all, it doesn’t look that much different from the last version [Although it doesn't look much different, it does look a lot different from my original intention. At the start, my plan was to introduce Version 3 without any cosmetic changes. As I progressed, however, I decided I might as well just go all the way and also modify the overall look of the site]. Well, to use a well-worn cliche, looks can be deceiving. The vast majority of the changes are more than skin-deep due to a radical overhaul of the entire back-end of RohJuh.com. These improvements not only enable the addition of discussion forums, but more importantly, it provides a much more efficient method of site and content management, and dramatically reduces the efforts required for future site redesigns.

Forums, PHP, MySQL
Ever since RohJuh.com was first introduced, I wanted to add a discussion board but just never got around to it. Just prior to my back injury, I began giving this more serious thought and started to devote some work to it. The first question was which technology to base things upon? Chris Tuft, my Mac Guru Extraordinaire, had created a nifty little web app on his website in which one can access some of his family’s food recipes based on various criteria. It was driven by some UNIX cgi scripts and a PostgreSQL open-source database. An appealing aspect to using cgi and PostgreSQL was that Chris was available for help if I encountered any problems.

I did some research on my own and found that the PHP/MySQL application server/database combination is extremely popular throughout the world. Many large websites are driven with them. It was certainly a tried, proven, and capable technology. They were both open-source programs, and because of the pervasiveness of their use, there was no shortage of online documentation. And since PHP was designed expressly for web applications, it was favored by many web developers. Chris had not actually used PHP before, but many of his geek friends had and regarded it highly. Mac OS X is based on UNIX, so it was definitely possible to run this combo on my G4. In fact, Apple actually includes a PHP module with OS X. I made the decision to power the RohJuh.com discussion forums using PHP/MySQL; it seemed like the right way to go.

I got both PHP and MySQL set up without much of a hitch (big kudos to Marc Liyanage who provides an easy-to-use OS X package installer for both PHP and MySQL at his website. Aaron Faby also provides an easy-to-install OS X package, but I personally have not used it). I also got a copy of “Designing Web Database Applications with PHP and MySQL” which turned out to be really helpful. As I started designing the discussion board app and learning the basics of PHP and MySQL, I began to realize the broader potential of PHP and MySQL beyond just a discussion board. It seemed well-suited to address a growing problem that I was beginning to have with RohJuh.com.

Dreamweaver: Great Tool but Not Without Limitations
Until now, Dreamweaver has been my primary tool for web design. With a WYSIWYG (What You See Is What You Get) approach to web page layout, it shields the user from much of the nitty-gritty HTML code details. This can be good and bad. It is good in that it enables novice web designers to create websites fairly easily. It is bad because the user need not learn HTML. A good understanding of HTML is very beneficial especially with more involved web designs and also during troubleshooting.

Dreamweaver allows you to create a template for your site which enables your site to have a consistent look and feel throughout. Within the template, you can define “editable” regions and “non-editable” regions. The non-editable regions are the areas that remain constant through the site. When you change a non-editable region in a template, Dreamweaver updates all the pages throughout the site that are based on that template. Editable regions for each page are, by definition, editable, and the information placed in editable regions are therefore unique to each page.

On RohJuh.com, you’ve likely noticed that all pages have a similar look and feel to them. The Nav Bar (the Aqua tabs) across the top and the footer along the bottom look similar throughout the site. Perfect for a Dreamweaver template, right? Well, not exactly. If you look closely at the Nav Bar, you’ll notice that different tabs are either “active” or “inactive” depending on the category of the page. If you’re looking at the Featured Adventure, for example, the Featured Adventure tab is active while all the other tabs are inactive. Because of this, the Nav Bar region must be an editable region (since it varies depending on the page) and therefore becomes a permanent part of the HTML code for any specific page. If I wanted to redesign the site with a different Nav Bar, I’d have to go into every page and make those modifications. At the introduction of Version 3.0, RohJuh.com had over 60 pages! To individually modify each of those pages would be an extremely mundane task! As more and more pages get added, the problem is further exacerbated and the chore of a redesign becomes ever more daunting.

PHP Hypertext Processor
PHP is one of those weird UNIX-geek recursive acronyms (like GNU is Not Unix, or WINE Is Not an Emulator). It is a programming language complete with variables, conditional statements, functions, etc. During the processing of a .php page, the web server (with an enabling php module) outputs any html code it encounters as is, and processes any php code accordingly. You can jump into and out of php mode as often as you like, and by outputting within php mode, you can actually generate html code. The idea is that the final file that the web server serves up is completely in html and therefore readable by the end web browser (i.e. Safari, Mozilla, Netscape, Internet Explorer). Some of the html may be straight html from the .php file, while some of the html is dynamically generated by the php code. A web page can thus be defined on the fly and various aspects of the web page can be created based on programming logic.

A good example of how this comes in handy on RohJuh.com is the navigation tabs along the top. PHP code selects which images to use based on the “category” of the page. If a page is in the “about” category, the page will be processed such that the active “about” tab is displayed instead of the inactive “about” tab, and all other tabs will be in the inactive state.

MySQL Database
So where is information like the “category” stored? That’s where MySQL comes in. A MySQL database stores key information about every page with fields like page title (the html page title), category (about, featured adventure, misc stuff, archives), title (this is the article title like Moab, Utah), subtitle, trip start and end date, last updated date, and content path. Each page is identified by a unique “pageid”. The content file is html and is typically (with some minor exceptions) a single-cell table set to a width of 100%. In the main page.php, there is another table where the width is set depending on what is desired. The content html (a single 100% wide table) is then pulled into the table in page.php (a table within a table), and since the width of the inner table is 100%, it expands to fill the outer table. The content is thus sized according to what is desired.

Style Sheets
Although style sheets were used previously, they were not used very extensively. In Version 3, style sheets are used far more pervasively. In addition to the regular text on each page, they’re used to style the pictures on each page, the header tags, and the titles and subtitles of each trip page. Previously, the titles and subtitles were static gif’s because I could not achieve the look I wanted through HTML. Although style sheets don’t quite give the font control of a graphics program, they do provide far more control than HTML. More importantly, they provide much more flexibility. Now, if I want to change the look of the titles and subtitles, a single style sheet modification makes it happen. In Version 2, I’d have to manually change the .gif in every single page. That’s a big time savings and will only get bigger as RohJuh.com continues to grow.

The whole idea behind style sheets is to separate the content from the presentation. Prior to Version 3, true separation did not exist because each page contained presentation information. Now, a single page with style sheets controls the entire structure and presentation while the content is a completely separate file and thus completely independent from the presentation.

Dynamically Generated Pages
So this is what happens when you, the end user, click on a link to somewhere on RohJuh.com:

• The clicked link makes a request to RohJuh.com for page.php where pageid=7 (7 is just an example).
• page.php contains php code which makes a request to the MySQL database to retrieve all the information about the page with pageid=7.
• The web/app server then creates the web page based on this info. It creates the navigation tabs based on the category, inputs the html page title, prints the article title and any subtitles (including trip start and end dates if present), retrieves the content, and pulls in the footer. The resultant output is a file that’s completely in html.
• The html file is loaded by the end-user’s web browser which then displays the page on the web browser, interpreting the style sheet to style the page as instructed.

Pretty cool, huh? So now, if I ever decide to redesign the look of the site, I only have to make modifications in one place rather than modify every single page in the site. All the key information about each page is stored centrally in a database for easy access and manipulation. Not only that, but having all the data stored centrally and called up as needed reduces a lot of redundancy. For example, the “What’s New” column on the Home page lists all the new content while the Archives page lists basically all the content from the past. Each of these pages previously had to be manually updated, and since they had overlapping content, there would often be redundancy (the same content manually entered in more than one place). With a dynamic website, these sections can now be automatically generated. It was a heck of a lot of work, but once implemented, it will make things a lot easier.

The Downside
Does such a system have any disadvantages? Well, yes, kind of. By introducing another layer of processing, the response time of the website may be adversely affected. Previously, the only thing being retrieved was a single, static html file. Now, information must be retrieved from the database and the web page must be dynamically generated before the info can be sent to the end user. This additional overhead slightly degrades the end response time. For the most part, however, it is not that noticeable in my opinion. And it’s definitely something that can easily be improved with new hardware. After all, my G4’s over 3 years old and significantly slower than today’s machines. Despite some minor performance setbacks, I feel that the benefits far outweigh any downsides.

Hey, What About the Forums?!!
Oh yeah, the forums. That was really the thing that originally brought about all of this other stuff. Well, I started out writing my own forum application. I knew that there were free bulletin/message board packages out there, but I wanted to write my own from scratch to help me learn PHP and MySQL. I started writing it and the app was actually coming along quite nicely. I knew from the beginning, however, that a self-made discussion board would be pretty rudimentary. If I wanted some of the cooler features, it would take me a very long time to write on my own. As I was nearing completion on my simple message board, I decided that I had gotten what I wanted out of it, namely to learn the basics of PHP and MySQL. With that objective accomplished, I decided to simply install one of the free packages.

phpBB
I ended up going with phpBB because it was open-source, nice-looking, easy to set up, and generally well-regarded. A basic setup was a breeze. The harder part was customizing the look of the application to integrate with the rest of the website.

Admittedly, phpBB is probably a bit of overkill for RohJuh.com. It is unlikely that RohJuh.com will ever become a high-traffic message board. I really was just looking for something simple so people could post comments about the trips. phpBB has a bunch of features that probably won’t be used, but that’s perfectly OK because it does have lots of features that I think people will use. And if for some reason RohJuh.com Forums someday needs higher-end capabilities, phpBB will be able to accommodate them.

So there you have it. If you’re still reading, congratulations, you’re a certified geek! There’s simply no mistaking that fact if you’ve taken the time to actually read this far. Now that you know just about all there is to know about the making of RohJuh.com Version 3, you can click around the site with a greater appreciation of all that is happening behind the scenes to present the pages that appear before your eyes. And perhaps more importantly, you can impress your other geek friends with your newly acquired knowledge of dynamic web pages. Happy clicking!

NOTE: Much of the above won’t make sense unless you actually click through the Version 3.0 website. A lot of the descriptions above do not apply to the current version of the website.

You can still peruse Version 3.0.

Posted by Roger at 7:06 PM.