Powered by dead dinosaurs

Tag: Wordpress

Moving a WordPress Site to a New Server

I recently had to install a copy of my wordpress site on localhost so I could test an upgrade without risking my live site. I used to do this a lot, but I’d forgotten the steps, so after I figured it out (again), I thought I should write it down…

Before starting: I moved my site to localhost. I run PHP/MySQL on localhost with XAMPP. I’m not going to provide a lot of details on every step. If you don’t know how to use XAMPP or phpMyAdmin, you’ll need to figure that out.

Step 1: Back everything up! Download all of your live site files to a local folder. Also, export your database. I export my database from the live site’s phpMyAdmin. Save the site files and database export somewhere that you won’t touch it. This is your fail-safe, just in case something really bad happens.

Step 2: Download all of your site files again. Yes, you COULD copy them from step 1, but that violates the principle of not touching your backup, so I don’t recommend it.

Step 3: Export your live site database again. You can copy your export from Step 1, but I think it’s a bad idea.

Step 4: Copy all of your site files to the new server. In my case, I created a wp_test folder in localhost/htdocs and pasted them in there.

Step 5: Open the wp-config.php file in in a code editor. It has info you’ll need for the next steps.

Step 6: Create a database on the new server. I did this through phpMyAdmin on localhost. This will be easier if you can give the new database the same name as the original (refer to DB_NAME in your wp-config file). If that’s not possible, don’t sweat it.

Step 7: Create a user for the new database. If possible, reuse the same user name and password as the old site (DB_USER and DB_PASSWORD in wp-config). Again, if your server won’t let you use these values, it’s no big deal. Generally, the hostname should be set to localhost. Since I was doing this on localhost, I gave the user full privileges, but if you’re moving it to another domain, you may need to be more careful about the privileges on your user. You can check the user account on the live site to see what permissions the user should have.

Step 8: Import the file from Step 3 into your new database.

Step 9: You need to open your wp_options table in the new database and modify the following entries:

  • site_url: change it to your new url. In my case: http://localhost/wp_test
  • home: same value as site_url

Step 10: If you were able to reuse your database and user info, you should be able to go to the site now. If you had to use a different user or database, change the values in your wp-config file to match the new values.

Step 11: You may need to fix some folder permissions tor things like image uploads to work correctly. Again, check the live site folder permissions for reference. NEVER use 777 permissions. 755 permissions should be what you need. That should do it! Check that you can click around your site and go to the admin panel. Things to watch out for:

  • Error establishing a database connection – means that your credentials in wp-config don’t match your actual user OR your MySQL server isn’t actually running.
  • 404s on the pages – see this post.
  • Pay attention to the URLs of the pages and admin panel. If you didn’t do step 9 correctly, it might direct you back to your original live site. It’s important to make sure you’re not on the live site before making changes.

Let me know if I missed anything important in the comments!

Kenny Login is Available Now!

Kenny Login version 1.0.0 releasedAfter months of procrastination and delays, I’m proud to officially release Kenny Login – a fully responsive HTML5 theme for your WordPress Login page. Version 1.0.0 is available now as a free WordPress plugin. Simply install the plugin and activate it through your admin panel. Blam! Kenny Loggins all up in your login page! Click here to get the lowdown.

Log in to the Danger Zone!

SOLVED: WordPress pages 404 Error on new server

I ran into this problem recently when moving a client’s WordPress site to a new server. On the old server, all of the pages had permalinks set up and they worked great. After moving the site, none of the pages were working, except the home page. All of the other pages gave me a 404 error. The admin pages worked fine.

When diagnosing this issue, you need to check a few things. First, check that your admin panel is still working when you log in. If not, you may have a problem with your base urls in the database. To check this, log into your phpmyadmin panel and check the wp_options table in the database. There are 2 entries that contain the site url. Make sure that they are correct.

Assuming that your admin panel is working, the issue is probably a server setting causing a problem with the Permalinks. To check this, go to the Settings>Permalinks page and change the setting to Default. Now, go back to your homepage and see if your pages are working. The permalinks will NOT work, but you should be able to click around using the navigation.

