Month: July 2012

wp-config.php and standalone scripts

WordPress plugin architecture is great and it provides developers with a lot of flexibility.  But once in a while one needs to write a standalone script that should use some of WordPress settings.  For example, a script that would have the same database credentials as a WordPress instance.  This sounds simple unless you look at the bottom of the wp-config.php file.  There’s that:

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

That means if you are to include wp-config.php in your standalone script, you’ll get the whole WordPress thing loaded and fired up. On one hand, that’s cool because now you can use WordPress functions and objects. But on the other, it’s not. Sometimes you just need the configuration only.

The work around is trivial.  Modify wp-config.php file like so:

if (!defined('WP_CONFIG_ONLY')) {
    /** Sets up WordPress vars and included files. */
    require_once(ABSPATH . 'wp-settings.php');
}

Now, in your standalone scripts, you can do the following:

define('WP_CONFIG_ONLY', true);
require 'wp-config.php';

And you’ll only get WordPress configuration without any extras. If you don’t define the WP_CONFIG_ONLY constant before loading the wp-config.php, then all will work as before.

wp-config.php and git

If you are storing your WordPress changes in git and then deploy the project between different machines (local, test server, production environment, etc), then you are probably familiar with a problem of wp-config.php file.  WordPress uses it for things like database credentials, which vary from machine to machine.  But you can’t just ignore the file since it’s plays the role in WordPress bootstrap.  The solution that we are using at work is very simple: have an additional configuration file, such as wp-config-local.php, which defines local settings, and which is ignored from git.

Here is how to do this.  First, you need to create the file itself.  Let’s say we want to change the database credentials which WordPress should use on the current machine.  Create a file wp-config-local.php with the following content:

<?php
define('DB_HOST', 'localhost');
define('DB_USER', 'localdev');
define('DB_PASSWORD', 'code15poetry');
define('DB_NAME', 'wp_playground');
?>

Now we need to include the file from the wp-config.php. The local configuration file should be optional, so we only use it on those machines that need it. Here is the code that I’ve added to the top of my wp-config.php:

// Load wp-config-local.php
$localConfig = dirname(__FILE__) 
    . DIRECTORY_SEPARATOR . 'wp-config-local.php';
if (file_exists($localConfig) && is_file($localConfig) 
    && is_readable($localConfig)) {
    require_once $localConfig;
}

If you will have a look at your WordPress website now, it’ll probably be broken. That’s because you are not allowed to redefine constants. We’ve defined that in our wp-config-local.php which loads first, and then they are defined in the wp-config.php as well. We should work around this. For any constant that is defined in wp-config.php and which you want to be able to set from wp-config-local.php, change the line in wp-config.php like so:

// before
// define('DB_USER', 'root');
// after
if (!defined('DB_USER')) { define('DB_USER', 'root'); }

With this, you’ll basically have values in wp-config.php act as defaults. If there is no local configuration, they will be used. Otherwise, the local ones will be utilized.

The last tiny bit that you need to do is add wp-config-local.php to your .gitignore file. That’s it. Now commit, push, and enjoy.

Workaround for Cygwin path issues

A colleague of mine had a problem with his Cygwin setup.  For some reason, he couldn’t just run “mysql” to start his MySQL command-line client.  The error that he was getting back was:

$ mysql
sh.exe: mysql.exe: command not found

Typing the full path to mysql.exe every time is more than annoying.  After searching the web for a bit, I learned that the problem might be with the msys/cygwin terminal, which doesn’t like the backslashes that Windows uses in the PATH variable. I’ve tried a few different variations of setting up the path, but eventually gave up. It just didn’t work.

But since there is more than one way to do it, I solved the problem in a completely different way – an alias.  Just edit the .bashrc file and add the following line:

alias mysql="/c/full/path/to/your/mysql.exe"

Obviously, replace the fake path with the full path to your mysql.exe and restart the terminal.  From now on, every time you type “mysql“, it’ll be like you’ve typed the whole thing again.

P.S.: The same solution is applicable to the other similar problems.

Intermediate Rails: Understanding Models, Views and Controllers

Intermediate Rails: Understanding Models, Views and Controllers

BetterExplained.com better explains the MVC pattern.  The examples are using Ruby on Rails, but that’s irrelevant.  Many other MVC implementations in web frameworks are working in exactly the same manner.  If you are not familiar or not very comfortable with MVC, read the article.  It will make things clearer.