messaliberty

about hulor and us

Posts Tagged ‘wordpress’

How to create a single wp-config file for local and remote WordPress development

January 28th, 2010 post by ianc

If you are developing WordPress sites, themes or plugins, you probably know that setting up a local development environment can speed things up immensely. The easiest way is to use XAMPP or MAMP. I prefer XAMPP by the way as it is available on Windows, Mac OSX and Linux.  Installing XAMPP gets you most of the way to headache free WordPress development, the rest is setting up your local server/virtual servers so that it as closely mirrors your remote set-up as possible.

However, some settings like blog address are held in the database which makes mirroring local development and remote production servers a little tricky. If you just backed up the database on the remote set-up and imported it to your local XAMPP server through phpMyAdmin then WordPress will still think that it is at http://www.wordpressblog.com and not http://localhost

Permalinks might not work, plugins might break and so on.

What you need to do is either edit the database, searching and replacing the relevant fields or edit the wp-config.php file to override the database settings. I don’t recommend the first option as it is error-prone and you have to do it again if you throw the database in the opposite direction.

Editing the wp-config.php file is relatively easy, just add the lines

	define('WP_SITEURL', "http://localhost");
	define('WP_HOME', "http://localhost");

but if you edit the wp-config.php file you will have two different versions of the file.  This will cause your site to break if you absent-mindedly uploaded your local wp-config.php to the remote server.  If you are using source control, like git or svn, and forget to exclude the file the same thing happens.  Plus you have to maintain two versions.

Here’s what I do. I set-up the wp-config.php to check to see if it is a local server, if it is then set the configuration one way, otherwise set it using the production values.

The first 3 settings are the same whether local or remote.  In some cases the MySQL hostname will be different, so just set it later with the others.

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wordpressdb');

/** MySQL database username */
define('DB_USER', 'wpdbuser');

/** MySQL hostname */
define('DB_HOST', 'localhost');

We’ve moved the 4th setting, the password, because it is different. And we will add the ‘WP_SITEURL’ and ‘WP_HOME’ settings later to override the database values. But first two more settings that are the same whether local or remote.

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

Ok, now the fun starts. These five lines checks to see if the server’s address is 127.0.0.1 If it is, we assume it is a local machine and set a WP_ENV to development, otherwise we set it to production.

if ($_SERVER['REMOTE_ADDR']=='127.0.0.1') {
	define('WP_ENV', 'development');
} else {
	define('WP_ENV', 'production');
}

Having determined whether the environment is local or remote, we then grab the site address for use with ‘WP_SITEURL’ and ‘WP_HOME’.  I don’t hardcode it in as it gives me the flexibility to re-use it for any virtual server.

$debian_server  = preg_replace ('/:.*/',"", $_SERVER['HTTP_HOST']); $_SERVER['HTTP_HOST']);

Finally in these lines, if it is the local development, we set a simple dummy password and disable post revisions. We also set WP_DEBUG to false, this allows us to set it to true if we come across any tricky problems.

If it is the real production server then we set the password to its original value which should be a long and random set of characters.

if ( WP_ENV == 'development' ) {
	define('DB_PASSWORD', 'short_dummy_password');

	define ('WP_POST_REVISIONS', false);
	define ('WP_DEBUG', false);

	define('WP_SITEURL', "http://$debian_server");
	define('WP_HOME', "http://$debian_server");
} elseif ( WP_ENV == 'production' ) {
	define('DB_PASSWORD', 'the_real_password_which_is_a_very_long_and_random_string');
}

This wp-config.php file is now safe to be used on the remote production server or on your local development server.

One note, we didn’t set the WP_SITEURL and WP_HOME on the production server instead using the values in the database.  But if we moved a site from one domain to another we could do so.

If you have any questions, feel free to ask me in the comments.

Next WordBench Osaka at messaliberty

December 18th, 2009 post by hiro

WordPress studying session WordBench will be held at messaliberty. Please join if you’re in Kansai area!

See more detail here: WordBench 大阪 » Blog Archive » 2010年新年会を1月31日(日)開催

Localizing dates in WordPress themes

December 15th, 2009 post by ianc
cal2

Ken's stuck in time calendar

Our theme on the English side and the Japanese side are the same.  And by that I mean, we only have one copy of the theme files that is used for both sides.  For this to work, it has to be  fully localised and independant. One thing that is quite different in the two languages is the formatting of dates.  A date like Dec 13th 2009 might be formatted as 2009年12月13日

Chapp worked from a theme that had the date formats hard coded into the theme.  As in:

<?php the_time('F jS, Y'); ?>

If we left that in, the Japanese side’s dates wouldn’t be right, but if we took out the ‘F jS, Y’ part, it defaulted to outputting the time.  As a workaround, we used:

<?php the_date(); ?>

which does fetch and use the right formatted date on both sides.  Yay! But… when WordPress generated archive pages, we found an unexpected behaviour of date().  It only outputs a certain date once.  So if two posts were written on the same day, only one post would have the date.  I think somewhere in the theme there is an ugly workaround involving an array.  But this is a better approach:

<?php the_time(get_option('date_format')); ?>

What this is doing is fetching the date format string that is set in Settings > General > Date Format and using that.  Which for the record is F jS, Y on the English side, and Y年n月j日 on the Japanese side.  I know it may sound obvious but at the time it had us scratching our collective heads.

And while not many installations will be using the same set of theme files for two or more languages at the same time (except for WordPress MU themes), localizing the theme this way lets you or your users to just set the date format in the General Settings screen.

Thoughts on the GPL and WordPress themes

October 26th, 2009 post by ianc

gnu_gpl_logo

Why the GPL doesn’t matter

WordCamp Kyoto 2009 was a great experience. One presentation by Digital Cube provoked a discussion about GPL amongst a small group of attendees, myself included.

The major worry about releasing themes or plugins as GPL is that after all the work and effort at producing it, someone you sell it to is going to turn around and re-release it either at a discount or for free. Leaving you, the original developer, feeling cheated.

The GPL definitely allows this. But it doesn’t much matter if you understand the concept of competitive advantage. Let me explain:

(more…)

Multi-lingual WordPress Admin Screens

May 8th, 2009 post by ianc

As mentioned in messa.tv episode 004 we have set-up multi-lingual admin screens in WordPress.  It means that each user can choose to have the admin interface in their own language.  You can’t believe how useful this is in a multi-lingual company such as ours and how long I’ve searched for the solution.

We used a plugin called tam-mothertongue written by Miyoshi-san.  It didn’t work for WordPress 2.7 but Miyoshi-san sent me a quick fix that got it working.  And now he’s released an updated version and renamed it bogo (which is mothertongue in Japanese). Please help spread the word about this wonderful and useful plugin by blogging about it in your own language.

You can find his announcement post about the bogo plugin here.

Get Adobe Flash playerPlugin by wpburn.com wordpress themes