Well, I’m doing another big coding conversion involving Wordpress, and I’m going to blog about it this time. I’m converting an HTML site to Wordpress.

Now I’m going to convert my long-standing old-fashioned HTML website, at Tim’s Missouri Employment Law Info Site - TimsLaw.com into a Wordpress site. [UPDATE - 4-1-06 TimsLaw.com is now LIVE as a Wordpress site - Today I pointed TimsLaw.com at the Wordpress working directory I used during the conversion. I have an article on TimsLaw about the conversion, listing some changes and glitches: TimsLaw conversion to Wordpress, Read about Glitches and stuff]

[AND I’ve started a new thread about Wordpress as a content management system]

[OUTDATED PARAGRAPH] I’ve decided to let you in on the BETA Wordpress version of my business site. Play around with it, and leave some feedback for me. The BETA site is at MissouriJobLaw.com (MJL). MJL is another domain name I had laying around. Eventually I’ll redirect my main domain - TimsLaw.com - at the Beta site. [UPDATE 4-1-06 - TimsLaw.com is now LIVE as a WordPress site.]

But before you go explore the Beta Site, the following is a chronical of my adventures in conversion.

Most of the issues I discuss below are ALSO applicable to this RadMod blog, because I am doing many of the same things, and even using essentially the same theme.

My previous project involving Wordpress was in converting my BlogSpot blog to a Wordpress blog that I hosted on my virtual account at Pair Networks. I wrote about my experiences in doing the conversion here.

When I recently changed themes here at RadMod.com, I blogged about that too, and there’s some stuff in that article about DC-Nicer Archives.

Organization of this article:
Latest updates and solutions at the top of the Post, then working backwards in time, down to the original Post in which I discussed the initial problems I was facing.

Now, read the UPDATES first ——-

UPDATE March 31, 2006 — OOPS! Boy did I ever make a lot of extra work for myself over the LINK-conversion issue!

Read about the LINK - Conversion issue way down below, which is chronologically the start of this conversion blog. My HTML site has articles that heavily inter-link, using relative references. A relative reference is like this, assuming all files are in the root of the site:

Here’s an absolute reference:

Well, I used relative internal links between files on my old website. I figured that Wordpress would not be able to find the files unless I used absolute references, because “Wordpress would not put the files in the root of the site”, Wordpress would be putting the files into a database, and would want to use category names and dates, etc….

So, as I talk about far below, I went through a TEDIOUS process of changing all the links from relative to absolute. WASTE OF TIME UTTERLY!!!!

Turns out that Wordpress can handle my old internal links, showing “relative” URLs in site-root, without any problem

But you have to have your settings just right: In Admin, you have the option to tell the permalink feature what things to put into your URL string. For example, you can put % category % in front of your filename. Most people put the category or the date in front of their filenames.

AHHH — but I chose NOT to put ANYTHING in front of the filename when laying out the permalinks in the Admin screens. Nothing. Not a categoery name, not a date, nothing. And then, I got WordPress to automatically append “.htm” to the filenames ….. read on …..

You can also put stuff AFTER your filename. I chose to put “.htm” after my permalink filenames, and NOTHING before the filenames.

WOW! Wordpress now will serve up a page linked as < a href = " / myfile.htm" > Myfile< / a >, JUST LIKE MY OLD HTML SITE DID!

And so, once I figured out that Wordpress could have worked with my old relative links, I re-converted the absolute links BACK to the original relative links from my old files. I used the Search and Replace plugin to do that.

I searched for the string: < a href = "http : // www . missourijoblaw . com/

And replaced the string with: < a href = "/

