TFBW's Forum

Discuss
It is currently Mon May 22, 2017 9:27 pm

All times are UTC




Post new topic Reply to topic  [ 1 post ] 
Author Message
 Post subject: Thoughts on content management
PostPosted: Thu Aug 03, 2006 5:10 pm 
Offline
Your Host

Joined: Mon Jul 10, 2006 6:57 am
Posts: 204
Location: Sydney, Australia
Having just spent the better part of a month setting up TFBW.com (and other sundries like this forum), I've been prompted to think about web content management again. The last time I did that with any great seriousness was when I migrated Nutters.org from static HTML to Zope, so it's been a while! Things have come a long way, too, or I wouldn't have bothered with TFBW.com at all.

Despite the improvements, however, things still aren't where I'd like them to be. This isn't very surprising: I usually think so far 'out of the box' that most people have no idea what I'm going on about. For my own reference, as much as anything else, I'm going to document here my current thoughts in relation to the experience with TFBW.com. This will be in the form of a brainstorm rather than a structured argument. Structure is for later.

I chose WordPress 2.0 as my content management system. Strictly speaking, it's not a CMS: it's a weblog with accumulated features. I chose it for two reasons, the first of which is the simple fact that it's readily available at Dreamhost, which is where this stuff is hosted (at the time of writing). They do also provide Joomla, a full-featured CMS, but my second reason for choosing WordPress was that it didn't overwhelm me with features I'll never use. WordPress 2.0 allows a hierarchy of static pages in addition to the blog entries, and this seemed to be about all I needed.

WordPress suffers from the same problems as most other things in this area. It has a lot of documentation, but it's poorly organised and reactively maintained. It's PHP and MySQL under the hood, but they've made a slightly half-baked attempt at hiding the gory details from the web designer. In order to get TFBW.com going in the manner I desired, it was necessary to scratch the veneer and engage in some real PHP hacking, albeit on a very small scale.

What WordPress gets almost right is the notion that 'weblog posts' and 'pages' are basically the same thing organised differently. I say "almost right" because it's clear that pages are hacked posts, rather than the two deriving their common elements from a common base.

I'm also a little leery of the MySQL obsession so prevalent in the PHP world. I am utterly unconvinced that TFBW.com needs to be based on a relational database. Indeed, I suspect that it's more a waste of resources and a load of unnecessary overhead. The site could easily be served up from static HTML pages, yet I'm engaging in goodness knows how many SQL queries every time someone requests a page. Yes, I could turn on the page cache, but I've had trouble with it dishing up blank pages on cache misses, and a page cache is just a way of reducing (rather than eliminating) the overhead.

So here's what I'm thinking at the moment in terms of a site management system.

I think the site should be served up from static files where possible. Factoring out common bits into shared files is a reasonable idea, and this can be achieved with server-side includes. They're a bit old-fashioned, but they have their place.

Server-side scripts should only be used when they're really needed. They're a drag on resources in other instances. A lot of the work can be performed by the client using Javascript. This has its limitations, of course, but so-called "Web 2.0" applications have shown us that these limitations aren't strictly very limiting.

I'm not at all convinced that I want a site management interface. Yes, they are convenient sometimes, but I wound up doing a lot of text file editing when making TFBW.com, and this was better performed in a terminal-based text editor than it was in the management interface! If weblog posts and other pages were simply created as text files in a particular directory, I probably wouldn't need or want the management interface at all.

This deprecation of server-side scripts and interactive stuff generally means that the site can be built in advance rather than on the fly. The server can dish up static pages rather than performing live database queries. This has the added advantage of robustness: no more "can't connect to database" rubbish when the MySQL server is down.

The process of building in advance rather than on the fly makes the process a lot more like computer programming. Your website becomes a programming product, and you modify it, test-compile it, lather, rinse, repeat, and eventually release it. All my TFBW.com hacking happened on the live data, which is not ideal.

The parallels with computer programming also suggest that version control would be a good idea. Actually, version control is pretty much a good idea with any written work of any substance. Site editors should be able to make modifications in a private branch of the site, then merge it back into the main and release it.

One of the things I dislike most about PHP, ASP, JSP, and their ilk is the mixture of markup and code. It's ugly and dense. The Document Object Model provides an excellent way of eliminating this mess: write the skeletal document in true XML, then fill out the blanks using the DOM interface. If this isn't practical, there's still the possibility of using Javascript on the client side to do most of the work: the dynamic part can be provided as XML, or even as dynamically-generated Javascript (just data declarations) rather than as the usual mix of static HTML and generated HTML.

The modules in WordPress (and just about everything else) still aren't quite carved up the right way. I need a "basic document" module that can convert a simplified markup into HTML for weblog posts and other pages. Its output can be a well-defined subset of an HTML document. Separately, I want modules which organise documents, working entirely with their metadata, and providing me with an object interface so that I can produce links to relatives, breadcrumb trails, and other navigational aids. Separately again, I want the ability to create comments, and have them associated with documents. Existing apps like WordPress tend to group these features together into a product like "weblog", rather than assemble modules into such products.

Here's roughly how I see it happening. I have a repository of site files, and I check out a working copy. I'm making some significant changes, so I branch off a copy with which to experiment. I build this experimental site by checking it out (or exporting it) into a staging area on my webserver, then executing "make" or similar. This generates the live data from the site spec, and I can browse it. When I'm happy, I merge the changes back into the main branch, export and build that on the webserver, then cut over the document root of the main site to the new directory (probably by changing a symlink).

That's enough brainstorming for now. Chip in your own two cents worth if any of this makes any sense to you.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group