blogZero

After my incredibly frustrating experience installing and configuring Textpattern, I decided to give WordPress a shot. Talk about night and day. You would either have to have years of experience working with Textpattern, or be a complete masochist, to even consider going with that package.

Neither of which includes me. After downloading the archive, creating a directory for it, unpacking the software, creating a MySQL database complete with credentials, running the installer, a little fiddling with rewrite rules—I had WordPress up and running with friendly URLs in 10 minutes. Okay, maybe not the famous 5-minute install, but I'm cautious and don't like to make mistakes that come back to haunt me later.

Themes

The default theme is okay, or you can go with the "classic" interface via the base install. Both one of which are a big improvement over Textpattern's default (boy, TP sure is the whipping boy around here lately). Anyway, I shopped around for a nice theme and quickly settled on iNove which is slick out of the box, and I discovered later really easy to tweak. Right off the bat I was impressed with this guy's skills. Little things like using Sprites for icons and other imagery, make a big difference.

Plugins

Plugins are a joy to work with. They're easy to install, and if you go with crowd favorites you're bound to find one that is well-documented, smartly coded and doesn't interfere with WordPress itself or other plugins. Thus far I've installed:

• Ajax Calendar — replaces WP calendar with one that doesn't page refresh
• Akismet — blocks trackback and comment spam
• Dagon Sitemap Generator — fully customizable sitemaps
• Google XML Sitemaps — for Google indexing, not users as above
• Highslide — zoom image thumbnails with many options
• Markdown — lightweight markup language for easier authoring of posts
• Page Links To — easily create links that are external to WP or offsite
• PageNavi — advanced paging navigation
• RecentComments — display recent comments in your sidebar
• Related Posts — create related posts links via tags
• SRG Clean Archives — search engine friendly archive listings
• WP-Syntax — source code syntax highlighting via GeSHi

Administration

Like any admin interface, it takes some getting used to. But I found the learning curve fairly shallow and was soon up to speed. Configuring your sidebar is really nice. You select items on the left side to place on the right, and using Ajax you can order them however you want by drag and drop. One thing that had me puzzled at first was the four sidebar sections: north, south, east and west. At first I pictured the entire page, but then realized your sidebar is dived into top, middle and bottom, with the middle having a left (west) and a right (east). Makes perfect sense now.

Configuring the menu bar was also a little strange. These are referred to as "pages" rather than "posts." You can put anything you want into them or use a plugin such as the sitemap generator mentioned above. The interface for adding content to these pages is almost the same as regular posts, but you can disable things like commenting and such so they appear as, well, normal content. Or you can "perma" link any of them to some other page, as I did in the case of my Contact option.

I fiddled with the theme stylesheet quite a bit to get things the way I wanted. It's easy to do right from the admin interface by selecting the Design tab then the Theme Editor. I also added a Blogroll OPML link next to my RSS feed at the top of the sidebar. But that involved a little PHP coding, adding a third icon to the feeds Sprite and again, modifying the CSS. I also fiddled with some other icon sprites, but I won't go into that here.

Conclusion

There are still a few little things that perturb me, for instance, when WordPress magically reformats my raw content when I select "Edit post" from the public side. My advice is to use the admin interface for fixing typos and such. I would also prefer a post preview that doesn't involve opening a new window (or tab if you have your browser configured that way). I can understand the rationale behind it, and I'm sure I could come up with a better solution. That really is the power of open-source software, if you have the skills you can make it do anything you want. Plus, using a scripting language like PHP makes it all that much easier. Especially when the code is well written and documented. Serendipity is a nightmare, at least this old version I'm still using.

But not for long! I will announce when I plan on moving over to the new blog permanently.

I had such high hopes for Textpattern, I really did. I was sold on the slick looking admin interface, the tons of templates to choose from (or themes or whatever they call them). The nice, clean layout of the Web site. The tons of resources—an almost complete MediaWiki documentation site—plenty of users. Bloody wankers! I was duped!

Cut and Paste?

