messaliberty

about hulor and us

Posts Tagged ‘wordpress’

How to fix WordPress automatic upgrades and plugin installs on XAMPP

April 12th, 2010 post by ianc

If you’ve ever had problems with WordPress automatic updates on a local install of XAMPP this should fix it (note that I’ve tested it on OSX but it should work for Windows/Linux but the details will be different).  For a long time I just did the updates/installs by manually installing because the automatic upgrades never worked or it would ask for my ftp details.  And no matter what ftp details I entered it would never connect.  Same for plugin installs or updates.

Turns out that it has nothing to do with ftp settings, it was a simple file permissions conflict.  XAMPP was running its local Apache as user ‘nobody’ while the files on my hard disk were owned by my local user ‘ian’.  When WordPress came across this conflict it fell back to ftp mode but since it is a local install, that didn’t work.

So what to do? The easiest thing to do is to edit the XAMPP apache config file to run it as your local user.  To find out your local user name, just launch terminal and in your home directory run:

ls -al

then edit the config file. If you are comfortable with using vi type this:

sudo vi /Applications/XAMPP/etc/httpd.conf

If not you can use the TextEdit app, you need to type this into the terminal:

sudo open -e “/Applications/XAMPP/etc/httpd.conf”

look for these lines:

User nobody
Group admin

and change them to:

User yourusername
Group staff

You’ll have to restart XAMPP’s Apache and if you attempted automatic updates before and failed, you’ll have to delete the upgrades folder inside wp-content.

Hope this helps other WordPress designers and developers using XAMPP. Please leave a comment or have a look at messa.tv if it did :)

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…)