If your pages now work, then the problem is that mod_rewrite is not enabled correctly on the new server. If you want to check this, simply create a new htaccess file with the following code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wp/
RewriteRule ^test\.html http://www.google.com [QSA,L]
</IfModule>

*note that your RewriteBase will be different than mine.

Now, go to your WordPress site and try to navigate to test.html. It should redirect you to the Google. If not, then mod_rewrite is definitely not working and you need to have your server admin or hosting company fix it.

I found a lot of people with the same issue when I was trying to fix this, but no one seemed to have a solution. Hopefully, this will help.

Querying the wordpress database with $wpdb from PHP

I have been working with WordPress a lot lately and I really like it. I want to have 10,000 of it’s babies. I recently needed to access the database using the $wpdb class that is built in to wordpress, but my PHP file was not part of the wordpress core, so $wpdb wasn’t automatically available. It’s really useful for accessing info like the root URL of your site (stored in the wp_options table). If you are creating a plugin or custom feature and need access to the database, it can be hard to figure how to enable the $wpdb class in your PHP files. Luckily, the code is actually not that complicated. The first thing you have to do is include the necessary files at the top of your custom php file:

include_once '/wp-load.php';
//var_dump($wpdb);
//$wpdb is now accessible!

If you uncomment the var_dump line in the code above and run this php file, it should spit out a lot of information. If it doesn’t, then you aren’t including the wp-load.php file correctly. You must have WordPress 3.0 or higher installed and your PHP file must be installed somewhere in the same directory as WordPress. You can also use a relative path if you need to:

include_once '../../../wp-load.php';
//var_dump($wpdb);
//$wpdb is now accessible!

Just make sure you have your relative path correct. It may be different, depending on where your PHP file is located in your wordpress installation.

Now that you have the $wpdb class enabled, you can query the database. Going back to my example above, if you need to retrieve your site URL, you could add the following lines to the PHP file we just created:

$table_name = $wpdb->prefix . "options";
$sql = "SELECT option_value FROM ".$table_name." WHERE option_name = 'siteurl';";
$root_url = $wpdb->get_var($sql);

This uses the get_var() function of $wpdb to return a single item (your site url) from the wp_options table. Notice that on the first line, I also used the $wpdb->prefix property, which in almost all cases, will be “wp_”.

What if you wanted to run a mySQL query on a table? That’s simple too! just use the query() method of $wpdb. For example, we can insert values into a custom table that we created for a plugin:

$table_name = $wpdb->prefix . "my_custom_table";

$sql = "INSERT INTO ".$table_name." (
	        field_1,
                field_2
              ) VALUES (
                'some value',
                'some other value'
              )";
$result = $wpdb->query($sql) or die(mysql_error());
//do something with the result here

You can even do more complex things, like create the tables you need for a plugin. The following function runs a mySQL query to create a table for a plugin:

function create_my_custom_table() {
    global $wpdb;
    $table_name = $wpdb->prefix . "my_custom_table";
    global $my_custom_db_table_version;
    $installed_ver = get_option( "my_custom_db_table_version" );
    //Check if the table already exists and if the table is up to date, if not create it
    if($wpdb->get_var("SHOW TABLES LIKE '$table_name'") != $table_name || $installed_ver != $my_custom_db_table_version ) {
        $sql = "CREATE TABLE " . $table_name . " (
              id mediumint(9) NOT NULL AUTO_INCREMENT,
              field_1 varchar(100),
              field_2 varchar(100),
              UNIQUE KEY id (id)
            );";

        require_once(ABSPATH . 'wp-admin/includes/upgrade.php');
	dbDelta($sql);
        update_option( "my_custom_db_table_version", $my_custom_db_table_version );
    }
    //Add database table versions to options
    add_option("my_custom_db_table_version", $my_custom_db_table_version);
}

The code above is actually a function that will check the wp_options table for a field called “my_custom_db_table_version.” If it exists, it compares the value to a global variable $my_custom_db_table_version. If there is a newer version of the table or if the version can’t be found in the database, it creates/updates the custom table.

As with most things, wordpress makes it easier once you know the basic code. Good Luck!

Powered by WordPress & Theme by Anders Norén