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

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

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