Migrating to your own WordPress.org account – things that will suck and how to avoid them

I’ve recently been in the process of migrating my blog off of WordPress.com hosting to my own WordPress.org account.  I tried a few things, a number of which did not work well, and I hope to help you avoid them if you try the same thing too.

After installing WordPress on a localhost / Linux LAMP setup (Linux Apache MySql PhP) you’re prompted for credentials when uploading content or plugins

This one is super annoying.  You’ll basically see a message like this whenever you try to install a new plug-in, and have to put in your  Linux credentials.

Whoa whoa whoa, contact my host?  I am the host.  Uh-oh.
Whoa whoa whoa, contact my host? I am the host. Uh-oh.

–Whats going wrong

What happens here is that if you follow the instructions in this page for setting up WordPress on a LAMP stack, you’ll end up with WordPress installed to /var/www and all of the files and folders there owned by your user account.  This means that when you try to upload files, Apache, the Linux Web Service, which runs with the user account www-data will not have any permission to this path.  Hence the prompt for credentials.

–How to fix it

This is simple.  In your Linux/Ubuntu system, open terminal.  If you’ve got an Azure Ubuntu VM like me, connect via SSH using Putty.

CD to your WordPress directory, most likely /var/www

Run the following commands


chown www-data *
chown www-data */*
chown www-data */*/*

Thanks to fkoosna for this answer.

You setup an Azure WordPress Website using the quick create option from the Azure Store and WPAdmin / Dashboard and page loads are slow

This one really stinks. You’ll get eight or nine second pages loads (shoot for under two!) and doing work to your site is a slog, because the page loads so slowly.

When you setup an Azure WordPress site using quick create from the Azure store, you’ll end up with a ‘shared’ website, meaning that your WordPress instance runs alongside other sites competing for resources.  You also generally have very little control over the site, as you’re using Platform as a Service (PaaS).

–What’s going wrong

Chances are that one of the other tennants in your shared host is being unruly and has lots of scripts running or other intense server behavior.  Azure will attempt to quash bad activity like that, but in the end can only do so much.  When you’re ready to move to the big leagues and have dedicated hosting for your site…

–How to fix it

The simple fix to this issue is to simply upgrade your instance to a Basic or Standard instance, which moves you into infrastructure as a service (IaaS) in which you now have a VM you can work with and tweak.

Login to the Azure portal and click on Web Sites, then click your desired site and choose Scale

 

blog_UpgradingToBasicInstance

On this page, keep in mind your budget.  As soon as we click from Free/Shared and move up to Basic, we’re talking about a full VM tier here.  This can run about $35 bucks a month.  That’s more than twenty dollars (which is my ‘uh, maybe I should pay attention to this‘ threshold).  If you’re on a totally free account, you’ll have to remove the spending limit, or you’ll basically have a VM immediately turn off and not work anymore.  Goodbye website.

blog_UpgradingToBasicInstance1

 

On this page, we can also configure Autoscaling, if we want to allow our site to scale up and out as needed.  Keep in mind that you’ll have to do a bit of work to make this function.  Azure can’t magically code-in scale-out support for you.

When setting up additional Azure websites after scaling up the WordPress installer does not launch

This one took me a while to figure out.  I was creating blog sites for my wife, and in the process of spinning one up in the Azure portal, I would point them to an existing MySql (or SQL Server, if you’re using Brandoo WordPress) db, expecting to colocate all of my blogs in one instance of SQL that I keep clean.

I'm creating this little guy just for you
I’m creating this little guy just for you

So, I’m making a new WordPress site just to show this to you.

Alright, lets see if it happens again.
Alright, lets see if it happens again.

The site is built, let’s see what happens when I go to the URL.

Um, shouldn't there be something here?
Um, shouldn’t there be something here?

–What’s going wrong?  

The first time that a WordPress instance is created, it will attempt to connect to and use MySQL and initiate a few tables, things like that.  However, if another blog has already been setup before and has permissions and data in those tables, the WordPress install will stall out!  Specifically, there is a setting we need to change to allow our WordPress installer to spin up some new tables in our existing MySQL DB.

–How to fix it?

This was one I never would have solved if not for this blog post (insert link here later when I find it!).  We need to edit the wp-config.php file, which has a number of useful settings we can change to help shape and control the way that WordPress runs.  We need to address line 65 on this file, $dbPrefix, because our first blog instance is already using that prefix, preventing the installer from running.

Assuming you’re using Azure Websites, we’ll use the very, very very useful Webmatrix tool to work with an online copy of our site.  From the Website window, click WebMatrix

blog_WhatIsWrongWithThis3

Now, choose Edit Live Site Directly.

blog_WhatIsWrongWithThis4

This gives us a nice way to upload files without resorting to FTP, and can be used to backup your site as well!  You can even run the site off of your laptop or PC if you choose to ‘Edit Local Copy’. We need to edit the wp-config.php file, which executes and sets up our blog for us by running the WordPress installer.

Skip down to about line 62, and look for the line beginning

$table_prefix = 'wp_';

 

Change this prefix to be anything else in the world, and you’re set!

I'm changing it to 'GuineaPig_'
I’m changing it to ‘GuineaPig_’

Hit Control+S to save the change…

blog_WhatIsWrongWithThis6

then hit F5 in your browser

blog_WhatIsWrongWithThis7

But wait, there’s more!

I’m still not done with my migration.  I’ll let you know if I run into any other really fun problems that destroy my blog along the way.  I’ll tell you that deciding to move to my own hosting opened up a huge can of worms with regards to minifying CSS and JavaScript, and suddenly worrying about PageSpeed and things like that.  I’m not certain yet if I’ll continue trying to host my own site, but the learning alone has been worth it.

Advertisements

2 thoughts on “Migrating to your own WordPress.org account – things that will suck and how to avoid them

  1. Casey February 26, 2015 / 6:53 pm

    For file ownership in a Linux system, rather than doing a bunch of commands, it’s probably easier to just do this:
    # chown -R www-data:root /path/to/files
    In this case, R = recursive, www-data:root = User:Group, so give ownership to www-data user, and anyone in the root group. That is what I’ve done in the past. Main point is the -R flag.

  2. Tom March 12, 2015 / 3:49 pm

    Wow. That must be much more involved than ours. We rented a server which does the hosting for us, and that proved to be a life-saver. Can’t imagine what it is to be running a truly self-hosted website!

Have a code issue? Share your code by going to Gist.github.com and pasting your code there, then post the link here!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s