Tips for building some sort of blogging application from scratch

December 9, 2003 1:32 PM

I'm well and truly sick of hand-coding my website, and so it's about time I got myself some sort of blogging application. Because I'm a contrary type, though, I'd quite like to have a go at building it myself. What do you think - is there any point at all in my trying this? If there is, should I do it using PHP to edit an RSS file? And what features would you include if you were starting from scratch?
posted by calico to computers & internet (25 comments total)

Install MT. You really don't have that much free time, now do you?
posted by machaus at 1:39 PM on December 9, 2003

PHP based blog, that has an SQL database, but spits out flat files, to reduce the number of connections to the SQL db. The flat files are destroyed and recreated from db when an update is made. The script can also generate RSS feeds via the db. Daily links, photoblog, comments (authenticated), and more.
posted by riffola at 1:40 PM on December 9, 2003

Install blosxom and be done with it. I got about 1/3 through writing a vaguely similar CMS only to find that blosxom is better.
posted by majick at 1:50 PM on December 9, 2003

Yeah, that's kind of why I was wondering whether there was any point. I'm now almost prepared to swallow my pride and install MT/bloxsom/whatever, but keep thinking there must be some feature, something that the blog tools don't have. That would be my reason for writing it, and then I'd have the sense of achievement & warm fuzzy feelings. But then, the clock is ticking on, the nights are drawing in, and I haven't alphabeticised my kitchen cupboards yet.
posted by calico at 2:01 PM on December 9, 2003

Could you clarify what you're thinking about doing? I'm confused. It sounds like you want to hand code things, but you say you're tired of hand coding?

I assume you mean you've been using just html, and you want to move to an automated, database driven solution, but you want to be able to tweak the functionality of the application?

If you have time and aptitude I would say doing everything yourself is best.

I just finished (well, not finished finished, but it runs now) recoding my weblog from scratch. For me this was very rewarding. It does exactly what I want, and if it doesn't I have a stable and well understood baseline to build on. One of the nice things is that I now have a very full featured picture gallery and discussion forum. I don't think Blogger has those.

"but spits out flat files, to reduce the number of connections to the SQL db"

This is really overkill unless your getting thousands of hits a day isn't it? But good to think about in terms of scalability..
posted by y6y6y6 at 2:09 PM on December 9, 2003

If I could find the time to write a CMS/Blog/&etc. engine, I would want:

1. Ability to create an infinite amount of categories, and be able to order them in a heirarchy and by relation. i.e.- Semantic Web.
   


2. Ability to integrate FOAF restrictions of content. i.e. - if you are my friend, you can see it, if not, too bad. Automatically. Say by use of a PGP hash, or something similar.
   


3. Rework Friendster type 6-degrees environment to help integrate the FOAF environment. But implementing 6-degrees so that you can classify the friendships by groups, relations, scales of friends, etc. I don't really care who my friend's friend is, I want finer grain control, dammit!
   


4. Ability to easily integrate to a home networked server and the InteWeb.
   

That is really just off the top of my head. Really, Anil's article, A Personal Panopticon is the impetus for many of my wants of publiching software.
posted by plemeljr at 2:19 PM on December 9, 2003

Oh, I have no concerns at all about how I need to get round the problems brought on by thousands of hits a day. Sadly.

Y6 - you're right, haven't been very clear. The current set-up includes some HTML & some CSS. Not really coding, more mark-up, and mark-up that I need to change every time I update. Now I'm proud that I taught myself to do this in the first place, but it's getting cumbersome & gets in the way of the spontaneous update. Plus I want to allow some others to post as well, but don't want to have to explain the whole 'this is where I use h2 tags' thing. So yes, I've just been using html, want to move to something more automated.

Also - I work in 'soft' IT. As an insight into how the other half live, I'd like to have a go at coding: it'd be an achievement, if a useless one. Your picture gallery and forum were exactly the sort of things I mean about what could be added that aren't in the current tools. I suppose I need to have a good hard think about what I need, but I'm finding it difficult to think about what I need when there are already so many solutions out there. Much like if someone asked me to design a new word processor - I'd find it very difficult to stop thinking about solutions rather than problems, if you see what I mean.
posted by calico at 2:27 PM on December 9, 2003

I used a self-written blog CMS for three years and finally decided keeping up with new things I wanted to add was too cumbersome for my shrinking free time and motivation. Movable Type is what I use now, and I'm very happy with it.

