This post originated from an RSS feed registered with Web Buzz by Douglas Clifton. Original Post: Texpattern: D'oh! Feed Title: blogZero Feed URL: http://loadaveragezero.com/app/s9y/index.php?/feeds/index.rss1 Feed Description: Web Development News, Culture and Opinion Latest Web Buzz Posts Latest Web Buzz Posts by Douglas Clifton Latest Posts From blogZero

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.