From time to time, specific for a single project, I create a WordPress web site. I put a WordPress theme, add some user accounts.
It is actually simpler to handle a small WordPress web site, rather than create the files in HTML, even for a small project, with only a few links to it.
But the project, being small & tiny, by its definition, ends after a while.
Three things happen after some time passes:
- You need to update contact information, because some data, inevitably, changes.
- You still need to update the WordPress CMS (mostly, for security reasons, to prevent hacking) and all the plugins. You might consider updating the theme, also, if you worked with child themes (for older project, I don’t think that this was even an option).
- You need to make sure that for all the people involved in the project, the site looks good (so, if someone visits the web site, it would look nice as a portfolio).
After some thinking, I found that it’s simpler and easier to just convert the WordPress into plain HTML web sites. See a live example » (see how the web site used to look in the past, on WordPress »). I’ve done a few others, for other web sites.
What are some takeaways on the project?
What steps should you take prior to making the conversion from “live” WordPress to “static” (plain) HTML, no PHP?
- First of all, test that the conversion works. Do a live test, and see if you can generate a working HTML site from your dynamic WordPress installation.
- Put a notice that the project has ended on the homepage and on key pages (contact / submission / join / login).
- Close all the possible forms as you can.
- Close the comments (if you already display some comments to some articles, put a message beneath, something like “The project has ended. The comments are now closed.” so that people are informed.
- Hide the newsletter form completely (there will be no news, you don’t want people to subscribe to a closed project).
- Regarding search – if it’s easy to hide it, hide it. If it’s integrated into graphics, make it not work (remove the form). It’s rarely used, and for a small project it’s generally unnecessary, so, if it’s too complicate it to remove it, just leave it there (and perhaps remove its functionality).
- I wouldn’t worry about RSS feeds in the source code. They’re for people who are so technically aware that they should be able to get a simple message – the project is closed, thus no new information. You have to “digg in” to find feeds on most web sites (they’re not shown on the homepage), so I wouldn’t worry so much. But, if you have links on the sidebar, by all means, remove them. So – don’t worry about RSS feeds in the source code, worry about the “visible” RSS feeds (links to them).
- If the theme has some authors you want to thank – leave those links in place. If the theme has links to casinos and viagra footer in the footer, either change the theme or remove those links, if allowed by theme license (which should be GPL, so, in most cases, it should allow for this).
- Remove most contact phones / emails. Use your judgement. If there is a Twitter link which still works, a Facebook page still in use, leave it there. If there is a physical address, a contact phone or an email address which is likely to be unavailable in the future, remove them, most of the times they’re not useful long after the project has ended. You should use your personal judgement here (I worked on a project which changed most of the contact data; another project changed none of that data).
- Make sure the project looks good enough for a portfolio. It doesn’t have to be perfect, but it also shouldn’t have major flaws. (it’s OK if some things are imperfect, but it shouldn’t have grave errors / lack of functionality / design problems).
- You should consider putting a responsive theme for the web site, prior to making the site in HTML, with three conditions:
- This doesn’t affect the initial project setup, how people remember the original web site.
- It isn’t a very big effort to adapt the new theme.
- The project is still quite important to you.
- Remove pretty much everything which might expire. It is possible to edit things later on, but it’s simpler if you just remove them right now.
- Quickly revisit some pages on the web site. You can’t change everything, but if there are some major blunders in there, try & remove them.
- If the WordPress theme, after all this time, looks bad today (not responsive, the graphics look outdated, the web site doesn’t look good on big/small resolutions), you should consider changing it.
- Create a backup of your WordPress installation (with a FTP program or a plugin) and of your WordPress database (via CPanel / backup plugin)
What software to use to convert from WordPress to HTML?
For transforming a simple web site into a simple HTML file, I found that HTTrack Website Copier » works well enough.
Generally, you should use the software with the original settings, just chnage this option when setting up the project (maximum external depth = 0, so that it only caches the current web site, not others)):
There are other solutions:
- Linux / Windows: GNU Wget.
- Mac OS: Homebrew.
- Mac OS: SiteSucker.
- Windows (premium): A1 Website Download.
- Windows (premium): PageNest.
- Others: Free Web Site Downloaders.
- You can try a search for WordPress plugin with the same functionality », but they didn’t work for me.
What’s HTTrack’s weakness?
I would have preferred that the links within the program were not:
site.com/index.html (for homepage) and
site.com/internal-article/index.html (for an article), but, instead:
Of course, I can visit
and they will load, but the links point to /index.html, so this is a bit of a weakness.
What’s the (partial) solution to the weakness?
If you want to redirect site.com/index.html to site.com, you can add the following code to the .httaccess file:
# redirect html pages to the root domain
RewriteRule ^index.html$ http://site.com/ [NC,R,L]
The code will only work for the homepage. If you need it to work for each page, you need to add it to each page (for large web sites, it takes quite a few time).
Consider using other software if you find the option too complicated.
Or, if the project is not very important, you can consider ignoring the issue, it may possibly generate duplicate content, but it’s not a huge issue.
What to do after you move?
- Verify that 90% of the links and functionality of the old web site work.
- Do another backup, this time of the HTML version.
Note: Also see the Yahoo! Group on which I present similar issues: IMRo. To join, email email@example.com and reply to the confirmation email.