Oh, at first everything seemed honky-dory. A straightforward install, if a little strange (that's when it started to dawn on me). First, you create a MySQL database, assign a user CREATE, READ, WRITE, etc., privileges. Okay, I've got no problem with that. Next, run the installer. It checks to make sure it can connect to the database, okay, then it spits out this code into a <textarea> and tells you to cut-and-paste the code into a file called config.php. Cut-and-paste? Why not just create the damn file and write the settings to it? That's when the hair on my neck started to crawl. Oh, there would be more, much, much more cutting and pasting to come.

First Post

Okay, I get the sucker up and running. I fiddle with the settings to name my blog and so forth. I fix a few permissions problems on directories, no big deal. I create a quick dummy post, I click "View site" and what does it do? Tries to open another browser window. Ack! But of course I have my browser configured do redirect such nonsense to a new tab. Oh, there will be many more tabs in my future.

The first problem I run into are "friendly URLs." Which I prefer, so do users, so to search engines. Only I'm getting 404 errors. Oh god, here we go, I know what's next. Sure enough, there's an .htaccess file sitting in the root of the install. I cannot stand application packages that blindly assume you have mod_rewrite installed and .htaccess enabled. Which I do, and I don't. The latter for a very good reason that I won't go into here. At any rate, I know what to do, I create a <Directory> container for the package and set the rewrite rules in my Apache config file, then restart the daemon. Viola, friendly URLs! I promptly delete the .htaccess file regardless of "Diagnostics" telling me it's missing.

So off I go to my "View site" tab. The presentation is basic, really basic. But I'm not worried about it, I can choose from one of the hundreds of themes out there or learn how to design one myself, right? I decide to go with the former. I find one, I download the archive. The documentation Wiki tells me to follow the instructions in the archive. Why this isn't standardized is a complete mystery to me.

Zip Files?

Who uses zip files? Folks, I knew Phil Katz. He died a lonely, pathetic alcoholic in a grubby motel room at the ripe old age of 37. Okay, okay, XPInstall files (.xpi) are zipped, JAR files, almost all Unix-like OSs have open-source zip and unzip... Actually, at the time, PKZIP was a pretty revolutionary piece of software, even if Katz stole most of his original code from SEA. At any rate, this was before you could even lay hands on a 56k modem so...

Anyway, I open this archive with my trusty GUI interface for such things and after looking through the contents I find what must be the install instructions since the file is called Instructions.rtf. RTF? How about INSTALL.txt, or how about RTFM? Anyway, I'm reading the "instructions" and they tell me to cut-and-paste the contents of such-and-such a file into such-and-such "folder" (pages, styles, forms). What folders pages, styles, forms? Oh, dear lord, I think, it's time to study the database. Sure enough, CSS, forms and pages are all stored in the database instead of the filesystem. Worse, there seems to be no admin interface to deal with these things. So I open another tab to Google and start searching...and find a plugin called mcw_templates which adds the ability to import and export pages, forms, and stylesheets to/from the database. Why this isn't built-in to the functionality of Textpattern to begin with is a compete mystery to me.

It turns out the "mcw" in the plugin name is the author's initials, so I visit his Web site and promptly discover that he no longer maintains the plugin and it is now on GitHub. The former is a little unnerving, but the latter give me hope. But before I go traipsing off to GitHub I take the time to read over the instructions on installing and using it. Not encouraging: "This plugin is beta in every sense of the word, as it’s only been tested on my 4.03 installation. It might work on other versions, but no promises!" I have the latest Textpattern, v4.0.6, but hey, I'm a masochist so this doesn't stop me. He also states "Regardless of where it’s been tested, this plugin messes around with your database. Do not use it without backing up your database." Oh god, what have I gotten myself into? So I promptly back-up the DB, create the _templates directory and make it world writable, then continue on to GitHub.

Uuencoded plugins?

When I get to the repository I find Mike's blurb on installing the plugin. I read it. It says to "cut-and-paste the following data into the 'Install plugin' box" under admin->plugins. The data looks suspiciously like it's uuencoded to me (actually, it turns out to be base64 encoded which is rife in this package). According to the Wiki, this technique is justified because it "reduces the possibility of errors during transport," or some such nonsense. What transport? You mean between my clipboard and the plugins form? If anything, neophyte user error would be the biggest problem. Okay, so I paste in the data and click the submit button, which is labelled "Upload." What upload? Oh god, my head is starting to pound. At any rate, the data is decoded then you can actually view the source before clicking "Install" to add the plugin. And don't forget, you then have to enable the damn thing by going back to your admin interface, clicking on the Plugins tab, finding it in the list (if you have more than one) and clicking "No" from the Active column. All very intuitive, not!

Speaking of error-prone, does anyone remember the days when PCMag would publish those little debug .COM utilities? I sure do. In order to build them you had to painstakingly type in the data, byte by byte by byte, and then feed it to debug which would spit out the program (written in DOS assembler). Oh god, I haven't thought about that in years. You can even get the damn book from an Amazon reseller for less than a dime (plus $4 shipping of course) if you want. Sigh, I digress.

Okay, so the plugin is now installed. Now what? It turns out the semantics have magically changed and now the plugin (once active) is under the Extensions tab (much fist pounding...) and there it is, has its own tab and everything: "Template Files." Great, now I can back-up the default template and (cough) install the new one. The former works pretty well, I name it "default" (go figure) and head back to my shell to see the results. Sure enough, under the _templates directory is "default" with pages, forms and css folders. Great, I take a look at these to comprehend what's next. It helps some, but this is when things get really ugly. I back up to the _templates directory and create a new folder for the theme that still sits waiting with baited breath over in my archive application. I continue to read the instructions, which go something like "cut-and-paste the contents of this-and-that file into the other file..." Which, like an idiot, I do: 3 stylesheets, 9 forms and 5 pages.

Then, I am told to create a folder for the images used by this theme in the images directory. Which images directory? At the root? Or the txp_img directory in the textpattern folder? I'm hoping that images is the correct place so I upload away. But the instructions aren't complete yet. I have to create two new sections (search and archives). Done. Next, the theme requires two additional plugins. Being an old hat at this already I install away. After several hours, it appears, I'm ready to install the theme. Crossing my sore fingers after this tedious, error-prone process is complete, I go back to the admin interface to the Template Files extension tab. I check the dropdown and sure enough, there is the theme I labored so hard to create, and I import it. What does the plugin do first? Promptly backs up the old template theme once again and names it "preimport-data." Sigh, now I have two copies of the default theme. But what the hell, you can never have enough back-ups, right?

Deprecated tags

So now I head back to my "View blog" tab and refresh. All seems well, until I start getting errors and warning from the engine about "Textpattern Notice: tag is deprecated" and "Article tags cannot be used outside an article context." It turns out "tags," and the pseudo-namespace txp: are Textpattern's method of including dynamic content into your templates. Reminded me way too much of Smarty. The first example, it turned out, was simply a matter of changing the sitename tag to site_name. Only not so simple really, because you have to edit the goddamn source code then reimport the templates back into the database. The second example I never found a fix for because after searching for it all I found were a shitload of sites that Google had indexed with the same exact error message.

All Your Desktop are Belong to Us

When I have a half dozen tabs running in my browser, one for my blog, one for my blog admin, one to the main Textpattern site, one to the documentation Wiki, one to the templates site, one to a forum site, one for GitHub, another for searching Google...you get the idea, there is something terribly wrong. On top of that, a shell window, a text editor window, a GUI zip file archiver app...you need a 40" monitor just to install this damn thing.

Textpattern, I've got one word for you: disappointed.

app> rm -rf tp
app> mysql
mysql> drop database tp

Bye-bye Texpattern.

Okay, now we're getting somewhere! Still dissatisfied at my attempt to reduce the glut in the parent PHP category page, I took yet another look. Wouldn't you know it? There was a definite thread of resources in there relating to improving the performance of applications written in PHP. Not surprising given the growing complexity of the language itself, the applications written in it, and the myriad of Frameworks available these days. The latter is especially critical, because with abstraction, underlying complexity, and growing feature sets, before you even start a project your code base is large. Very large. I'm not going to name names, you know who you are.

Frameworks

I prefer the simple over the complex, the modular over the monolithic. Given the opportunity, I would go with something like CodeIgnitor, which allows you to use the pieces you want and eliminate the rest. The same is true for templating engines. I've used Smarty of course, but it puzzles me why the developers would reinvent the wheel, so to speak, by adding an entirely new dynamic language syntax for templates, when PHP already is a templating language (and a whole lot more). I'm a Savant man, call me an idiot.

Web Publishing

Now we're getting into that gray area I've mentioned before. Is Drupal a framework, a CMS or an application? In my mind, some of each. Wikis and blogware packages I consider applications. It certainly helps to be a developer to get the most out of them, but it isn't strictly necessary.

User or Developer?

And this is also the point where I change my stance on complexity and features. There are certainly faster and easier to use Wiki packages than MediaWiki, but do they have all the power? As always there is a trade-off. I get frustrated with Firefox for instance, because it has become rather bloated and I have bloated it even more with lots of extensions. But as a developer, and a bit of a designer, I could not live without FireBug, Web Developer, ColorZilla, and countless other tools. Christ, I'm not even sure how the hell I managed back in the bad old days of using telnet to test HTTP requests.

Simple vs. Complex

My own philosophy on programming goes like this, start with primitives and build complexity as you move up towards the more abstract and powerful—without going too far. We can see this in the OSI layer model, and an even better example, the early days of Unix. When Dennis Ritchie got tired of working on the kernel in PDP assembler, he took the time to build the more abstract language C. Funny how all the scripting languages, tools, hell, pretty much everything, is written in C, but now days how many of us code in C anymore? Even many of the extensions written for languages like Perl, Python, and of course PHP, are written in C. And there is a damn good reason for this: Performance.

Extensibility

This concept, to me, is absolutely key to good software. Use a high-performance compiled language to build the tools and you're left with solutions that are both easy to apply and responsive. The best of both worlds.

Results

Okay, and now for the final tally. After fragmenting the PHP category into "general" (now around 50 resources) there are six sub-categories (for a total of around 50 also). Divide and conquer my friends.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

Last week, while researching and evaluating open-source software packages written in PHP, I naturally took the time to install some of them to see how difficult it was and note any problems I might encounter. One of these was of particular interest. MediaWiki is the software that drives Wikipedia and the rest of the projects under the Wikimedia Foundation umbrella.

Goals

Some of the goals I had in mind when I set out on this little project were:

• Follow best practices.
• Virtualize the install so PHP scripts and other resources visitors should not have access to are hidden.
• Friendly URLs—I don't want to see any .php extensions while browsing.
• Customize the install for my particular needs.

Root

For security reasons, and the threat of downtime from customers who don't know what they're doing, most hosting companies severely limit what you're capable of doing in a shared environment—and of all things they're not going to give you root access or sudo(8) privileges. Even on a dedicated server this can be a sticky situation. In order to follow the instructions below, at some point you're going to need that capability to, for example, restart you're Web server daemon. If you're running Ubuntu or another Linux distribution, or Mac OS X, on a local development box, you should be all set. You should also be comfortable using a shell and know how to edit text files.

Download

First you need to grab the source code from the MediaWiki Web site. You'll find it on the Downloading MediaWiki page. It comes in a tarball—make sure you get the latest stable version. Also make sure you meet all the requirements before attempting the install. It helps to know which versions of PHP and MySQL you're running beforehand.

Upload and unpack

After you download the file, upload it to your Web server into the docroot of your site. At the time I did this the MediaWiki latest stable version was 1.13.2 (released 10-2-2008), and the name of the compressed archive reflects this: mediawiki-1.13.2.tar.gz.

Fire-up your shell client and visit docroot. You can decompress and extract the source in one command:

$ tar xzvf mediawiki-1.13.2.tar.gz

You'll see a whole flurry of activity as the package is creating its source tree and populating the directories with files. You'll be left with a directory, just off docroot, with the same basename as the archive. The first thing I did was rename it to something more manageable:

$ mv mediawiki-1.13.2 w

There's no need for the archive any longer so get rid of it.

$ rm mediawiki-1.13.2.tar.gz

Then change into the w directory.

$ cd w

Configuration

The browser-based installer will want to write out a file called LocalSettings.php in the config directory. To forestall any permission problems make that directory world writable:

$ chmod a+w config

Now point your browser at the directory off docroot you just created: example.com/w/ and follow the instructions to set some basic options and create the database. In a bit you won't access the w folder directly, since we are going to virtualize it and create friendly URLs. Two things to keep in mind: the virtual directory does not really exist in the sense you create it in your filesystem, and (this is important), do not use the same name for both. By MediaWiki convention this virtual directory is called "wiki," which you should be familiar with from browsing around Wikipedia.

When the installation is complete, copy the config file down to the w directory and add a few lines.

$ cp config/LocalSettings.php .

// docroot/w/LocalSettings.php

$wgScriptPath  = '/w';        // real path
$wgArticlePath = '/wiki/$1';  // virtual path
$wgUsePathInfo = true;

These settings, and one more task with your Apache config file, will take care of ever having to access the w path directly, and will give you the nice URLs we're after.

Apache

You're going to need to be root on the box to do at least one of the following steps. Since I have a virtual.conf file for this site there was no need to edit httpd.conf directly. Your mileage may vary. Either way, in the <VirtualHost> container for your site you need to add an Alias to finish this job:

Alias /wiki /real/path/on/your/server/docroot/w/index.php

It's probably a good idea to make sure your config file(s) have no errors, then restart Apache:

$ apachectl configtest
Syntax OK
$ sudo apachectl graceful
Apache gracefully restarted

Then point your browser at: example.com/wiki/ and if everything went well you'll see the MediaWiki "Installed successfully" message on the Main_Page. An even cleaner set-up would be to create a sub-domain of your site, say: wiki.example.com, and install everything in the docroot. But I'm not going to get into that here.

mod_rewrite

There are a number of other solutions out there, many of them involving mod_rewrite. Unless you understand regular expressions and have some experience using mod_rewrite, or enjoy pain of the voodoo variety, I recommend going the Alias route. Why hit a tack with a sledgehammer?

Conclusion

MediaWiki is a large program and it uses lots of system resources. If you're in the market for a simple Wiki and one only you will be using then consider shopping around for something less complicated. I went for Big Daddy for a couple of reasons. One, I wanted to gain the experience of installing it, and two, I wanted to have my own sandbox, so to speak, to better understand the system, and in particular, to improve my skills editing Wiki documents using their markup language. With that said, it was worth the effort.

Although there is little to see or do, you can visit wikiZero to see the results of a fairly fresh install. Also, if you're really planning on diving into this, and you're a dead-tree fan like me, O'Reilly published MediaWiki just last month. I took a look at it and read some third-party reviews. It's a keeper if you plan on using this software to any great extent.

This is the fifth and final installment of the Specificity series. In it I'll be taking a look at open-source blogging systems written in PHP. The last post on debugging PHP was a bit of a departure, this one lands squarely back in the realm of targeted CMS applications.

What do I mean by targeted? Well, there are general-purpose CMS packages, and there are ones that are designed for a more specific role. But this gets confusing, because many cross over into other territory. Take for example Trac. Is it a software documentation Wiki, a front end to Subversion, or an issue tracking package? Well, all three.

Blogware

But we should get back on track. The number of features in a sophisticated blogging platform is remarkable. The guys who build these packages are very talented (for the most part) and work their butts off. And users new to blogging may find that the jargon alone is overwhelming. But the cool thing about these packages is you can start with a simple one, and work your way up as you get comfortable. Lots of them have import/export features that allow you to move data from one to the other.

If you're in the market for any of this software, take the time to do your homework. And remember you can always try before you install, or go with a hosted solution so there's nothing to do except tweak your blog until you're satisfied. And if you're not, try something else!

Conclusion

There is no conclusion. I succeeded in nothing I set out to do. Instead of making any headway towards trimming the number of reviews in the PHP category, I more or less only moved a handful and added a bunch of additional ones to the newly created sub-categories. I will probably take a closer look and do some more segmenting. At the very least I learned a lot about the topics covered in this series.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

Yes, I'm aware that a spider isn't technically a bug, but the cool thing about spiders is they eat bugs. This mechanical spider by Belgian sculptor Stephane Halleux looks especially menacing.

But we're not here to talk about spiders, we're here to talk about software bugs, and more specifically, debugging PHP code. In this fourth installment of the PHP Specificity series I'm going to break from the theme of content management packages momentarily and get into a topic that is not so dear to the programmer's heart. Debugging is a necessary evil and can be painful at times. But the reward, when it happens, is that eureka moment when you find the bug and squash it.

Options

I'm not sure what ever happened to DBG. The author seems to have abandoned the project, or at least stopped updating his Web site several years back. I know the product was rolled into the commercial NuSphere PhpED PHP IDE—whether they took over the code base I'm not really sure. Another option is, or rather was, the PECL package APD by George Schlossnagle (of APC fame). But again, it seems to be dead in the water (the last update was in 2004).

Xdebug

Fortunately we have Xdebug, by Derick Rethans. It has all the features you'd expect from an advanced debugger, and a built-in profiler to help you tackle performance issues. With output in Cachegrind format, once you're done running the profiler on your code, you can fire up your favorite viewer to analyze the results.

If you are an IDE fan, you might want to try the Eclipse PDT, which supports both Xdebug and the Zend Debugger. Or, if you're old-school like me and a Vim user, you can configure the editor to use Xdebug with the DBGp plugin.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

The third PHP sub-category I selected was Content Management Systems, abbreviated CMS. There is a bit of a gray area between software that is considered a CMS, a Wiki or Blogware. The whole genre is often referred to as Web publishing software, which makes sense. The one thing they all have in common is the ability to quickly and easily add content to a Web site without needing to understand every gory detail of a markup language like HTML. It certainly helps, but it isn't a requirement.

CMSs are generally more sophisticated than Wiki or Blogware packages. They typically target the newspaper industry or some other publishing organization with multiple employees that serve various roles. For instance writers, copy editors and on up the ladder.

Content

In all cases, the user normally adds content through a Web browser form in what is known affectionately as a sandbox. I'm actually doing so right now as I create this blog post. Most offer a lightweight markup language making it easy to create links, headings, text formatting, and so on. Other features include content metadata and automatic indexing of content making the entire site searchable by its readers. High-end, commercial CMS packages also allow the same content to go to print as well as the organization's Web site.

With that said, I'm only going to list open-source packages—the best-known of which is probably Drupal.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

The second sub-category I decided on to sub-divide my many PHP resources was Wikis. I love wikis, they're easy to use, they're a great tool for documenting just about anything, and most of all, they're organic. Organic, as in always changing and growing, not as in food—although I do eat lots of organic food. Hey, it's a lot better than eating your own dog food.

The WikiWikiWeb

It's been over 10 since Ward Cunningham came up with the wiki concept, and if you ask me, the guy was a genius. Ward, with co-author Bo Leuf, built the very first Web-based wiki called WikiWikiWeb—go figure!

Wikipedia

Despite the controversy, and probably because of it, Wikipedia consistently ranks in the top 10 most visited Web properties. I use it constantly, almost as much as Google. Hell, when you're searching for something one of the first links usually is to Wikipedia (note the dog food link above). Although rarely, I'm even a contributor myself.

MediaWiki

After submitting this post I took the time to install MediaWiki on my own server. To share the love, I wrote up an article on my experiences doing so, and added some tips on how to create Friendly URLs.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

I'm not a big fan of either really long pages, or the paging of results. Who goes past the first SERP on Google? I do fairly often when drilling down, plus you can find some real gems if you don't give up so easily. But there is a damn good reason why Web site owners want to land on the first page given a certain set of keywords—because most people don't even bother looking past the first five links.

In my case, the PHP category of my Web Developer Resource Index was getting ginourmous . I mean out of control, practically unusable. Not to mention the download time. Which is a real shame, considering it is one of the most popular pages on my site. Something had to be done I tell you!

But rather than spending the time and effort to implement paging, I took another approach. And that was to get down to specifics. This was really a taxonomy problem, and the key was to break the page up into a top-level (general) category, and then divide the rest into sub-categories.

The first of these was, as you might have guessed, PHP Frameworks. Now I'm not listing every PHP framework on the planet, there are some pretty good ones and there are some really bad ones. In addition, the page has links to articles and other resources. And I can add more without thinking "oh crap, yet another PHP resource to add to a page that already has close to 100 of them!"

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

What's this, no multi-page post today—complete with code examples and links all over the place? Instead, I did some house cleaning, and added a new wing. JavaScript has been such a hot topic around here of late, and in the Web development community in general, that I took a look at my growing list of resources and discovered that indeed, the JavaScript category was in need of some pruning. Amongst the list, and in particular by studying the most popular tags, I found that JavaScript libraries would make an excellent category to splinter off and reduce the weight in the parent folder. I know, I know, I need to implement paging. PHP is another one that grew out of its clothes.

Speaking of implementing paging (and caching and a lot of other things on my todo list), I have been really busy behind the scenes fixing bugs and making other improvements to both this blog and loadaverageZero in general. Some of them my visitors may have noticed, some may not. But things are definitely on the upswing around here since health has improved.

One thing that really has me puzzled is what to do with this blog. I'm running a rather old, and hacked to pieces, version of Serendipity. I don't want to let go of the design, which I spent a lot of time on, yet on the same token it bothers me that my only recourse to block spammers and other miscreants was to disable comments and trackbacks. I'm not a big fan of Captchas, I would prefer to go the OpenID route.

Anyway, I'm starved and I haven't been to the diner for some good old eggs and bacon in ages...