I recently redid the website of the non-profit for which I work. The original site was HTML/CSS, but the Executive Director wanted it redone in WordPress, since she has a WP blog and is familiar with the interface. I knew very little about the inner workings of WP, but have “learned by doing” these last many weeks. I didn’t even know when I started that there are really two WordPresses; wordpress.com, on which you’re reading this blog; and wordpress.org, where the non-profit’s website was developed. (You can view the site at www.lcnlit.org) .
(For those of you unfamiliar with the two WordPresses, wordpress.com is a site where your blog is hosted for free. Your domain name is generated by wordpress and has wordpress.com in the URL, as you can see if you look at the URL of this blog post you are currently viewing. You can upgrade and get your own domain name and increased control over the look of your site for $99/year. wordpress.org is the site you should use if you want to do a WP site with a domain name and/or server that you are already paying for. You have unlimited control over the look and feel of your site there.)
Using WP as a CMS for a static site is not without its issues. Even though it’s a very powerful platform, it was and still is geared towards blog sites, not static sites. Things like comments and their handling, post archives/categories/tags, and the like are not things that I needed too much for a static site. I actually ended up making the home page of http://www.lcnlit.org a series of three posts, not a wp page, so that I could get the look that I wanted. I stripped the posts of metadata (author, date and time) to make them look like parts of a static page rather than posts, but under the hood, they’re still posts. For those developers used to making changes to the HTML, using WP as a CMS requires some adjustment. A good deal of the HTML used to generate a wp page or post is pulled from the site database using PHP. Tracking down something that you need to change on the site is much more difficult when you can’t go directly to the HTML and change it yourself–Chrome Developer Tools or Firebug for Firefox can tell you where in the generated HTML file something resides, but NOT which PHP file generated that HTML or where in that PHP file you need to make the change.
Here are some things you need to check if you are moving your WP.org site from one server to another. In my case, I moved the site from a local development site on my computer to our live server, but I would imagine some of these things need to be checked if you’re moving from one server to another as well.
(1) MENU LINKS:
Before you port the site, go into the general settings and change the WordPress address and site URL to your new URL. This will update most of the necessary links in your site. After porting the site, check the links back to your home page in your menu(s)–Appearance>Menus>click on the dropdown arrow to the right of your home page’s bar in the menu. Update that link to your new URL.
When I ported the lcn site, all of the pages in the menu linked fine to each other, but when I clicked “home” on the menu, they were looking for the address of the home page on the local development site until I updated the URL to the live site URL manually.
Before you port the site, go to Settings>Permalinks and make sure the links are formatted the way you would like. In my case, I used the custom structure and added “/home” in the text box. This resulted in the permalinks having the structure of “my chosen URL/page slug”. (To view your page’s slug, while on the page editing screen, click “Screen Options” in the upper right corner and make sure that “slug” is checked. The slug will then appear at the bottom of your editing screen).
After you port the site, go back to Permalinks and resave.
I did not have any permalink problems after porting the site, but from what I’ve read on the web, broken permalinks are a big issue when moving a site.
(3) IMAGE LINKS:
All of the image links in my site were messed up by the move; I had to redo every link. Grr.
There is a plugin called Duplicator which is supposed to make moving your site easier, but I didn’t learn about it until after I had moved the site. I hear good things about it.
(4) CHECK YOUR WIDGETS:
I had a link/image in one of my text widgets that had to be totally redone after the move. I don’t think making changes in the General Settings filters down to the widgets, so recheck any links or image links in your widgets after a move.
(5) BE VERY CAREFUL PORTING YOUR WP DATABASE:
The WP database is where all of your site’s information resides. The db name and password can be long and complicated, so check and recheck the accuracy of your information when going between the old and new servers.
(9) CONSIDER WHAT TO DO WITH YOUR PLUGINS:
One of the plugins that I had installed on the site on the local server was quite complex. When I was uploading this particular plugin to the live site, I accidentally deleted a file it had put outside of the Plugins folder which was integral to the plugin’s function. This could have been disastrous, as the lack of this file corrupted the site enough that I couldn’t even get into the wp admin of the site. Fortunately, I realized what had happened and reuploaded the relevant files, and then I could get into the wp admin (phew!) Since our previous live site had been superseded by the wp site, if I hadn’t been able to get back into the admin, our live site would have been a badly corrupted wp site, not a desirable outcome!
If I had this port to do over, I would not have uploaded this complex plugin via FTP. I would have uploaded the site to the live server and then reinstalled the plugin on the live site. This would have been an option for me since I did not have very much data stored in the plugin, but would NOT be a good option if you had a plugin with a lot of data that would need to be replaced, as might happen if you’re porting your site from one live server to another.