Pulling from Git to WordPress and Desktop Server

1 Views

I’m having problems keeping consistent versions of a repository on different local machines, and pushing and pulling effectively.

When I worked with Rails, I could push and pull easily and all the files required to start a Rails server were included.

Read More

With WordPress, I have to include files like wp-config.php in .gitignore so when I pull the repository to a new computer, I cannot start a local server (through Desktop Server). I did try manually transferring wp-config because that wasn’t too inconvenient, but then a database error followed and I need a more complete solution.

How do you transfer entire WP repositories between developers through version control? I want to be able to push and pull, not drag and drop.

(One solution I thought of: Duplicate the WP base, connect the remote repository to the base, then pull and merge the updated site into the base server.)

(Another possible solution: moving the db config and salts lines from wp-config.php into dbsalts.php, then including that file in wp-config.php. I would then add dbsalts.php to .gitignore and remove wp-config, so the big important stuff would be ignored but the reduced wp-config would be pushed. Not sure if this would work, and we’d still have to drag and drop dbsalts.php.)

dbsalts.php 

define( 'DB_NAME', ..... (redacted code for security)
...........................

define('AUTH_KEY'......         
..........................

wp-config.php 

include(dbsalts.php);

Currently using wpengine and desktop server, but I’m just now implementing this and open to suggestions.

Post Views: 1

Related posts

3 comments

  1. *Private BitBucket Git Repository – While most of the time the only truly sensitive information in a WordPress install is in the wp-config file, which is preferable not to include in Git repository, keep whole sites in private repos, which are free from Bitbucket. Open-sourcing your entire site might make sense, but it’s something to think through thoroughly before doing so, and erring on the side of caution is a good policy, especially when doing client work.

    *WP Migrate DB Pro – While Git can keep all of the site’s files in sync between environments, a different tool is required for keeping the MySQL databses in sync. WP Migrate DB Pro is an excellent plugin that automates this process.

  2. Even if you get this to work you are going to have further problems with the database. 2 developers working on 2 different local WordPress sites can create a number of issues with data in the database.

    Here’s an example suppose both of you pull the site that has the following posts in the database: A, B, C.
    Now you make a new post: ‘D1’ and the other developer make a different post: ‘D2’. This will associate D1 and D2 with the same post ID (since D1 isn’t at the second developer’s WordPress database, the same is true for D2).

    What you could do (in theory), is set up both machines to connect to the same remote database (you’ll have to white-list both of your IP address, if they are different, for that particular install with WPEngine’s support). You’ll need to modify the local wp-config.php, which I believe will make it different from the one on the server, but that’s okay, since you can include it in gitignore.

    Now you might can both pull and push to the server without an issue. But I’d use BitBucket or GitHub and have only one of you pushing to the server. I’d also look at DeployBot.com at some point. It can push the code from BitBucket/GitHub to WPEngine’s server through ftp automatically.

  3. I use local configs based on the url by adding the following to wp-config.php:

    $site_options_filename = dirname(__FILE__) . '/options-' . $_SERVER['SERVER_NAME'] . '.php';

if (!file_exists($site_options_filename)) {
    die('missing config: ' . $site_options_filename);
}

    This will look for a specific config file based on the domain you are viewing. I use a dev. prefix or similar for my local builds.

    I also use a quick bash script to dump the db to a .sql file which I include in the commit whenever there are database changes that have to be propagated:

    mysqldump -uyour_db_username -pyour_db_password --add-drop-table --create-options your_database_name  > dump.sql

    It’s a simple task to run dump.sql against the database every time you pull and dump.sql has changed.

Comments are closed.