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.