One of the benefits I reap from
my move to DreamHost is the fact that I can now host multiple websites in parallel. This allows me to run both the production website and the
work in progress on the same system, without one affecting the other.
For this overhaul of the site I've got two major changes planned:
1. The whole look and feel of the website.
2. Programming like I should, not like I can.
The first goal is easy to describe. My website has had the same look for over four years now, with only minor changes being made to banners and logos. This may make it recognizable, but it's also become a bit boring.
Understated may be good, but
dull never is. I'll still be using the same basic elelments, but they'll be arranged differently. The menu structure is going to change quite a lot and hopefully things will look just a bit more
spiffy(tm).
The second goal is going to take a lot of hard work and a lot of deep thought. I recently read an article that suggested that one should keep
all content in the backend database, as opposed to in the code. This may sound logical, but how many people fall for same trap?
For example, the menu in the Archives contains a list of months for each year with a month being a link to the list of relevant posts. If there aren't any posts for that month, there are no links. In theory that sounds great, but in reality it's all hard coded :( While it would be relatively simple to write the code to automatically generate the menu structure, I've written out all <a href> lines by hand. Yuck!
The menus in general are a good example as well! Instead of generating the contents of the menu automatically, I've created a bunch of HTML files with all the links that get included by PHP. Nasty. The same goes for all the articles I've written so far: all included HTML files.
But all of that is going to change! I've already redesigned the database backend and implemented the requisite changes. The picture above is a model of how things connect. When compared to other websites it's definitely not rocket science, but it's still a nice learning experience for me. For example, all the yellow tables are
supporting tables that contain lists of types. Types of items, types of wishes, types of beliefs, types of links. E.g. wish X is of type 3, which in table
wishtypes relates to the type
book. I'm sill pondering whether I should just pile all types into one big table, thus saving a bit on complexity...
Some of the more intricate stuff that I'm looking at regards the sections of my site. Currently the division is made with file system directories. With my new approach I'll be using a new database table (
sections) for the same purpose, although I'm not entirely sure if I'll completely drop the use of directories. The sections also have a great impact on the menus, since this time around I'll be using the titles and section numbers for articles to build the menus. This left me with one quandary: how to properly sort the menu listings. For now I've opted for an approach similar to a tree (the programming structure, not the foliage) where each article has the
below characteristic that contains the ID number for the article above it.
Ah well... Loads of work to be done! :) Let's get crackin'!
Posted in:
backend
,
database
,
php
,
redesign
,
website