I’ve elaborated a bit more on Sean’s piece mainly on the installation, so even if you’re not that experienced you should be able to follow along. Also read Sean’s article as it contains a more sophisticated solution as well!

Preamble
I use Linux on my development machines, but I suppose it should work with any Unixish type of OS, such as OS X or *BSD. Probably doesn’t work on Windows (leave a comment for a Windows based solution).

1. Ok, first put the following line in a file called ‘logmail’ (without the quotes!):
   cat >> /tmp/test-emails-sent.log
2. Save the file somewhere you can find it back In my case, like Sean, I’ve used /usr/local/bin as the directory for this file.
3. Then make sure it has execute rights. You may set it by typing in: chmod +x /usr/local/bin/logmail
4. Finally if you use PHP you need to change the sendmail_path variable in your php.ini. In my case (I’m using Ubuntu 11.04 and 11.10) I’ve added a file called mail.ini to the /etc/php5/conf.d directory with the following line:
   sendmail_path=/usr/local/bin/logmail
5. Restart Apache by typing sudo service apache2 restart
6. Test your application’s mail sending capabilities by looking at the test-emails-sent.log in your /tmp directory

Deploying WordPress from a local machine to another location such as a testserver is annoying, because there is no easy way to export and import settings (although menu’s and other content can be exported and imported!). WordPress saves configuration options in the database and often these settings are part of serialized arrays (see Serialization) . Making it hard to change these by hand or using a deployment script. Imagine working with multiple developers, several plugins and it becomes a real pain in the ass to keep track of configuration changes.

Some problems are more or less solved for the single WordPress install: moving a single WordPress installation is a lot easier than a WordPress Multisite installation. Using certain constants in the wp-config.php file, such as WP_SITEURL or RELOCATE, you may alter the domain name used to access the WordPress installation. Et voila the installation has been moved!

Keep in mind though, all other settings have not been automagically altered. So you still need to change these, but at least for a single WordPress install there are some constants to help you out. Such constants are, as far as I know, not available in a WordPress Multisite installation and we still have the issues with all the other settings which need to be changed. Basically WordPress at the moment lacks a good approach for dealing with multiple installations and sharing settings.

Therefor my current approach towards development with multiple developers on WordPress Multisite uses database dumps and a simple search-replace. This is a bit ‘hackish’ and certainly not a magic silver bullet, but it at least makes developing with multiple developers a bit easier.

Assumptions

• The WordPress Multisite installation uses subdirectories for the seperate sites.
• There are at least two WordPress Multisite installations. One locally on the developer’s machine and one on a common test server. Both use a domain name and extension, which has the exact amount of characters regardless of it being locally installed or on a test server.

For instance I’ve started to use the following scheme:

• http://domain.mine for my local test installation on my laptop
• http://domain.test for a test server which we use with multiple developers

It doesn’t matter what the domain names and extensions are as long as you are using the exact same amount of characters for both. This ‘fixes’ the issue with settings being tied to a domain name in a serialized array. Due to the nature of serialized arrays, changes in the length or type of the new value will affect the serialized array. By keeping the amount of characters used in the domain name and extension exactly the same we prevent any issues with the length or type. Now I can dump the test server’s database, search ‘domain.test’, replace it with ‘domain.mine’ and use this on my local machine.

For the search and replace I use sed, a nice little Unix commandline tool which makes it very easy to do search-and-replaces. Check out this great tutorial on sed by Bruce Barnett, even if you have used sed before. This is the one-liner I use:

sed 's/bnn.test/bnn.mine/g' < database-dump-original.sql > database-dump-renamed.sql

Note: this implies the test server is the leading example for all installations, so be careful with the test server and make regular dumps (I try to do this with every configuration change).

Although this approach does not solve deployment on a production or live server, keeping track of configuration changes during development is made a bit easier.

I’m using a ReplaceRegexp filter to change WordPress’ wp-config.php file. In this file a constant WP_DEBUG is defined false and I would to change it to true. I have defined the regex and provided a property with a string “true”. However this string will be casted to a bool and causes strange sideeffects.

Consider this build.xml example:
<!– setup wp config specific properties –>
<property name=”wp_config.wp_debug” value=”true” />

