Rose garden

I can’t just ‘do’ technology. The longer I don’t feed that other half of me, the more somber I become.

The weather was too nice to stay inside pasting, cutting, and folding for my Art of Book projects, so it was a good time to visit the rose gardens; take some pictures, though I know it must seem like the only photographs I take are those of flower and weed, with an occasional aside into something that doesn’t have roots.

I hope to explore with my photography this summer, with different subjects including local bikers and river rats (human that is). Or not, and take a break from it. But for now, just plain flowers.

I also looked for something to go with the flowers, some writing. A poem or two, and if you search on poems with roses, you’ll find hundreds. But they all seemed so weepy, and sentimental. I don’t like sentimental poems, and I don’t need weepy.

So I guess I’ll stick with just flowers.

Technology Weblogging

Survival guild to LAMP: Taught by tweak

M is for MySQL and P is for PHP

I like to go the book store about once a week, to browse the shelves checking out what’s new and have a really nice cup of coffee at the cafe. (Well, and also make sure my books are stocked, but that goes without saying.)

A couple of days ago, while at the store and before heading over for my caramel mocha (my big treat for the week) I was looking through several books on PHP and MySQL, when I was struck by the fact that there’s a lot of good books on the shelves on these subjects. PHP and MySQL are big, and with new versions of both in the works, getting bigger all the time.

However, what puzzled me about the books is the type of examples used to teach the PHP language, or the mechanics of MySQL. For instance, several books featured a discussion group, and others demonstrated how to do a shopping cart, and so on through out the books–demonstrations of the language and the database by starting from scratch to build applications. Not particularly small applications, either.

Ten years ago, I would say that was the way to learn how to use a tool or a technology or a language, but no longer; particularly within the LAMP environment. No, if you’re going to learn about MySQL or PHP, especially if you want to learn about both, grab any one of the many freely available open source applications, install it, and then *learn by tweaking.

I chose WordPress, an open source PHP/MySQL weblogging tool, to tweak in this series for two reasons. The first is that I plan on using WordPress for my future weblogging needs, so the tweaks serve a purpose beyond the series; I also hope that the information might be helpful for those moving from Movable Type to WordPress. Secondly, from a purely tweak perspective, WordPress is just large enough to provide interesting possiblities, while remaining small enough to find your way about fairly easily.

Once WordPress is installed, if you’re a migrating MT user, you’re going to want to export your MT entries using the export utility within MT; creating a file of all your entries, categories, users, and comments. I’ve exported all of my weblogs without problem, and you shouldn’t have a problem either. However, if you have a large weblog and run into timeout problems, you might have to talk with your ISP about adjusting the timeout on the web server, at least long enough for you to grab your data.

(You can also view the WordPress documentation for importing MT entries, here.)

I exported my entries from the Practical RDF support weblog into a file called rdf.export, and then FTP’d it down to the the wp-admin directory of my WordPress 1.2 test installation. In this directory is a file called import-mt.php, which will take your file of exported entries, slap the data around until it agrees to cooperate, and then load it into the WordPress tables created during the installation. However, before loading this file in your browser, you need to make one edit to it–to add the relative location and file name of the exported MT entries.

You can download this file to your home computer and made the adjustments there, but the purpose of the LAMP Survival Guide is to introduce the adventurous among you into the joys of this environment; instead of using FTP to move the file about and the text editor in your Mac or Windows machine, you’re going to have a chance to make an edit directly in the Linux system of your server, using a text editor that’s almost guaranteed to be installed on most versions of Unix: vi.

However, for those wanting to skip the joys of vi, follow the instructions given in the WordPress documentation for importing Movable Type entries, but no hacker pin for you. See you at the end when we run the PHP file.

For the rest, on with the show.


Beat me, I’m vi

Of course, just saying vi is enough to drive many folk running, screaming from the room. However, this poor misunderstood text editor is actually a lot handier than its reputation implies. The key to the tool is to understand it’s philosophy: it’s the ultimate tweaker’s tool.

You use vi to open a file, make your tweaks, close it, and be done. It’s not meant to write reams of code or writing; it’s not meant to be a word processor; it’s not meant to be elegant. It is simple and functionality and without a lot of geegaws to get in the way. Of course, not everyone will agree with me. The wars between emacs and vi users are legend, and there are other tools with more functionality such as pico, mentioned by Dorothea Salo in the last essay. There are also more modern versions of vi with enhanced functionality, such as vim.

However, no matter what else is installed on a system, you’re almost guaranteed that vi is there, so we might as well work with it.

(Besides, I like it, and I’m driving.)

Editing import-mt.php with vi

To start vi, just type ‘vi’ at the command line, followed by the name of the file you want to edit. Since you’re editing import-mt.php, you’d type the following (shown as is with the command line annotation on my server):

-jailshell-2.05b$ vi import-mt.php

When the file opens, you’re going to search for a specific value, and then add some text. Searching for the value is accomplished by typing the forward slash, and then the value :


Type the text, just like that. You don’t have to move the cursor or click a button or hit any other keys.

The cursor is moved to the first character of the first value you just searched if found, in this case under the M of MTEXPORT. This is in a line that looks like the following (truncated for space):

define(’MTEXPORT’, ‘’);// enter the relative path of the import.txt file …

What you’re going to want to do is move your cursor over to the empty set of quotes, and add in the name of the file containing your exported MT entries. You can use your cursor keys to move to the right, left, up, and down, in this case using the right arrow key to move to the right. Once in position, you’re going to want to turn on vi’s insert mode. Do this by typing the letter ‘i’. Nothing else, no keys, no buttons, and you don’t have to sacrifice a chicken. You should see something, most likely along the bottom of the page that looks like the following, designating that you’re now in insert mode, and any text at that point is added to the document:


