Categories
Technology Weblogging

Additional links for moving from MT to WordPress

Carthik.net has a good summary on must reads for moving from Movable Type to WordPress.

LibraryPlanet just wrote up a migration strategy (and provided code) that encompasses how to use WordPress 1.2 new slug feature to support the MT keyword-based shorter file names.

If anyone else has any links related specifically to exporting out of MT and importing into MT, please let me know. Especially if you’ve run into problems and have work arounds.

PapaScott has some MT Export Gotchas to watch our for.

Categories
Technology Weblogging

Survival guide to LAMP: who says you gotta be dynamic?

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 hereProgram 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….

Categories
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 :

/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

*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.

Categories
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…

Categories
Technology

Survival guide to LAMP: Rushing forward

I have put aside all efforts in regards to my bookbinding work, and all photography, and other writing about hikes or cats or life in miniature, in order to focus on finishing the LAMP series as quickly as possible. (Other than those efforts that pay the bills, of course.)

As I work on the next installment, a couple of caveats:

First, I’m going to be editing the last essay and removing the reference to using install-config.php for WordPress, replacing it with instructions on editing the configuration file. I had forgotten that to run install-config.php requires that the directory is writable, and this makes this choice the more complex installation routine to follow rather than the least.

Second, there seems to be confusion that one can’t charge for open source software. As I mentioned earlier in Spin City, you can charge, but you need to carefully set expectations for people using your software. Matt at WordPress has said they won’t charge, but even if they do, we can copy the software and go our own way if we wish–it’s open source. Dean Allen at Textpattern is contemplating charging for the commercial uses of his product, but he’s setting expectations at the start for this direction.

Software and ‘gotcha!’ don’t go together well.

Third, I will be talking about Textpattern and how to use it and demonstrate moving a Movable Type weblog to the product, and altering the templates, but I won’t be making any modifications to the underlying code for this product. Again, it is a single developer product, and not the one I’ve chosen for my own weblog. I’m reserving actual code changes to my work with WordPress, only.

As I continue writing on LAMP, I wouldn’t mind some feedback from people as to what they want to hear about in these essays. Consider this thread an open thread on this topic.