I’ve been hard at work setting up blogs
and CMS software this month. Just in case you’ve been on
holiday in some far corner of the Galaxy for the past few
years, in which case you won’t have a clue what I’m
rambling on about, CMS stands for ‘Content Management
System’ and it describes a kind of software that
lets you create dynamically updated web sites. Instead
of creating each page from scratch, you just design one
page layout then make numerous entries in the form of text
When someone wants to view a specific entry, the CMS puts
the text, pictures and layout all together in order to
display the page. Blogs are a specific type of CMS which
enable people with a limited grasp of their native language
to bore the rest of humanity with the details of the most
trivial details of their tedious daily lives. A bit like
Rants and Raves, really…
The first Blog system I used in earnest was Pivot. This
is far from being one of the best known but it has the
distinct benefit of being easy to use and doesn’t
store its data in a database. For novice users this is
a big plus. Not only does it mean that you don’t
have to set up a MySQL database on your web host but you
can also download your entire Pivot weblog, data and all,
just by copying files.
When I recently set up a second Blog system, this time
for sapphiresteel.com, the site of a Ruby programming IDE
currently under development, I opted for the better known
WordPress Blog system. This is also fairly easy to use
but it does require a MySQL database.
The Fantastico control panel should (in theory) make
it easy to install or upgrade software such as WordPress.
Only human stupidity gets in the way... :-(
Initially, I installed WordPress 2.0 with the help of
the Fantastico control panel provided by my web host. Fantastico
automates most of the time-consuming steps of an installation
including uploading the files, creating a database, changing
the permissions of files and directories and so on. The
downside is that Fantastico updates tend to lag a few weeks
behind the updates of the individual programs so if a critical
fix is issued, you may be tempted to do a manual install
in order to fill in any security holes as quickly as possible.
But once you’ve patched
an installation manually, Fantastico may refuse to do any
automatic updates in future. I decided, therefore, to wait
a few weeks until the official Fantastico update for WordPress
Alas, when it did appear, the auto-upgrade option in Fantastico
did not (appear, that is). I exchanged many emails with
tech support people but the boffins were baffled. So, in
the end I decided to do a manual upgrade. I backed up the
MySQL database, I backed up all the files in my config
directory plus a little file called .htaccess which programs
on Linux seem to worry about a great deal. Then I just
uploaded the new files over my existing ones and ran the
WordPress upgrade program. Oops! It couldn’t find
the database connection in my configuration file.
Configuration file? Configuration file? What Configuration
Pulled Up By The Roots
Urgh… it turned out there was one more file I’d
forgotten to backup and, without that, my Blog wasn’t
coming out to play. Well, let’s see, what’s
in that file, anyway? A user name, a database name and
a database password. Maybe I can just enter those myself.
Oh, but wait a minute - what database password? Oh, the
one that WordPress creates automatically during installation,
probably. Unfortunately, it didn’t tell me what it
was and I couldn’t see any way of finding out.
Have you ever had one of those days? Me, I get them all
Oh well. Time to pull out my hair, kick the settee (I
would have kicked the dog but she kicks back!) and do a
complete re-install from scratch. This is the online equivalent
of reformatting your hard disk. I deleted the database,
deleted every single file and told Fantastico to do a complete
new WordPress setup. Eek! It wouldn’t let me! It
said I already had a script in my home directory and no
more than one script was allowed. But, what the heck, the
home directory is empty. Look at it: zero, zilch, vacancy,
After half hour of hunting around I eventually found a
file hidden way up above the root of sapphiresteel.com
and down in a directory called .fantasticodata. The file
had the suspicious name installed_in_root.php and when
I opened it this is what it contained:
I was in a file deleting mood by now so, in a moment of
frenzy, I deleted the file and started all over again.
Look, I know I may have made some silly mistakes. You
don’t have to tell me – I know it was my fault
that I didn’t backup every single thing before trying
a manual upgrade. All the same, I am not exactly a novice
user and if I can make silly mistakes, I’m sure there
are plenty of other people in the world who can make ever
sillier ones. All of which makes me think that the current
reliance on PHP applications hosted on Linux, with a dash
of Apache and MySQL for good measure is not the be all
and end all in user friendliness. There really must be
a better way of doing this!
Joomla is relatively easy to use and has a nice administration
interface (shown here) which, I am encouraged to
see, does its layout with tables - but maybe not
for much longer...
The next thing I did was to install the Joomla CMS – this,
for another project which I’m keeping to myself for
the time being. So far so good with this. The standard
Joomla installer (even without the help of Fantastico)
sets up the database for you and deals with all those pesky
Linux file permissions. Thus far, Joomla seems reasonably
easy to use, though, as with so much open source software,
the documentation is not all it might be. There are lots
of explanatory technical documents on the Joomla site but
not so much in the way of hand-holding tutorials that actually
tell you how to use the damn’ thing. I’ll have
more to say on Joomla in a future column.
Style Sheet? Bull Sheet...!
One of the things that drives me up the wall about the
Open Source development community is that many of them
seem to live in a hermetically sealed world in which everybody
codes (or ‘hacks’) in PHP; web page layouts
are defined using cascading sheet sheets rather than plain
old HTML; and if you ignore Microsoft maybe it’ll
just go away.
Open Source advocates have their own special jargon to
reinforce this world view. The term ‘a non standards
compliant web browser’, for example, is their way
of saying ‘Internet Explorer’. The fact that
IE happens to be the most widely used browser on the planet
is often dismissed as a minor annoyance. Well, frankly,
people can define as many standards as they want but if
most people use something else, then, that is the standard.
As Borland used to say in the old days, ‘Turbo Pascal
is the de facto Pascal standard’ – nope, it
didn’t conform to any of the standards defined by
the standards committees; but it was the only Pascal that
had any major market share, so what the Hell!
In the CMS community, there is an almost universally accepted
article of faith which states that cascading style sheets
are the One True Way. I’m sorry, but I beg to differ.
In my view, style sheets are all fine and dandy for, well,
setting styles. But for laying out web pages they are dreadful,
awkward, ineffective, messy or, to put it more succinctly:
just plain wrong.
I’ve set forth my views on
CSS before. I was hoping
that, over time, I would gradually come to see the hidden
benefits of the damn’ things. Well, I haven’t.
Actually, when I started using Joomla I was pleasantly
surprised to discover that it uses tables for the principal
elements of its layout. At last, I thought, a CMS which
dares to stand up against the CSS zealots!
My joy was short lived.
Compass Designs have some great tutorials for Joomla
users and designers and I don't want to seem ungrateful.
As I wanted to master the art of Joomla templating, I
sought out some tutorials. Considering this package is
so widely used, there are surprisingly few readable and
comprehensible tutorials around. It took me some time to
track one down – a pretty detailed Joomla template
tutorial from Compass
In a little over 50 pages, the authors explain pretty much
everything I need to know to create my own custom templates
for Joomla. Before proceeding any further, let me say that
I appreciate the effort they put into this document. It’s
helped me a lot and I recommend it to all Joomla newbies.
Had the authors confined their mission to the purely explanatory,
I would have been positively gushing in my recommendation
. Unfortunately, they were unable to resist the temptation
to do a good deal of proselytization on behalf
of CSS along the way. I note that they are members of the
official Joomla Documentation Team, and they say that Joomla
will be going further down the slippery slope towards CSS
(not their actual words, you understand) in future versions – a
fact which did nothing to lift my spirits.
The authors’ arguments in favour of CSS layouts
over HTML tables can be summarised as follows:
require more HTML code.
- Tables are difficult to maintain “To
change something you have to figure out what all the
td/tr are doing. With CSS there are just a few lines
- The content cannot be ‘source
apparently, is required when viewing web pages in something
other than a graphical web browser.
OK. So let’s take these criticisms one by one.
1) Yup, I’m prepared to accept that tables may indeed
require more HTML code. They also require less CSS code.
And anyway, what the heck!, compared to the amount of time
it takes to download graphics or generate HTML pages from
PHP or load and style the content using CSS or do any number
of other things needed to get a page up on screen, I really
don’t believe the extra code in a table takes up
huge amounts of time to render. What I do know, from bitter
experience, is that it does take a great deal more development
time to create a page layout with CSS than with tables.
The designer is forever zipping back and forth between
a file containing CSS styles and the HTML web page to which
they apply. Moreover, designing with CSS is not a ‘what
you see is what you get’ process. You constantly
have to guess what the effect might be, try it out, then
go back and fix the problems. With a table you just drop
it on screen in a web design tool such as Dreamweaver,
and make any changes before your very eyes.
2) Tables are difficult to maintain? Really? “To
change something you have to figure out what all the td/tr
are doing.” Sorry, but I don’t have to figure
that out at all. That’s Dreamweaver’s job.
It shows me exactly what those table cells and columns
are doing. But CSS on the other hand? Now that really is
difficult to maintain. The authors, of the Joomla template
guide, know this to be true, even though they are reluctant
to admit to it. I refer you to their tutorial on
creating a three column Joomla theme.
This begins with this admission:
“Let's face it, making
a Joomla theme with tables is easy. That's why we all
did it (may we hang our heads in shame). Achieving the
same using CSS is much harder.”
go further, it’s not only harder; it also doesn’t
do the job as well. I recommend that you follow the links
to other tutorials listed on the 3
Column Tutorial page.
When you arrive, try reducing the width of your web browser
to see how well those columns resize themselves. One of
the features of ‘fluid’ (i.e. resizable) columnar
layouts with CSS is that the columns and/or the text, have
a nasty habit of shifting about all over the place when
the browser is resized. At best, the columns may become
uncomfortably thin with the text trickling around to places
where it shouldn’t be; at worst, the columns themselves
start moving around, popping unexpectedly down to the bottom
of the page or obscuring other columns. Why do CSS designers
waste so much time and effort on this when the end results
are so imperfect? If they’d only used tables, the
design would have worked first time.
3) Source ordering. OK, I’ll admit this may be a
problem. If people use text based browsers (maybe on mobile
devices) or readers which narrate onscreen text in a synthesised
voice, it is quite conceivable that CSS layouts may be
better than tabular ones. I say ‘may be’ since
I haven’t done any special research into this, don’t
know if tables can be source ordered like CSS layers and,
in any case, note that some CSS tutorials make a
distinction between ‘fluid’ and ‘source
ordered’ layout, which suggests that source ordering
may not be any more a ‘natural’ feature of
CSS than of tables. But, hey, I’m feeling generous.
I’ll give CSS the benefit of the doubt on this one
and say that maybe it scores over tables in this respect.
Right Problem, Wrong Solution
Don’t get the impression that I am completely averse
to cascading style sheets. When used within the limits
of their competences (for setting styles - such as colours
and fonts) they are fine and dandy. I will also accept
that they have one other great advantage – by keeping
the style information separate from the individual web
pages, they make it easy to change the appearance of tens,
hundreds or thousands of pages just by making changes to
a single style file. It is this latter features which,
I believe, has led them to be so widely abused. If style
sheets make it so easy to change the font and paragraph
styles throughout an entire site, well (say the CSS converts),
well, maybe they can be used to change layouts too! And
thus the rot set in…
It would, indeed, be very useful to be able to change
the design of pages throughout site in this way.
But style sheets are not the place to do it. Instead what
is required is something like an HTML templating system
in which a single template file is dynamically applied
to multiple web pages. I don’t know what, if any,
solutions may emerge to this problem in future. All I hope
is that something arrives sooner rather than later. In
the meantime, the more people who champion the wholly inappropriate
CSS as a solution to the problem, the less likely it is
that a better solution will emerge.
So, in brief, folks,
don’t do layout with CSS. Come on, in your heart
of hearts, you know it makes sense…