Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

I first posted to this blog on December 13, 1999. I had a Web site for years before that, but that was the date of my first recorded post to Irreality.

I don’t know how many blogs have been going for a decade, but when I realized that this one had, I thought it was worth mentioning. Plus, I haven’t posted in a while — even though I have quite a few ideas waiting in the wings.

When I started out Irreality, it was probably more of what you might call a “life stream” now. It has evolved into a much less personal and more technical outlet for me today. I think this change is natural given what has happened in my own life and, also, in the life of the Internet.

On the technical side, I began with a subscription to UserLand Manila and hosted it on my own server. I had been a user of UserLand’s Web scripting and development environment for several years already in 1999. I recall the jump to Manila being both exciting and familiar. It was fantastic to click “Edit this page,” and be able to do just that. I wouldn’t be surprised if most of the decade-plus blogs also started on Manila. (A few I can think of from that era are Backup Brain and Have Browser, Will Travel.)

I’m pretty sure the original server was either a Power Mac 7200 or 7500, running on my cable modem connection, with a hostname from DynDNS.org. Many years of collecting cast-off equipment were required to keep that system up and running at reasonable performance levels.

Somewhere along the way, I purchased a domain. What a leap that felt like at the time!

I finally gave up on Manila when it gave out on me earlier this decade. That allowed me to stop running the blog on my own hardware, on my own Internet connection, with my own power and so on. Unfortunately, I still haven’t converted all of my archives over to Drupal, the content management system I use today on a shared hosting environment. Sometimes, I wonder if that is for the better, but I still do aim to process that MT Import data.

I’d like to thank my wife for delivering a “happy blogiversary” cake with the requisite good humor.

I’m not even sure what the utility of trackbacks are, but I have the feature enabled on my Drupal site. Unfortunately, I discovered that this made the site susceptible to junk trackbacks.

Given that I only vaguely understand what they’re for, I should probably just disable the feature altogether. When the concept first came up, I was running Userland Manila and trackbacks didn’t make sense to me then — let alone now.

The response I’ve taken tonight is to enable a spam filter for Drupal that will scan trackbacks. I’ve also taken the liberty of deleting all of the existing junk — most of the identifiable source addresses came from Russia — to prevent these many tiny messages from clogging up my database. One set of queries, I kid you not, deleted over 3,000 database entries in one fell swoop.

This is an unfortunate state of affairs. Trackbacks are apparently just one more piece of social software that can get spammed. Sigh.

Continuing today’s Drupal love, I should mention that I recently figured out how to use the Inline module. Thanks to Inline, I’ve gotten much closer to the more-ideal state I felt I had with the built-in facilities of Userland Manila in 1999.

Namely, I adored Manila’s easy interlinking of pages. I could just quote the name of one page while in the body text of a second page, and the quoted title would become a link between them when published. I could also put images inline by quoting their titles in the body text of a page. It made the rapid creation of new, richly-linked sets of pages very fast and, while not effortless, much easier. I’ve used that to good effect, I think, in some past projects.

Drupal’s Inline module allows me to do much the same today. It uses double square brackets, which aren’t as convenient as quotes, but it gives me additional power I always wished Manila had. I can place the titles of pages on my site inside the double backets, to link between pages internally. I can also put the URLs of outside pages in those brackets, to link externally. I can also modify this by putting a pipe between the title or URL, and the link text that I want the reader to see on the page. This is very flexible, and that last ability really overcomes an obstacle I ran into with Manila — without the opportunity to change the link text, I ended up having some oddly-capitalized links within sentences.

I managed to reimplement the various redirects for my old Manila CMS’ URLs over the weekend. I did so by moving my site into a subverted in my Site5 hosting account, and then using some mod_rewrite trickery to direct my domain to that subdirectory. Meanwhile, I put the redirects in the same .htaccess that is used to point my domain to the subdirectory.

Somehow, this separation of the redirects from the Drupal .htaccess file did the trick. I guess it just works more closely to what I’d been doing within the VirtualHost directives on my old server, which I ran myself.

Interestingly, Site5 gave me 55 domain pointers that I can use to direct any domain I own to a subfolder within my document root. Any domain, that is, except the first one … the one I used when I set up the account. This just seems like a silly limitation.

Along the way towards this solution, I found the following to be handy:

• HTMLSource’s URL rewriting guide
• JavaScriptKit’s Comprehensive Guide to .htaccess redirects
• B&T’s tips and scripts article on domain and subdomain pointing, which eventually was the basis for my mod_rewrite solution.

This has certainly made a difference; the stats for my “temporarily unavailable” page are jumping again. Sigh.

I finally figured out how to get the VirtualHost directives in my Apache configuration to work the way I wanted. I had previously had vhosts defined, but one would always clobber on the other. I suspected something was also in conflict from the server’s default configuration—before the vhosts were defined.

I figured out how to follow the first example in the Apache VirtualHost documentation, and ultimately, that worked. It simply took the addition of a NameVirtualHost line.

I also changed the name of the server at the same time, just to make sure it wouldn’t conflict with the domain. (I didn’t know if that would cause further problems, but having a specific server name was what was outlined in the Apache examples and I’m in no mood to experiment further this morning.) It had previously just been the domain name, but now it’s got a host name (which it always had, I just didn’t have it in the Apache configuration since my last attempt to fix vhosting).

I had also tried changing the DocumentRoot for my vhosts to “/” rather than the absolute path to the site directories. This turned out to be a bad thing: visiting every path in Drupal failed. When I undid that, replacing “/” with the full path to the site folders, it magically started working again.

A big benefit of this is that I can have sub-sites, which can be individually configured and even protected (to only allow access within my network, perhaps). Now, I can use this to do some testing on upgrades and data imports (hello, my old data from Userland Manila!) and other stuff like that.

I installed and switched on mod_gzip for my Apache server two nights ago. I don’t really know if it makes a difference, but at least when I’m loading these pages on other computers, it does seem to be a bit zippier, shall we say.

Mod_gzip does require some configuration in your Apache http.conf, but examples are easy to come by. (I found this Apache and mod_gzip page to be clear and helpful.) I cannot really say I understand all of them but I’m still getting my sea legs with respect to Apache, so that’s to be expected. I’m hoping I got it right, and am not really sure if it’s working; any change I’ve experience could just be a placebo effect.

I made this change even though I’m not sure my server can handle running Drupal on Apache under any significant load to begin with. Hm. Adding gzip of every page sent out can’t really help performance on the server, but CPU is fairly cheap, even on a low end Power Mac G4. I was mostly hoping to make sure I’m making efficient use of my bandwidth.

So far, even with this change, I still feel like Apache plus Drupal is more responsive in many situations than Userland Manila 9.0 (and older version now) was on the same hardware. Perhaps it just takes advantage of the hardware resources better; it should certainly spread the load across the dual CPUs.