<!– Setup the wp-config file –>
<!– thanks to http://stackoverflow.com/questions/974963/phing-and-wordpress-configuration –>
<target name=”setup-wp-config” description=”Copies the wp-config-sample.php to wp-config.php and sets up the parameters for the test site”>
<copy file=”./wp-config-sample.php” tofile=”./wp-config.php”>
<filterchain>
<replaceregexp>
<regexp pattern=”(define\(‘WP_DEBUG’, )\w+(\);)” replace=”\1${wp_config.wp_debug}\2″/>
</replaceregexp>
</filterchain>
</copy>
</target>
If you would run this it would not work as expected. Changing the property to “foo” it does work as expected. This is probably related to this thread:

http://phing.tigris.org/ds/viewMessage.do?dsForumId=1083&dsMessageId=958537

Using the workaround in the thread the example becomes:

<!-- setup wp config specific properties -->
    <property name="wp_config.wp_debug" value="(bool)true" />

  <!-- Setup the wp-config file -->
  <!-- thanks to http://stackoverflow.com/questions/974963/phing-and-wordpress-configuration -->
  <target name="setup-wp-config" description="Copies the wp-config-sample.php to wp-config.php and sets up the parameters for the test site">
    <copy file="./wp-config-sample.php" tofile="./wp-config.php">
      <filterchain>
        <replaceregexp>
          <regexp pattern="(define\('WP_DEBUG', )\w+(\);)" replace="\1${wp_config.wp_debug}\2"/>
        </replaceregexp>
      </filterchain>
    </copy>
  </target>
Thus by adding the type (bool) to the property value forces Phing to work correctly with boolean values as strings. Thanks Hans Lellelid for this workaround!

A bug has been filled with Phing. See this ticket #633

 <!-- setup wp config specific properties -->
    <property name="wp_config.wp_debug" value="true" />

  <!-- Setup the wp-config file -->
  <!-- thanks to http://stackoverflow.com/questions/974963/phing-and-wordpress-configuration -->
  <target name="setup-wp-config" description="Copies the wp-config-sample.php to wp-config.php and sets up the parameters for the audition test site">
    <copy file="./wp-config-sample.php" tofile="./wp-config.php">
      <filterchain>
        <replaceregexp>
          <regexp pattern="(define\('WP_DEBUG', )\w+(\);)" replace="\1${wp_config.wp_debug}\2"/>
        </replaceregexp>
      </filterchain>
    </copy>
  </target>

Oh and Roy Tanck (plugin author of WP-Cumulus) has posted a nice explanation of what bbAggregate is and why he likes it sometime ago. Check it out!

Download de presentatie inclusief voorbeeld plugin als een zipbestand

ps: Op 6 november zal ik ook een presentatie geven op WordCamp Nederland te Utrecht. Voor meer info zie de WordCamp site.

To remove the ^M characters at the end of all lines in vi, use:

:%s/^V^M//g

The ^v is a CONTROL-V character and ^m is a CONTROL-M. When you type this, it will look like this:

:%s/^M//g

In UNIX, you can escape a control character by preceeding it with a CONTROL-V. The :%s is a basic search and replace command in vi. It tells vi to replace the regular expression between the first and second slashes (^M) with the text between the second and third slashes (nothing in this case). The g at the end directs vi to search and replace globally (all occurrences).

“Too many authentication failures”.

As far as I understood this happens due to SSH trying each key on the client for logging and failing due to hitting the serverMaxAuthTries in the SSH server configuration. I use the following quick fix to work around this, by forcing SSH to use a password instead of a public key:

ssh -o PubkeyAuthentication=no username@hostname.com

I’m pretty sure there has to be a better, more durable solution for this issue, but the above fix allows you to at least gain access to your server again. Btw I use this on Linux (Ubuntu 10.04) with OpenSSH_5.3p1 Debian-3ubuntu4.

De vertaling is hier (update 2011/02/11: In de oude zip miste het *.po bestand) te downloaden.

Installatie:

1. Gedownload zip bestand uitpakken.
2. Bestanden in Limit Login Attempts directory plaatsen
3. WordPress op Nederlands als taal instellen

ps: Ik heb Johan inmiddels ook op de hoogte gesteld van de Nederlandse vertaling en ik hoop dat de vertaling zo spoedig mogelijk toegevoegd wordt aan de plugin zelf zodat je deze vertaling niet meer extra hoeft te downloaden.

So I am a bit lucky in that my father is a very experienced programmer who also gave me the bug. One of the first things he said to me when I started programming for more than just fun or OSS, was that he never judged other programmers code. He would correct it, point out flaws in it, but always with a suggestion of how to do it better. The reason for this is that in the world that we have to live in, of deadlines, PHBs and evil marketing folks who spring new features on a development team right before a release, you never know why someone’s code is the way it is.[...]

source: mprorock on reddit