Moving WP to another host without downtime

Yeap, I just moved to another host, this time, I wanted to test BlueHost for a year or maybe 2 years. It’s like a trandition already, that I move hosting every 2 years on average. Which is good, because hosting provider did get busier and upgrade their premium cusotmer than small potato like me.

With so many moving host, I got some experience on moving host wihtout causing downtime. Seriously, just some trick will do. Here are some few steps you’ll need to take. Now this is an advance and cheap but time taking steps, you can always opt for a plugin to do all these though. But I like to get my hand dirty.

Step 1:
Backup (to restore). Essential folder like the theme you use, plugins/, uploads/, oh and .htaccess file.

Step 2:
Go to phpMyAdmin to get the database.

Step 3:
Create/install new WordPress on your new host. Restore all the folders you have from your backup. DO NOT CHANGE YOUR NAME SERVER YET!

Step 4:
Import the database to the new host.

Step 5:
Add the new host name server with your current one.

Domain propagation should take a few hours only. So be caution before you delete your old nameserver. Keep the name server intact first and check www.whois.sc with your domain. Once it stated all 4 name servers, you can start delete the old ones.

Moving around 10 WordPress sites per host migration, these steps become as simple as a symbol barcode scanner for me to point it to an item. However, it is really time taking though. That’s why I did it at my free time :)

Best practice to responsive layout?

I don’t have any idea yet, but I have my set of how to. Especially this talks about screen resolution. Getting from the statistic and all that, may not be that much accurate nowadays, because those general statistic is not YOUR statistic. So I tend to skip that part, and look into the existing statistic.

Most of my sites are 1280×800 resolution above. A very very common screen resolution today. A 14″ – 15″ laptop 16:10 ratio should be this resolution. Well, to be honest, who look at the height (800)? So we can skim the rest ratio for the same size laptop.

That being said, 1280 is the most commonly used resolution. 1024 used to be the common one, but it is still the common one, for netbook. So I can’t really skip this resolution. The rest, well, responsive is here to save the World :D

I divided it into 3 groups, mobile, tablet and desktop.

Size and resolution

So all there need is both fixed and fluid layout to work around all those sizes.

Layouts

So my questions comes along too. With the statistic that keep telling me that mobile users will be keep raising the bar, and laptop/netbook are going to replace desktop computer. Am I the one who question the weight of the sidebar information? A website with sidebar information and some 3 columns footer for example. So when it shrink into mobile size, what is to do with the 3 columns and some sidebar information? Are we still keep pushing information toward users even in small screen? Hmm…

Approach to one-page web in WordPress

One page web design has a little myth: Not dynamic enough. However, it is still possible to be dynamic using WordPress. Recently I found 2 ways to work-around it. 1: Widgetize the content area; 2: Page extract.

1: Widgetize the content are

I think there is no need much explanation on this one. Just create widget for specific area:

Widget

However, widget area doesn’t give you much “Dynamic” impact. The lack of visual editor, the need to use HTML tags and of course uploading an image. It will be a lot of job to start off, though updating is easier. That’s why I discovered another approach, the page extract.

2: Page extract

Time to revisit WP_Query again. Notice that is has pagename=my-page-name ready when query WordPress loop.

<?php
$the_query = new WP_Query('pagename=contact');

while ( $the_query->have_posts() ) : $the_query->the_post();
	echo the_content();
endwhile;

wp_reset_postdata();
?>

There I can query some pages I need on that one page. This can help editing the layout content, I gets all the visual editing, media uploading and etc. Just as per post/page editing. It helps a lot when creating for a client.

On part of the custom menu, it is like normal. I’m using <a name=""></a> approach, so instead of normal drag-and-drop, I go with custom link:
Custom menu

Moving from WordPress to Blogger

Recently I was thinking about cutting my VPS resources. So I thought about moving some leisure blogs to blogger, the free blogging platform that does all maintenance for me :D So here are some steps to work around the exporting and importing tasks.

Step 1

Prepare everything:

Step 2

Exporting WordPress posts. Due to the limited size WordPress2Blogger converter can do (1MB), if you are moving a WordPress blogs with few years of entries, or maybe more than 230 posts, you need to export them in batches, to make sure the file size is less than 1MB.
WordPress exporting

Step 3

Converting WordPress XML to Blogger XML. Just go to WordPress2Blogger.appspot.com and convert the file(s).
WordPress2Blogger

Step 4

Importing to Blogger.com.
Blogger import
Blogger importing

That’s all!

Note: There might have some trouble with the converter, make sure the XML you exported from WordPress doesn’t have some weird looking type in there. Well, you can always check it when the converter comes out with error message, check the XML if you see error message.

Mobile first, then the rest

After reading through the slide provided by a commentor, I am more than happy to give it a go right away. So I set the “Mobile first” approach to a theme for simplyWP. Well, not everyone can accept that, so it is best to test out my own thing :D

Octopink theme

Mobile stylesheet was place first, then to a bigger devices then only desktop. I find Google Chrome takes the last one as priority, which is good. Tested in both Firefox as well as Internet Explorer (8 and 9), they all runs pretty well.

Mobile and laptop

One problem came in was the media queries in Internet Explorer. IE6 doesn’t take it at all, instead, it takes the first one to show, which is the mobile version (where I will hide the NivoSlider). IE7 doesn’t take media queries well too. A little Google-it, I get MediaQueries.js, where it will enable IE to support the media queries.

The reason I put media queries at header instead of stylesheet is that IE doesn’t work well with it, even with the jQuery plugin.

This is one happy test, and I’m sure there will be more to explore.