Year: 2004

This is just a quick tease not a full essay.

Want to see a static HTML page from WordPress? Take a peek. (You can see static rendering of the Atom syndication feed here. Burningbird here. Program modified to grab all content in page and reproduce.)

I logged into the #wordpress IRC today, and the issue of static rendering of pages came up. A valid concern about dynamic systems such as WordPress, which use PHP and a database to generate content, is that sometimes this can be a burden on the system–not to mention the pages not displaying if something happens to the database.

For the most part, PHP/MySQL applications run without any problems, even with large numbers of people accessing the site. Currently the WordPress site is under load with all the sudden, new interest in this weblogging tool, not to mention being slashdotted, and it’s holding up just fine. However, if you have a page that is relatively stable and unchanging, such as a syndication feed, you might want to generate a static page just for the sake of added efficiency. In addition, things happen, and even a stable MySQL database can fail at times.

So, I played around with PHP source I found online and came up with a rendering routine that hopefully will render my main page and feeds each time I publish. Then with a little tweak or two in the .htaccess file, if something happens to my main feed or page, you’ll see the static pages instead. Or for feeds, you can have people link directly to the static feed to prevent extra burden on the system if you have a lot of subscribers.

Still playing with the code, and file permissions and PHP are an issue that deserves some in-depth writing –but I wanted to quickly point the result out, as another tease for LAMP essays for this week (writing the code is easy; writing the how-tos and documentation and creating procedure for non-techs, now that’s hard). I also wanted to mention how fun this is.

I Can’t remember the last time I had this much fun working with technology. I feel like a young, eager programmer again, ready to swig my Dew (or double strong caramel macchiatos), as I work into the wee hours of the morning, hacking line after line of code. Gone is the tired old woman who has written one too many semi-colons; burned out on bugs, tired of the latest new tech buzz, not to mention program managers who should have been drowned at birth. I have caught my second wind, if one can catch a second wind when it comes to software development.

Playing around with WordPress and the LAMP series has become a face lift for my soul. Now, if it only did breasts….

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 :

/MTEXPORT

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:

– INSERT –

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:

:w!

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.

update