On the other hand, if you have the time and inclination to spend lots of time tweaking your system, it is a rewarding project. But I found that for myself, I was far too perfectionist about everything working in the perfect abstract way I envisioned it, and when that didn't work out easily it became frustrating. A less flawed individual may not experience this problem.

In other words, it's up to your preference: Which do you enjoy more, coding web applications or posting to your blog?
posted by daveadams at 2:28 PM on December 9, 2003

I second Blosxom. If you can code Perl, you might be able to write your own plugins to do whatever you need that it doesn't do (which would give you the warm fuzzies you seek).

Blosxom has a great user community, too. I've seen Rael whip up a plugin to answer one person's feature request.
posted by timeistight at 2:33 PM on December 9, 2003

"but spits out flat files, to reduce the number of connections to the SQL db"

This is really overkill unless your getting thousands of hits a day isn't it? But good to think about in terms of scalability..

I'd recommend implementing some form of funky caching: on each request, check if the appropriate flat file is available. If it is: show it. If it isn't: perform the necessary SQL queries and generate it. After adding to or updating your data, simply delete the relevant flat files so that they may be generated anew on the next request.
posted by milov at 2:54 PM on December 9, 2003

"As an insight into how the other half live, I'd like to have a go at coding"

A web log with comments is actually a very good introduction exercise for learning web programming. For the core you only need two tables, two forms for grabbing the content to put in those tables, and a page that dumps out said content.
posted by y6y6y6 at 3:06 PM on December 9, 2003

"I'd recommend implementing some form of funky caching"

I hate to be an ass, but why?

In a homebrewed application like this you have to assume it will be hosted on some shared server that a not very admin savvy user will be getting to via FTP.

How will this user get their app to write files?

PHP won't do it out of the box since the user the web server is running as won't have write permissions. Does the user know how to change ownership on the folders? Do they even know what that means? Will they be confused when their FTP client will no longer write to that directory?

Static caching is a good idea. Unless you're someone thinking about taking baby steps into web programming. In which case it's an invitation to frustration.

Please let me know if I'm missing something here.
posted by y6y6y6 at 3:44 PM on December 9, 2003

Time for bed, so thanks to all for thoughts and time. Baby steps is right - but I guess I can start small and add as I go on.
y6 - I'd already thought a little about structure and what-have-you and read my big book on PHP, and thought that it might be something very similar to what you describe. Thanks - you've been very encouraging.

Thanks to all for the blosxom tip as well: it looks very tempting. I'm going to have a go at this, but reserve the right to go crawling back to the blosxom downloads page in a few weeks time when I find that fixing the detail isn't quite as much fun as having the idea in the first place.
posted by calico at 5:27 PM on December 9, 2003

My advice (after having developed weblogging tools in a variety of languages, mostly for the sake of learning):

Design it first. Figure out what you want it to do before you start coding. List the features. Creating mock-ups. Know the application before you write the first line of code.

It's easier once you understand what you're trying to do, because you can modularize it, and get one thing working at a time, instead of building a heap of code and then piling more code on it as it evolves.
posted by oissubke at 6:13 PM on December 9, 2003

