Converting WordPress to static html

UPDATE: Check out the new post on a better way to do this here: Convert WP to Static HTML Part 2. Or see the page devoted to the script here: Make WordPress Static.

Usually people are wanting to convert their static html pages to some dynamic content management system. I’ve run into the issue of needing to go the other way.

A few professors at GMU love to use WordPress for their classes. It’s a really great way to get more student participation and involve some of those who aren’t so talkative in class.

But these blogs are usually only needed for one semester, and then just sit there. This can be a security risk if they are not kept up to date, and is cumbersome when trying to update many of them (one professor had over 30 blogs!).

Sometimes the content should still be viewable, but the need for a whole cms type back-end no longer exists. Sometimes the professor would just like a copy of the pages for their own future research or whatever.

So, I figured out a way to convert a dynamic WordPress site into static html pages.

Here are the basic steps I used:

  1. Change the permalink structure in the WordPress admin section. Alternatively, directly in the database change wp_options.permalink_structure.option_value to “/%postname%.html”.
    [code lang=”SQL”]
    UPDATE `database`.`prefix_options` SET `option_value` = ‘/%year%/%monthnum%/%day%/%postname%/’ WHERE `prefix_options`.`option_name` = ‘permalink_structure’ LIMIT 1 ;
    [/code] 

    UPDATE (2.12.08): Reading a post from Christopher Price (who linked to this post) about WP permalinks, I’m thinking using this structure (/archives/%post_id%.html) might afford the best results. I often found a page that displayed the raw HTML instead of being rendered. This just might fix that issue.

    UPDATE (3.11.08): I did some more dynamic to static conversions today, and found out the best permalink structure to use is just the post name. No extra categories and such. So the best structure to use would be this (/%postname%.html). The benefit is that the every page is unique with a descriptive name for the url (albeit sometime very long), and there are not as many subdirectory issues that arise.

    UPDATE (7.17.09): This time around, I have found that the following seems to work best for permalink: /%year%/%monthnum%/%day%/%postname%/ And cleaned up the SQL statement.

  2. Add the .htaccess to /path/to/wp/ if not already there (where /path/to/wp/ is from http://somedomain.com/path/to/wp/ ). If there already is a .htaccess file and it is set to have permalinks, then you can probably leave it as it is.
    RewriteEngine On
    RewriteBase /path/to/wp/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /path/to/wp/index.php [L]
  3. Use wget to copy all of the files as static html files.
    [code lang=”bash”]wget –mirror –wait=2 -P blogname-static -nH -np -p -k -E –cut-dirs=3 http://sitename.com/path/to/blog/[/code]
    *** Change –cut-dirs to the appropriate number associated with how many directories are after the domain name. The trailing slash plays a part too. ****
    UPDATE (03.11.08): I found that the –cut-dirs doesn’t really do anything this time around.
    UPDATE (7.17.09): This time around, I find the following to work best, even the –cut-dirs. 

    wget --mirror -P wpsite-static --cut-dirs=3 -nH -p -k -E https://site.com/path/to/wp/

    This has the bonus of making the directory for you, thus negating the make directory step. Make sure to use two dashes and not an em dash.

  4. Copy the contents of wp-content to save uploaded files, themes, etc. This way copies a lot of unnecessary php files, which could be potentially dangerous, but is really easy if you’re just converting to archive. To remove the security threat, just pick and choose the files you need.
    [code lang=”bash”]cp -r /path/to/wp/wp-content/* /path/to/static/wp-content/[/code]
  5. Sometimes the files are created with folders in the archives folder. To fix this run the following three commands in the archive folder to fix that up. To get rid of the feed file in all of the directories:
    [code]rm -f */feed [/code]
    To delete all of the now empty direcotries:
    [code]find . -type d -exec rmdir ‘{}’ \;[/code]
    To rename the files ###.1 to ###
    [code]rename .1 ” `find . -type f -name “*.1″`[/code] That’s two single quotes after the first ‘.1’
  6. UPDATE (03.11.08): I have found that the old ‘rename‘ command [rename .1 ” *.1]only works on the current directory. If you want to do a recursive renaming you have to use the ‘find‘ command. The above code has changed to reflect this.
    UPDATE (7.14.09): When the rename with find doesn’t work, it’s probably because the post has comments, so there is a folder with the same name as the post’s filename. In this case, just move the file (with the .1 extension) into the folder of the same name, but change the name of the file to index.html

  7. move to wp folder. make a backup of database: [code lang=”bash”]mysqldump -u [userfromwp-config.php] -p –opt databasename > databasename.sql[/code]
    UPDATE (03.11.08): I found I needed to backup just a few tables from a database that contained many copies of wordpress. To do this more easily, I used a little script I wrote earlier to dump tables with a common prefix. This could also work if you just put in the full name of only the tables you wanted to backup.
  8. move one directory above wp install. make tar backup of old wordpress folder: [code lang=”bash”]tar -cf wordpress.tar wordpress/[/code]
  9. rename the old wordpress folder [code]mv wordpress wordpress-old[/code]
  10. move the static copy into place [code]mv static/wordpress/ wordpress/[/code]
  11. test out the site. If it’s totally broke, just delete the wordpress directory and restore the original from the tar file.
  12. remove the tar file and wordpress-old directory as needed.

WordPress updater

What’s with these multiple posts in a day…

Today marks the completion of my Multiple WordPress Updater Script. I’ve already posted a bunch about school stuff, might as well post about work stuff too.

We host over 55 blogs at CHNM. It’s up to me to update them when security patches or new versions come out. Doing them each by hand is a pain. I did a bit of searching but didn’t find anything that would help me update so many sites automatically. So I wrote a bash script that will do it for me. It reads a file that lists all of the wordpress install paths or prompts you for the path to one, prompts for the version to switch to, and a mysql user/pass that has permissions for all databases.

Then the script creates a copy of the database, makes a copy of the wp-content folder, updates the wordpress install using subversion, fixes some permissions, and saves the subversion output to a file in your home directory (which I’ll probably change to somewhere’s else).

I run this via sudo as root for easy updating. What I’m really pleased with is that I figured out how to get the script to pull the database name from the wp-config.php file, and grab the owner and group for later fixing of the permissions.

I hope it can be useful to someone. If you have any comments or suggestions, let me know.

Latest Version: 1.2.3 – 04/29/08
Download file

UPDATE 24.4.08: WordPress Updater has been updated. I also updated this post, took out the code in the post, and put up a link to the file for you to download instead.