WP 2.8 weirdness

So, I updated each of my WP installations from 2.71 to 2.8. I started on my local instance, to verify that everything was working the way I expected. It was, so I upgraded one of my client accounts, and it worked fine, too.

Then I tried upgrading one of my personal WP instances to 2.8. It was a near disaster. Oh, the upgrade itself went fine, but it went downhill from there.

First, the Dashboard news items weren’t loading. I didn’t think too much about that, but it did seem odd. The main problems were:

1. Trying to add a new category to an entry was futile. I could click on the “+ Add category” link endlessly with nothing happening, and
2. The “save” button for editing templates was missing.

I tried everything I could, including disabling Google Gears, removing Google Gears, reinstalling Google Gears, deleting all the WP files and uploading afresh from a new download, etc. Nothing worked. I posted questions in both the WordPress fora and Feedback, with no responses.

So, I gave up for the better part of two days.

Today, I got back into it, and low and behold, the news items appeared right away on the Dashboard page. OK, maybe WP was overwhelmed with hits and wasn’t able to serve RSS feeds to populate those areas when I first upgraded. No problem.

Next, I went into an entry and clicked on the “+ Add category” button. It worked! I typed in a new category and hit save. That’s when I got this error message:

Warning: Cannot modify header information – headers already sent by (output started at /Users/accountname/quotes/wp-config.php:153) in/Users/accountname/quotes/wp-includes/classes.php on line 1586

I’d never seen that one before, but when I looked at the blog, it was fine. I went back into WP, and the entry itself was fine, too.

So I opened wp-config.php and had a look at line 153. Like line 152, line 153 was blank. So, I deleted both lines, saved, and tried again. With no other changes, WP 2.8 started allowing me to add categories and make new entries without any error message. Pretty wild, huh? Of course, this is the only file that I held over from the previous install of 2.71 — everything else was new.

There is still no “save” button in the template editor, but I can call up the template files in Fetch for editing in BBEdit, so this isn’t a huge issue.

I have no idea why this worked, but I thought I’d pass it along.

A shortcut to avoid

When the time came to install WordPress on my Mac OS X Server, my local machine was busy proccessing some large log files from a client, so being impatient, I connected to the server using VNC to do the install “directly” on the server.

I popped open Safari, downloaded WordPress, dragged the resulting folder to the home directory of the virtual user account where it was needed, and set up MySQL.

As detailed below, it seemed to run fine, so I figured everything was fine.

Nope.

Yesterday it occurred to me that that WordPress install was perfect for a subsection of that site, so I chucked in some data and started trying to edit the template files and add widgets.

What a mess. The file ownerships and permissions were all off, and even after going through the file hierarchy with chown and chmod, the site still wasn’t running the way I wanted it to.

So, I scrapped and reordered. I deleted (via VNC, of course, because I didn’t have the authority to delete the files using Fetch) everything except wp-config.php, and the uploaded fresh WordPress files via FTP to the virtual user account. A little editing of the template files to clean up the presentation, and I was done.

So, the moral is to upload WordPress to Mac OS X Server via your virtual user’s FTP account, even though it seems faster and easier to do it “directly” using VNC.

Running WordPress locally to upload to a remote server

I was poking around in the MAMP fora and came across a question from someone who wanted to run MAMP locally on his Mac and then upload the files to a server.

Here is my response:

It seems that you have a misunderstanding of how WordPress works. You are supposed to install WordPress at a location where it can be reached by those you wish to see it. That is, it is not designed to be a local CMS, the output from which you can then upload to a remote server. To have a WordPress blog, you should install WordPress on a public server, and do all your work over the Internet.

Note that you could use the WordPress Super Cache plug-in to generate static HTML files, which could then be uploaded to a server that does not run WordPress. However, the search feature (and perhaps some others) would not work, so you’d be presenting a crippled site to visitors.

If you cannot install WordPress on your (or a) public server, you can get a free WordPress account at wordpress.com, and let someone else worry about the server admin details.

Finally, you could run a local WordPress install, export from that local install and import to a remote install, but each time you did this you’d have to delete all the posts (entries) on the remote system to prevent duplicate posts. You could do this manually on a small blog, but for a large blog you’d want to use phpMyAdmin or something similar to empty your table before importing. It would be a real hassle.

Installing WordPress on Mac OS X Server 10.5

When I first got my G5 XServe, I tried setting up Movable Type the “normal” way (using MySQL), but for some frustrating reason, the MySQL that comes pre-installed on Mac OS X Server 10.4 is missing a key perl module that allows Movable Type to interact with MySQL, so after days of trying to install the module via CPAN, I gave up and used SQLite. It works fine, but it’s tough to find tools to deal with SQLite databases the way you can with MySQL databases using, say, phpMyAdmin.

