Okay, I made a lot of mistakes along the way to forcing my static HTML information into the WordPress database. In an effort to help others learn from my mistakes and compromises, I present mine to the world so you can see that a lot of hard work and screw ups went into the finished product.
The first mistake I made wasn’t so much of a mistake as lack of information and lessons learned by trial and error. That was the issue of the order of the fields in the MoveableType import file. It has to be in that order and there is nothing you can do about it.
The list of mistakes is long, but the point of these mistakes was the lack of information to help me avoid them, so I wanted to list that information here, to help others avoid the same mistakes.
I also had to make a lot of compromises along the way to importing my entire 500 plus static html web page site into WordPress. Some compromises were content issues, some were technical, and a lot were design issues. This is just a start of the list of compromises I had to make related to importing my site and stripping out html, Javascript, and other code elements. I’ll get to the rest of them as I start to work on the design elements.
Giving Up Meta Tags
For the past five years, I’ve worked long hours researching meta tags, their use, purpose, and assistance for users and search engines. I’ve analyzed what tags were the best to have, even going to the lengths to have the PICS tag for approval of the site as “not harmful to children” with a good G rating. I also have tags for “abstract”, “categories” and others specifically targeted towards each individual article. These have been lovingly created and I’d hate to loose them.
I had to give them up. Well, not totally. I had to give up the ones customized for every page. Through the use of plugins, which I’ll get to later, I was able to add in keywords, but the description, abstract, categories, and a lot of other meta tags had to go bye-bye. Not just because they aren’t useful any more, and some aren’t, but because WordPress adds so much more to the package, these are almost redundant.
Clean Page URLs
This was the hardest for me to compromise on. Every category was represented by a folder name which matched the category name. So an article in the Learning Zone from the section on Photographic Equipment had a nice URL:
http://www.cameraontheroad.com/learn/equipt/buyingcamera.html
By default, in WordPress this might become:
http://www.cameraontheroad.com/index.php?p=432
WordPress has a powerful feature called Permalinks. Permalinks allow readable links to be created as links to your data. From the above example, it might become:
http://www.cameraontheroad.com/tips-on-buying-a-camera
You can also set the categories to be visible with a name, like category or archives or fred if you wanted, so the above link might look like:
http://www.cameraontheroad.com/fred/tips-on-buying-a-camera
With the new version of WordPress 1.5 came the ability to include the actual category that a post is in. For the above URL, since it is from the learn category, the link might look like:
http://www.cameraontheroad.com/learn/tips-on-buying-a-camera
Fantastic, right! Enter the compromises. My website hosts is several versions behind in their Apache software, and their version won’t handle the rewrite codes that make this process possible. My site totally chokes on this. I’ve written, voiced, and chatted with them to encourage them to upgrade their software, but all I get are “soon”, whatever and whenever “soon” means. So for now, I live with the ugly index.php?=432 until my server gets on the ball, or I change them. I may switch to the simple permalinks, but that means I’ll have to add redirects when my host server upgrades….and I have over 500 redirects from my old site to my WordPress site URLs….and I’m tired of them.
Styles in the Header
You might think that this topic would be found in my article on the compromises I had to make in the design of my new site, but it totally impacted my import. Since I had a lot of styles within the header on a good number of pages, styles unique to that page or to the series of articles I was working on, these would be lost in the import unless I took special care of them. I soon realized that the majority of these were in one category of articles associated with web page design and development. Since I couldn’t leave them in the header, as the header is a template file used for every page generated, I had to make a compromise about how I would have normally handled these.
Since the majority of these were in the one category, I figured that I would have to make a style sheet that would be added to the posts if they were in that category. How I would do that would have to wait, but I needed to preserve the styles.
As I encountered these embedded styles, I copied them and put them in a special style sheet, with a comment about which article these came from. Tedious, but I needed to do this to keep the design elements.
Article Series or Multiple Pages
Since I tend to work in series rather than individual articles, I have broken up my articles into smaller chunks on many occasion so the user can just click to the next page in the series. Since the ability to maintain articles or posts within a series is more challenging in WordPress, I debated over what to do about the shorter article series.
Some research uncovered a multiple page ability within WordPress. By using the quicktags NEXT in the Write Post edit screen, I could insert a “next page” into an article so that it would be read across several web pages while still being only one post.
This meant I had to remove the titles, authors, and excerpt information and merge the content together in the linked articles, making them into one giant article. After they are imported, as I go through and do my edits within WordPress to make sure everything is working and made it into the import, I can insert the <--next--> tag into the spots where I want the pages to “break”.
Article Titles
I’m not so sure I would call this a compromise, but in a way it is. I had to deal with the titles of my articles that highlight the fact that this article is part of a series. Since the different parts are actually separate articles within the same topic but different information, they were:
Closeups in Nature Photography Part 1
Closeups in Nature Photography Part 2
Closeups in Nature Photography Part 3
I needed to help the user understand that this is part of a series when the article title is turned into a permalink or while navigating the site, while not having the title sound too similar. Each title has to be unique and make sense. I decided to change them to something more useful:
Closeups in Nature Photography
Closeups – Macro Photography Equipment
Closeups – Lighting For Macro Photography
This not only expanded the title to match more of the content, it helped make the articles stand on their own. I also decided to write a little more to help give them some more punch to stand on their own better, while still being part of the series.
Pages and Posts
WordPress works with posts (aka articles in my lingo) and individual Pages. The posts are in the database and work within what is called the WordPress Loop, a fascinating piece of PHP coding that pulls the post information from the database and displays it, depending upon the type of request by the user, be it “view a specific category”, “view the front page”, “view archives”, “view an individual post”, and more. A WordPress Page is different. While its information is stored in the database, too, it actually works “outside” of the WordPress loop, acting more like a static page. It isn’t static. It’s a generated web page, but it works and acts differently from the regular posts or articles. Typically, individual Pages are used to create web pages like “About us”, “Contact us”, and “Events and Schedules”, web pages that hold information in a more permanent manner.
Since I was coming from a world of every web page being a static html page, I needed to look at my pages differently. I’ll go more into the how and why I chose which pages to become Pages and not posts later, but for now, I had to debate over which ones I would import as regular posts, and which ones I would hold back to keep as Pages. Not as easy a choice as you might imagine, but one faced by everyone using WordPress.
I wish I could say that this process was easy, but I kept feeling like I was the first one to actually convert a static HTML site into a relational database system like WordPress. I know I’m not, but I searched for ages to find answers to the simplest of questions about this process and could find very little in the way of helpful resources. It was hit and miss, backup and restore, or just plain start over for about two months until I struck gold. I hope that you learn how to avoid these mistakes, because if I did it right to begin with, using all this information, the process might have taken one to two weeks of hard core work and not two months of hit and miss struggles.
That is the purpose of writing all this down. This is one of the main reasons we have this website. Whether it is working on the computer, on the Internet, with web pages, or photography, travel, or life on the road, I write these things down because I want others not to suffer in the way we have. And boy, have we suffered. Hee hee, sigh.