Installing WordPress locally

2 Views

I’m working on a new WP site. The WordPress installation has already been done on a live server by the ISP and now I need to skin it.

I am wondering if I should bring the site down to my local machine and work off that. Having to upload constantly would be rather annoying.

Read More

I’m a little concerned that I will screw soemthing up. Or… that, even if the local installation goes smoothly, when I re-upload to the live server there will be some conflicts.

So what exactly are the steps once I’ve downloaded everything into a localhost folder?…

create a database in phpMyAdmin?
Do I go to wp-config.php in my browser?
What other files would need to be modified?

I will be using MAMP.

I’m very hazy on the database side of things! Is there any danger that my databse setting would interfere with the live installation? e.g Do they have to have the same name?

I just don’t want to have to approach the ISP guys if I mess up their installation!

Thanks!

Post Views: 2

Related posts

Leave a Reply

4 comments

  1. If the other answers make sense I apologise for how patronising my answer must sound – but if they don’t make sense perhaps my N00B style answer will 🙂

    You can’t mess up the installation of wordpress on your live server if you are simply developing a theme on the localhost installation (a skin is known as a theme when it comes to wordpress)

    Once you have developed the theme on localhost you then Zip the theme up and upload it through the themes management menu in your live wordpress installation. There are other ways to do it, but I find this way far easier and less prone to user errors.

    BUT – you don’t do it by downloading everything from your live site to localhost

    try reading this page http://codex.wordpress.org/Installing_WordPress_Locally_on_Your_Mac_With_MAMP

    or google “install wordpress locally MAMP“

    This should walk you through the steps to install it

    Creating the theme you want – that’s a whole other kettle of fish, but again try using google to look for some tutorials to help you walk through it – or find a theme that you love that someone else has already created

    Hope this helps even if only a little

  2. I’ll share one or two things that have made my local development of WordPress sites make a smooth transition to a live server.

    The first is to have common database names, usernames, and passwords between your local and remote servers. There are fewer config settings to change when you move between them and fewer lines to modify in your sql import/export files.

    Second, I would remove any unused theme folders from your install to reduce the size of beast you’ll be moving. The same concern exists for images. Is this an existing site with an entire media library? Or can you work with a slimmed down version of it?

    Third, read this article about moving WordPress published on the Codex. http://codex.wordpress.org/Moving_WordPress. It will tell you everything you need to know about site names and the process of moving the installation. It focuses mostly on moving from one host to another and moving an install around on a server, but it might help familiarize you with possible issues.

    Fourth, My experience of local development was IMMENSELY eased after I learned Mercurial and used it to track and activate changes in the code. It’s a small endeavor, but it’s changed the way I code.

  3. One thing that can help is to set up your local test environment as closely as possible to the production environment (same domain name, database name/login, etc). Use your hosts file to switch between your development environment and production.

    I use a Mac utility named Hoster to help manage switching the hosts entries. With it, I can create ‘dev’ and ‘qa’ settings groups, so that when I enable ‘dev’, then ‘foo.example.com’ points to my local development environment, or I can switch that off and enable ‘qa’ to point to our Quality Assurance testing box. Or I turn them both off to let normal DNS take over and get to the production machines.

    The main tricky thing is remembering to enable the entries at the right times, and keeping in mind that your machine might take a minute to recognize a change to the hosts entries. In the case of my work, we have some extra code set up so that when we view our dev or qa sites, a red box is overlayed on the web pages telling us that we are viewing either the ‘dev’ or ‘qa’ site. I’ll have to see if I can whip up a plugin for that (the sites we do this on are not WP).

  4. The Codex has some instructions for MAMP and WordPress

    Some general notes:

    • Make sure you use some kind of version control (SVN, git or Mercurial)
    • I generally use the same database name, but do change the password, for security
    • Take a copy of the production site and the production database

    • Use the WP_HOME and WP_SITEURL defines in your wp-config.php to set your local testing domain: I will typically have the following 2 lines in my wp-config.php, which mean I can take a database dump from production without needing to change (mostly) URLs contained in it.

      define(’WP_HOME’,'http://sitename.local’);
define(’WP_SITEURL’,'http://sitename.local’);

    • If you’re just skinning, then you should have no need to move your local database to production – you’ll just be working in a theme.

    • Did I mention using version control? The reassurance you’ll have knowing you’ll always be able to revert to previous working versions of code is essential – I find it hard to do any development without having my files in git.