So, when my colocation facility informed me that it was dramatically raising the price for XServe customers, I bought the on-paper faster dual-core Mac Mini and Mac OS X Server 10.5. Again I tried setting up Movable Type using MySQL, but ran into the same problem. I wondered about WordPress, but figured it would have the same database connectivity issue as Movable Type, so I didn’t even try it. (Also, I wasn’t keen on the idea of having to transition everything from Movable Type to WordPress on my tight schedule for swapping out the servers.)

Last week, however, it occurred to me that one of my sites might benefit from having blog/CMS software available, and rather than install another instance of Movable Type, I took a shot at WordPress. I fully expected to fail, because unlike Movable Type WordPress works only with MySQL; there is no option for SQLite.

So, I set up a new MySQL database, downloaded WordPress to the destination folder, checked ownership and permissions, and then called up the install wizard in my browser.

No go, but as I said, it was no surprise.

Just as I was about to delete WordPress and proceed with Movable Type, I opened Terminal.app to delete the database I’d created. However, the response to every command I typed was that as root @ localhost I didn’t have permission to access MySQL! On a whim I opened up my MySQL management software and tried to delete the database, and was given the same message.

On a whim, I tried gaining access as root @ the FQDN for my server, and it was granted immediately. Ah ha! I then edited the WordPress config file to reflect the FQDN in place of the localhost designation, and from that point on, everything ran flawlessly.

My initial failure with WordPress (localhost vs. FQDN) may be more of an issue with the way I have my server set up than anything else, but the bottom line is that WordPress does run on an unmodified, unpatched, untinkered-with Mac OS X Server 10.5 using MySQL where Movable Type apparently does not.

Note that there are those who scrap the pre-installed MySQL and then install their own version from scratch, but really, even my geekiness has its limits, and that is beyond mine.

My only problem now is that I must decide whether the game of transferring my existing Movable Type CMS to WordPress is worth the candle. As luck would have it, the first several hundred entries have nice HTML tags and transfer over beautifully. I subsequently became lazy on my data entry, though, and began relying on Markdown and SmartyPants, and for reasons not yet understood, the WordPress Markdown and SmartyPants modules handle Markdown syntax much differently than either Movable Type or BBEdit. I may have to hack the modules to get the same results, as I don’t see myself going through my Markdown entries in the Movable Type export file and recoding them with HTML tags. Ugghh.

Well, at least the Movable Type install is running fine … there is no reason to transfer that section of the site to WordPress. And, for all future CMS installs, I can always use WordPress. I’ll just have to remember to change my rsync backup strategy to include the MySQL databases for the WordPress installs, as the SQLite backups are simply file transfers — one of the benefits of using SQLite.

Converting from MT 3.34 to WP 2.65

I recently had the opportunity to convert a large-ish Movable Type system to WordPress for speed testing and usability evaluation. By “large-ish” I mean 12,038 posts, and 43,043 comments. This may not be large by others’ standards, but it was plenty large to me.

Here are some of the steps I took. If you’re facing a similar conversion, I hope this information saves you some trouble.

• Before exporting from MT, I did a GREP search and replace on the entries and comments, as some authors and commenters had used multiple hyphens as separators (e.g. “———”). I already knew that MT uses multiple hyphens as separators in its export file, so to avoid confusion, I replaced all such runs with dots (e.g. “………”). Note that you can do this on the exported text file, too, but then you have to worry about munging valid separators.
• I exported the entries and comments from MT. This gave me a 70.1 megabyte file.
• I converted all special characters to ASCII. I wanted a file with no smart quotes, m-dashes, etc.
• I converted all HTML entities into ASCII. Note that WP will do this conversion on import, but I got better results converting the entities before import.
• I did some general clean-up, such as eliminating multiple newlines, although you can get into trouble doing this, because there are places where multiple newlines are expected. Use your own judgment.
• I split the file into 10 megabyte sections.
• I checked the end of each section against the beginning of the next section, moving text around so that every entry was contained in one file, with its associated comments, if any.
• I set up a scratch installation of WP on my local computer.
• I imported each 10 megabyte section into WP, then exported that section as a WordPress XML file, and then in phpMyAdmin emptied the MySQL table of posts, comments, and relationships before importing the next section.
• I repeated this last step until I had eleven WP XML export files.
• I transferred the eleven WP XML export files to the server (wp : wp-admin : wp-content).
• I imported each file into WP.

Without breaking up the large file into smaller files, I was getting partial imports, time-outs, etc. It was a real hassle. Even breaking up the MT export file into pieces, and attempting to import those into WP proved problematic. However, pre-processing them through my scratch installation of WP worked well — especially with the smaller files.