Because I'm a contrary type, I'm using Nucleus CMS. I especially like its "plug-ins" system for serious customization (even though I've only barely learned enough PHP to do add snippets of content to the page) and a fairly nice community adding public plug-ins to the work of the app's original author. I've had problems with the timestamps on my old webhost and the comments function did some strange and ugly things to basic html tags, but at this moment I'm installing a new version on my free 1and1 account, so those problems may become moot - or I may get a whole bunch of new ones. Stay tuned.
posted by wendell at 6:55 PM on December 9, 2003

d00d... just code that bad boy yourself. It'll be a learning experience... and really, it's not that hard at all with mysql/php, and you can be up and running with it in no time. The best place to start is that "Learn PHP in 24 hours" book. Tons of good, applicable lessons packaged as 24 manageable lessons.

My opinion... screw caching. (Of course, our entire server crashed today due to load, so maybe I'm not an expert on the subject.) Mysql has some degree of caching built in anyway... and if you want to be super sophisticated about it, just get in the habit of using ADODB as an abstraction layer - it has nice, built-in db caching.
posted by ph00dz at 7:47 PM on December 9, 2003

Most PHP installations will have write access somewhere, like the default file upload location.

If you like the Apache Cocoon style, which is based around XML/XSLT, then PHP Ambivalence might suit.
posted by holloway at 9:14 PM on December 9, 2003

I agree that writing your own CMS is a good learning experience. Fortunately, if it gets to be a hassle to maintain (my experience), you'll find that MT can import your existing entries with just a bit of work. And if there's something Movable Type or Blosxom don't do, you can probably write or download a plugin that'll do it.
posted by teg at 11:41 PM on December 9, 2003

"I'd recommend implementing some form of funky caching"

I hate to be an ass, but why?

I should say that after optimizing my own clunky three-year old blog-script and database recently, I found that things got so fast that I could do away with caching altogether. So I agree it's probably not even necessary in this case.

I guess my point was really this: if you're going to use caching, it's a lot more practical to implement it on the view/request-side of things rather than the edit-side. Say you have a whole bunch of different templates that show the same data; you don't want to generate all possible archive pages for all possible templates on each little edit.
posted by milov at 2:29 AM on December 10, 2003

What I did (before I worked for the company that makes it) was choose Movable Type and then do the custom things I wanted to do in PHP by reading directly from the database. The best of both worlds, because I take advantage of the core functionality that's already been made and don't have to reinvent plugins other people have already written, yet I'm still able to work on coding the stuff I want to tweak.
posted by anildash at 3:07 AM on December 10, 2003

"Most PHP installations will have write access somewhere, like the default file upload location."

This is slightly incorrect.

Since this is a major point of confusion for people learning PHP - The default file upload location is writable by PHP, but PHP will automatically delete files uploaded here when the script terminates, so you must move the file if you want to keep it. Hence, you need to make a directory writable by hand so that you can move it to that directory.

It's been my experience that PHP installations on Windows (very rare) are the only exception.

The best way to get this done it to log in as root, find out who the webserver is running as, and chown a directory to that user. If you don't have root or shell access you can do the same thing with a PHP script thusly - using your FTP client, change a directory's permission to 777 (fully open). Then write a script that will make a directory inside the 777 directory and change it's permissions (with the script) to 755. This directory is now owned and thus writable by the webserver. Now change the 777 directory back to the original permission.

The tricky thing here is that the user you're logging in as for FTP will no longer have access to this directory.

If someone has a better way to do this on a shared commercial host I'd love to hear it.
posted by y6y6y6 at 5:47 AM on December 10, 2003

y6, my host, pair, lets you wrap CGI scripts to run as your user account, so that you don't have to set global write access. There are other potential security concerns with such a system (eg, now your PHP has access to ALL your files on the host, not just a particular directory), but I've found it a good balance.

For PHP, though, you probably have to compile your own PHP (and keep it up to date as new versions come out) instead of relying on the web host, because most shared PHP installations are done as Apache modules, which can't be wrapped using this method.

However, for Movable Type, since it's all CGI, I was able to use this method to give the MT scripts write access to my content directories without having to make it globally writeable. (Of course, if my MT gets hacked...)
posted by daveadams at 7:01 AM on December 10, 2003

If someone has a better way to do this on a shared commercial host I'd love to hear it.

y6y6y6, I was having trouble using a Blosxom plugin that required write access to my files. What finally worked was getting my host set up suEXEC so that Aapache runs as me instead of itself. I'm not sure whether that's the same thing as daveadams mentions. Seems to work fine.
posted by timeistight at 10:48 AM on December 10, 2003

Pick a blogging tool or CMS and install it. Play around with it. It almost doesn't matter which one you choose. I use MT myself, and have started experimenting with Drupal for a different project. I've successfully imported Blogger blogs to MT, and believe I could probably export from MT to other systems if needed.

Using a pre-existing tool will give you a better idea of what's possible and what's available. If there's a whizzy feature you'd like that's not already there, try coding that as a plugin (MT already has a huge array of plugins
posted by adamrice at 10:50 AM on December 10, 2003

Since this is a major point of confusion for people learning PHP - The default file upload location is writable by PHP, but PHP will automatically delete files uploaded here when the script terminates, so you must move the file if you want to keep it. Hence, you need to make a directory writable by hand so that you can move it to that directory.

PHP only cleans up after itself for file uploads, not if you've written a file there yourself. And in this conversation we're using it for caching, so although the directory might be cleaned it's not like we can't recreate the files. But yeah, if you're looking for permanent storage it shouldn't be used.
posted by holloway at 12:43 PM on December 10, 2003