This past Monday I was lucky to have the opportunity of giving a talk at the Boston WordPress Meetup. This was my first time giving a talk of this nature, and overall it was a fun experience. I enjoy talking about controversial topics within the WordPress community, and migrating WordPress can definitely be one of those topics. The reason being that there are many different methods of doing it, and each have their pros and cons.
A lot of the feedback and conversation I had with attendees during the presentation was that there are plugins available to do some or all of the steps I performed manually in my live demo. And I can appreciate that, because everyone is at a different level with their WordPress skills, or willingness to get down and dirty in the database to do some rearranging (which can be scary at times!).
My fear with plugins however, is this: They won’t serve 100% of the purpose 100% of the time. Even the best of plugin developers can’t account for all configurations of hosting and databases, though I do give kudos for taking on such a big task. The other issue is that some plugin developers stop supporting their plugins after a while, especially free ones. Sometimes that’s ok if it’s a simple plugin that doesn’t rely on too much, but something like migrating WordPress would depend greatly on WordPress Core. And with even the slightest change in a new version, the plugin could instantly become a digital paperweight.
The benefit of migrating a site by hand however is that it applies to all hosting. As with many things WordPress, you’ll run into variations depending on your hosting environment, Core version, plugins, etc. But with a little knowledge and practice you can easily get around those types of things, and not need to rely on plugins or paid services in the process. A fellow WordPress enthusiast said it best: “I can build a career off of experience, I can’t build a career off of someone’s plugin.” Well said sir!
One thing I wanted to be sure of addressing here is the issue I ran into with importing the .SQL file during the live demo. The strange thing is that it worked properly that morning, but not when I needed it to… just my luck! Anyways, once I changed over all of the URLs in the .SQL file to the new structure, some of the theme options didn’t carry over. This is because some themes and widgets store info as serialized data and don’t use the URL in the .SQL file. A fix to this (as quoted from the Moving WordPress Codex page) is:
- Only perform a search and replace on the wp_posts table.
- Use the Search and Replace for WordPress Databases Script to safely change all instances. (If you are a developer, use this option. It is a one step process as opposed to the 15-step procedure)
I’m glad I had the opportunity to present at the meetup and look forward to doing it again soon. It’s always nice to get feedback from the crowd, and I intend on tweaking the sticky points before presenting on the topic again at a future WordPress Meetup.
Did you attend the talk on Monday? Please take a moment and rate me on SpeakerRate. I’m also always open to feedback and suggestions on how to make my presentations better. Just drop me a line. Thanks!