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.

Er waren een aantal (veelal) korte presentaties die vanuit diverse invalshoeken WordPress belichten. Wat mij opviel was de verscheidenheid aan mensen die er aanwezig waren en met WordPress bezig zijn. Van hardcore (web)ontwikkelaars zoals ondergetekende en (web)ontwerpers tot vertalers en geïnteresseerden die hun eerste stapjes met WordPress nog moesten nemen.

Persoonlijk vond ik het erg leuk om te horen dat er meer mensen zijn die WordPress inmiddels inzetten voor grotere projecten, zoals ik dat inmiddels ook al voor een aantal projecten heb gedaan. Mooi voorbeeld deze avond was de website van Attractiepark Slagharen die in samenwerking met Orangevalley was ontwikkeld. Milan van Bruggen gaf ook nog een goede promotie presentatie  voor zijn online webdesign magazine Heeftstijl.nl Daarnaast kreeg ik ook nog de kans om het intranet project wat ik samen met Roy Tanck (this.play) voor de VARA heb gedaan te mogen delen met de aanwezigen. Dank nog voor de leuke reacties hierop!

Al met al weer veel leuke mensen leren kennen en gezellig met oude bekenden kunnen bijpraten. Hieronder nog een korte sfeerimpressie door Karim Osman

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.

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.

[...]Will only output the date if the current post’s date is different from the
previous one output.

Source: the_date() function in the WordPress source code.

WTF! Why on earth is this function only returning a date when the post date differs from the previous one and does nothing if the two are equal. I don’t get this. I guess I’m going to supply a bugreport and a patch.

bbRedirector makes it easy to redirect a page to another location using absolute urls from within WordPress. No mod_rewrite nor .htaccess is needed. You just create a page, add a specific customfield and choose the redirect template included with this plugin. It even allows you to set the required http status code (302 or 301). You can also set a default sitewide redirection or setup your own custom redirection.

The included templates should give you an easy start using this plugin.

Download the plugin from http://wordpress.org/extend/plugins/bbredirector/