If you’ve placed the exported MT file in the top level directory of your weblog, you’ll want to signify this using the relative directory syntax, in this case since you’re accessing a file one level above the application, use ‘../’, as in the following:

define(’MTEXPORT’, ‘../rdf.export’);// enter the relative path of the import.txt …

You could also put the exported text file directly in the same directory as the import program, and then leave off the relative syntax:

define(’MTEXPORT’, ‘rdf.export’);// enter the relative path of the import.txt file …

Once you’ve added the text, end insert mode by clicking the ESC key. The INSERT indicator should be gone at this point. Now save the file and exit in one command by typing the command indicator character and the write command. This sequence is as follows:


The command indicator character is the colon (’:’), the write/quit command is (’w!’). At that point, your ready to run the import program.

More importantly, though: you’ve just done your first edit with a Linux command line text editor. Not just any text editor: vi. Have a beer. You’re now officially a hacker.

Import the MT entries

At this point, load the import-mt.php page, click on the button that says, “Let’s Go”, and watch as your entries, categories, people, and comments get loaded.

In previous versions of the import script, each user from MT would be imported as is, with a password of ‘changeme’, requiring you to log in as that person and change the password. Immediately, unless you want to leave your site vulnerable.

However, with 1.2, an important difference is that the script will provide you a list of names from the MT weblog and allow you to map them to existing users in WordPress. What you can do is create the users ahead of time, and then map them during the import. Doing this is a safer, less vulnerable and a more controlled option.

Other than this change, all other aspects of the import as detailed in the WordPress documentation is the same, including the fact that draft essays are only visible when you’re logged in as the user who owns them.

Unless you run into problems, you should get a message at the end giving you an indication of success. When finished, you’ll want to clean up the directory by getting rid of the import-mt.php file in the wp-admin directory, unless you’re going to use it again. No worries if you run it multiple times–the import doesn’t load duplicate entries.

Congratulations! Not only are you a hacker, you’re also now officially an open source hacker, having just moved your weblog to WordPress.

Next, up, time to tweak the interace and add the Multiple Weblog emulation hack.


*No surprise, then, that ‘learn by tweaking’ is the philosophy I plan on incorporating into my future books and articles; instead of the book or article starting from scratch on large applications that already exist as open source, I’m going to focus instead on existing code and then walk the person through modifications. Hopefully this gives insight not only into the original coding, but also how one can look at code and know what to modify to meet new needs.

Technology Weblogging

Survival guide to LAMP: Multiple weblog support in WordPress

M is for MySQL and P is for PHP

For the LAMP series, I’ve decided to focus on WordPress for the nonce. I’m anxious to dig in and start playing with the tool, not to mention migrate the rest of my weblogs. I’ll return to Textpattern at a later time; or we’ll see how Joseph Duemer does with his adventures in Txp land.

My next LAMP essay loads the Movable Type weblog into WordPress, and I’ll post that one in a moment. In addition to this writeup, I’ve also finished my first major tweak of WordPress 1.2, which is to provide emulated support for multiple weblogs. Though it may not be smooth as you’re used to with Movable Type, it is an approach that can be used by those who aren’t comfortable working with PHP.

My emulated multiple weblog support does require copying some–not all– some of the WordPress files into the new weblog directory, but once this has happened, it’s a simple matter of opening up the Switch Blogs page (found in the menu of WordPress after the menu.php file has been replaced) and adding the information about the weblog name, the URL for the WordPress wp-admin directory for the weblog, and the URL to view the weblog.

This information is added into a table (I have a PHP program that creates this), and is displayed in the Switch Blogs page each time it’s accessed. The image below shows what this new page looks like, and how it is integrated into the main WordPress 1.2 interface. Note that only the blogs owned by the person who added them are shown on the page.

I have a g’zipped file of the modified pages ready to look for those interested. If you’re experienced with PHP and/or WordPress and feeling brave–oh so brave–you can download it now and play with the files while I write up the procedure. All I ask is if you run into problems, or have suggestions, please let me know as soon as possible. The modified code is based on the first candidate release of WP 1.2. Follow good procedures and backup your replaced files.

Unzip the files into a temporary directory, and move the files (switch.php, menu.php, and install-multi.php) into your primary WordPress installation’s wp-admin directory. Note that the menu.php file will overwrite your menu.php, so if you’ve made customizations, beware and backup.

After moving the files, run install-multi.php to create the database table (wp_multi_blogs). Then, modify the Switch Blogs entry in menu.php to reflect the URL for your copy of the switch.php page. At this point, Switch Blogs should show in your menu, click on it and add your different weblog locations.

Create the database once, and install switch.php in just one location, but modify the menu.php for each WordPress installation.

More detailed how-to later; however the ease with which I could install this functionality demonstrates the ‘openness’ of both PHP and WordPress. After years of working with complicated frameworks such as J2EE and COM+, or crypic languages such as Perl, I’m finding that working with a language such as PHP is such a joy.

And there’s a new version of PHP coming out. Once this series moves beyond the work with WordPress, perhaps I’ll take a more detailed look at it. However, its unlike that PHP 5.x will be available on most systems for probably about a year, as widely used PHP applications such as PHPMyAdmin go through the upgrade process.

Or if it is available, it’s only so under a different naming convention. Hmm, I wonder if Hosting Matters has it installed…