[By the way --- all the href references I quoted above have extra spaces in them of course, just so WordPress didn't mistake them for actual code]

Generally, this fix has worked. A few links got changed that I didn't want to get changed. A few links got missed because I had something screwy in them by mistake.

But I haven't found any systemic problem, and the overwhelming majority of my OLD relative links still work fine in WordPress.

UPDATE as of March 11, 2006

[Update March 26 to this March 11 Update —- I wrote about Jerome’s Keywords, and tried it, and liked it, but in the meantime I moved instead to Ultimate Tag Warrior for the greater number of features and power, and I am now keywording all my articles - I’ll keep the Jerome’s keyword update here, in case anyone finds it useful - Back to the text now …… ] JEROME’S KEYWORDS is giving me some frustration. I cannot put a CSS style on the keyword links produced by Jerome’s Keywords. JK outputs a list of the keywords associated with each article, right at the top of the page (cuz that’s where I wanted them to appear). BUT —- I cannot apply any custom link styles and colors to the outputted links.

I’ve tried for hours, all manner of things, and nothing works.

The problem seems to be something regarding the fact that the links are in an array, and also that the links point to a Wordpress search-type function. Somehow, the array and the search function prevent my CSS attributes from being applied to the href links. Darn. Much time wasted, and I can’t do what I want with the keyword display now. Very disheartening. I may have to find another keyword plugin.

UPDATE as of March 10, 2006

Today I destoyed all my posts, over at M.J.L. dot com. I wiped them out completely, in a malformed MySql search and replace (using phpmyadmin). Fortunately, I had backed up the database right before playing with it.

Why did I use phpmyadmin when there is a nice “Search and Replace” Wordpress plugin? Well, the F’n Search and Replace plugin DID NOT WORK on this global search and replace for an unknown reason. (It’s worked at other times). Maybe the nature of the search was funky. I was trying to replace all the old temporary links in my files to say MissouriJobLaw (rather than simply specify a subdirectory of my webserver). S & R SAID it had success, but actually didn’t change any data.

So I tried to do a MySql search and replace, and did it wrong. All post content data was wiped out completely, and was replaced by bits of the actual query I ordered. I misused quotes in writing the Search and Replace, and MySql put the quoted words into the data tables, replacing what was there.

Restoring a Wordpress data table, such as the one containing your POSTS, by cutting and pasting from an SQL backup

Anyway, NOW I had a new problem: How to restore the old data. THAT was an adventure! I had backed up the data JUST BEFORE messing with it, in two ways: First, I dumped the ENTIRE database into an .sql Export. Thank GOD!!!!. Second, I exported just the Posts in CSV format (CSV was USELESS - CSV would NOT restore - kept throwing off errors in MySql when I tried to just restore the posts using the method of uploading a CSV file).

Eventually I learned that the SQL file was just a plain text file. So I loaded the SQL backup file into WORDPAD, scrolled down to the section where the posts were listed (you can’t miss it!). And GUESS WHAT? A MySql complete export (a dump) contains all the code necessary to automatically restore the data, if you just copy and paste the data into a MySql query window using phpmyadmin.

So, here’s what I did, using phpmyadmin: First, I “EMPTIED” the data table for the Posts Table in my database. Emplied it completely. Then I clicked the “SQL” link in phpmyadmin. I then see a box that says it’s a Query box, as if I were to type a Query. Well, I didn’t type a Query. Instead, I PASTED the ENTIRE 1.3 meg chunk of Wordpad characters right smack into the Query Box. Then I clicked GO.

SUCCESS!!!!!!!!!!!! Can you imagine how pleased I was?

[Note that Phpmyadmin would NOT import the CSV data I’d carefully dumped earlier. MORAL: Always do a FULL EXPORT, and Always use the wonderfully complete SQL format.]

UPDATE as of March 8, 2006

• The DC-Nicer Archives plugin still won’t display the Excerpts when displaying the Categories in WP 2.01. The problem could be my plugins, or a changed function in WP 2.01. Or it could be the ADD FILTER command that Nicer-Archives issues. See this for much more on Nicer Archives and how it ALSO interferes with my Admin Panel: I wrote about my experiences in doing the conversion here
• I’m playing with the Jerome’s Keywords plugin to provide “Related Posts” links at the top and bottom of each article. This is REAL COOL! I can’t wait till you can see it. But my Beta site is a few days away from being announced. I have an aold domain that I am going to point to it this week. STAY TUNED! I’m NOT displaying Category links on my business site.
• I tweaked the WP-print plugin, called “wp-print.php”, to have it grab a second post (my short Address post) and print it on the bottom of any page the user wants to print. WP-print only acts on the current post. But my Address and Contact Info is in a separate post, so it can be linked throughout the site. I needed to get the Address post to print at the bottom of every page that “wp-print” printed. I wrote my own Wordpress Plugin, which I call “Tim’s Hacks”, and put a function in it to grab just the content of the Address post. WP-print calls this new echoing function, and displays the output at the bottom of each printed post. COOL!!!!!!
• PHP syntax kills me as a newbie. I can’t hardly ever get an IF comparison to work. I set up two variables containing numbers, (I print ( ) out the variables on the screen to double check). Even though both variables print out numbers, when I tell php to “do something” IF the two numbers are NOT equal, (!=), php won’t do it. No matter what the numbers are, php always thinks they are EQUAL. Argggghhhhh. It’s HELL being a php newbie!!!!!!!
• STAY TUNED for the link to my beta business site.

UPDATE as of March 1, 2006

As of March 1, 2006 ——-

POSTS vs PAGES: I committed to using POSTS not PAGES. I found that Wordpress will not let PAGES appear in multiple categories. Also, the plugins work mostly on POSTS, not pages. I want flexibility with my presentation, and plugins, so I’d better stick with POSTS.

I’ve now uploaded about 40 HTML articles (using Copy and Paste) out of my 120-odd articles into Wordpress categoried posts.

PLUGINS: I’ve fussed with DC-Nicer-Archives. I’ve gotten it to work with Wordpress 2. The only problem I have encountered is that the Archive list will not Expand to show the Excerpts when the Expand link is clicked. So I went into the plugin file (nicer-archive.php) and changed the lines of code calling for the Expand and Collapse when the Archive list is displayed. The code for the expand and collapse is still present, but the LINK TEXT is now a space ” “, rather than the words Expand” or “Collapse” . So the presence of the link is invisible to the user.

However, the Expand and Collapse work fine in the Search list, and I left those alone.

LINKS: I tediously converted all internal links in my HTML pages to ABSOLUTE links before cutting and pasting the HTML articles into Wordpress POSTS.

THEME: I reached the point of modifying the Journalized theme to look like my old site.

Unfortunately for all the DIV purists out there, I decided to use my old 3-column TABLE structure. The various pieces of the site, Top, Middle, Leftcolumn and Rightcolumn, all contain parts of a TABLE structure. The Top is a fully-self-contained series of tables and menus. The body of the display (below the Top) is 3-column, one-row table. The Footer is it’s own separate thingy that appears after the 3-column table. The Loop and Showhomepage files contain alternative code for the Middle td-tagged column in the 3-column table display. The left and right columns are each wrapped in td tags. The Index file calls the pieces as follows: Top, Leftcolumn, Middle (either Loop or Showhomepage), Rightcolumn, and Footer. PHP magically assembles the pieces.

Folks, I tried and tried to find a good fluid DIV-based 3-column design, that would degrade gracefully, and would contract and expand well in different browser display configurations.

But I don’t understand enough about z - indexing and offsets and margins and positioning. Every so-called “fluid” theme or coding scheme talked about “good” things like “Making the middle column overlap the right column in narrow displays” — Who the hell wants to have content overlap content? Also, even the best DIV coding has serious quirks and needs little coding hacks for cross-browser support.

Browsers support tables just fine thank you, without hacks. You don’t have to be a DIV pro to get the display you want. I want a completely FLUID site, WITHOUT hard-coded positions and fonts and without cross-browser issues and without hacks.

I tried the DIV coding route. My own ignorance means I loose flexibility - I kept breaking the display while changing the code. I don’t want to be beholden to a theme — I want to be free to make it do what I want, and I can’t with DIV-based coding.

But I know pretty well how to do it all with tables, and I’m gonna stick to it.

In the specifications for CSS-3, I hear that CSS will provide for “columns”. In a couple of years, when CSS-3 gains broad support, and the DIV-hacks aren’t needed anymore, I’ll convert my code to DIV-based.

But for now, it’s back to TABLES.

PRE-CURRENT-STATUS DEVELOPMENT ISSUES

Read this section to get the history behind the things mentioned in the Current Status section above.

WHY CONVERT FROM HTML TO WORDPRESS?

I want to be able to write short and quick updates, very frequently, without having to go through the following hassle: create new pages in my html editing program, upload the pages to the web server, tediously LINK the pages into my old-fashioned manually produced “Site Map”, and edit my Front Page to add a news item about the new page.

I figure that a content management system like Wordpress will make it so easy to add a new post that I won’t be able to resist adding lots and lots of new content.

Search engines love new content. People find me in search engines. When people find me, it translates into clients.

And so, if I convert to Wordpress, it’ll be good for business.

FIRST STEPS IN THE CONVERSION PROCESS

• Grabbed the very latest version of Wordpress
• Setup a brand new database with my webhost. No sharing of databases among Wordpress installations. My hosting account allows me to have several databases.
• Installed the newest Wordpress into a subdirectory of my website. As of yet, my converted website is not reachable through a domain name. I access it by typing in the directory name and the name of the index file. Eventually, I will have to change the configuration settings in Wordpress to reflect the real domain name, rather than a subdirectory of my domain, but it’s not time to go live yet. Much work to do before that happens …
• Installed the latest version of Mike Little’s 3-column Journalized theme.
• Did NOT tweak the Journalized theme. The latest Journalized theme allows a bit of modifications through an administration interface, and that’s ALL the tweaking I’m going to do until I get my content sufficiently converted. My main site is a 3-column site. One day I will modify Little’s theme to look like my main website. But now is not the time to take on that HUGE project. [UPDATE —- oops, I have completely modified the theme: Little’s theme is not apparent any longer, and the beta site looks just like my old site. See the Current Status section of this article for more info]

CONCEPTUALIZING THE DATA - In other words, what will the data structure be?

• The design of my old fashioned website is pure old HTML, with all files residing in the root directory. Each file has a reasonably short name, ending in “.htm”, and there are about 120 html files on the site. The articles are heavily linked to each other.
• Wordpress doesn’t store articles in the old-fashioned way. Wordpress articles are NOT stored as “files” ending in “.htm” names. They are stored as text in the database.
• Every link inside each file will have to be edited to point to the new articlenames in Wordpress.
• Is it better to convert my articles to “PAGES” or to “POSTS” in Wordpress? I don’t know the answer to that question yet for sure. I’m trying both. [Update - POSTS are better - they allow for multiple categories for each post, and plugins work on posts. Pages aren’t of much use as it stands today.]
• INTERNAL LINKS AND PERMALINKS PROBLEM - CHICKEN OR THE EGG PROBLEM: I can’t update the internal links within my html pages, to point to the new Wordpress versions of the pages, until I get the pages themselves converted to Wordpress. Until a page is converted, I will not know for sure what the “permalink” will be, so I can’t edit the dozens of other pages that might link to this converted page.
• POSSIBLE SOLUTION TO LINKS PROBLEM? In Wordpress’s permalink options (see the Admin interface), I can set the Permalinks to ONLY use the PostName in the permalink (not the date or the category), AND - GET THIS — I can arbitrarily have Wordpress add “.htm” to the end of each post. —- Could it be THAT EASY? If so, I could just cut and paste my old artlicles into new Wordpress blog posts, and keep the same filenames as the html versions.
• [UPDATE ABOUT LINKS PROBLEM:]
  The “possible solution” to the filename problem works, but caused another problem. By “works” I mean that my posts all Appear to be in site-root, with .htm extensions.

  HOWEVER: When viewing individual posts, the Wordpress “FilePointer” shows that Wordpress is working within the confines of a specific category - the Category for the post that is being viewed.

  Strangely, Wordpress now interprets the .htm permalinks to be FILES WITHIN THE CATEGORY BEING BROWSED.

  Example: Let’s say my theme contains a menu item linking to a post called “bio-of-tim .htm”. Let’s say I created the bio post in the Category called “About”. My permalinks DO NOT use the Category Names, just the postnames with “.htm” appended. Now let’s say we have a visitor viewing a post in the “Politics” Category. Hover your mouse over the Menu Item linking to the “bio” post - you will notice that that the link now magically appears to be “/politics/bio-of-tim .htm”. If the viewer clicks the link, they get a 404.

  SOLUTION: (Remember that I have NOT YET copied my old HTML pages into Wordpress) Taking me hours and hours, and several Windows utility programs, I changed the thousands of “relative” internal links within my HTML pages to be ABSOLUTE links. Example: Old way was to call my bio by relative link: a href = bio-of-tim.htm . New way: a href = http: // www. mysite . com /bio-of-tim.htm .

  Then I uploaded a LOT of my old HTML articles, into various categories of posts and tested my new linking scheme.

  So far Wordpress seems to play nice with ABSOLUTE internal links.

  MORAL: I will use only absolute links within Wordpress. Remember that I set my permalink structure to ONLY use “postname”.htm — I want the freedom to move articles around within different categories as I develop the site, without breaking any internal links. My articles all heavily lonk to each other.

• HOME PAGE ISSUE: My cover page is very important to my site. It isn’t a gateway page - it’s an important general introduction to my extensive legal site.

  In Wordpress, the “Blog” nature of the software will cause whatever I write last to show up as the “most recent” post on the front page of the site. Therefore, I will have to learn how to effectively use a “STATIC HOME PAGE” in Wordpress.

  [UPDATE] I fixed the static homepage issue in MY OWN WAY: I didn’t like the Wordpress default way (to treat the “home” post as the homepage), and I didn’t want to use a plugin to cause a post to appear sticky on the front page. I didn’t want my front page text to be presented the exact same as blog post, but I didn’t want to create a special theme just for the front page.

  Here’s what I did: In my index file for my theme, where “The Loop” would normally appear, I built a PHP instruction something like the following —- if ( is _ home ( ) ) include (’myspecialhomepagetemplate .php’); else include (myloop .php)

  The Loop is in its own file, with some special coding that will apply whenever any post is viewed.

  The showhomepage.php file DOES NOT include “The Loop”. AND it contains some very special coding just for the front page. Some code that might call for display of Next Post Previous Post is gone, and comments-related language is gone, etc… [or comments WERE gone, but they come back from time to time as I invite people to leave me feedback. Few people do so, tho]

  ADVANTAGE OF MY APPROACH: I didn’t have to create a special theme for the front page of the site. Also, by avoiding using a post called “home” I avoid the problem that Wordpress would present my homepage text as just another blog post.

  It seems to work very well on the beta site so far.

MORE EDITING OF THE OLD PAGES

• I controlled the layout of the old html site through TABLES, and I controlled the font and colors through css rather than through FONT tags.
• In preparing the old articles for cutting and pasting into Wordpress, I only need to cut out the CONTENT section from the middle column codeblock for each html page, and the text is pure and clean and pretty much free of formatting and classnames and IDs, and is properly wrapped in P and DIV tags.
• In Wordpress, I have set up a lot of categories, kind of like the main categories of articles I use on my html site.
• If I convert the article text into POSTS rather than into PAGES, I can assign each Wordpress article to multiple categories.