May 1, 2017 - Steve is no longer available for freelance work. Thanks for your interest!
Getting web site errors fixed means telling your programmer or IT people what needs fixing, and it can be challenging to communicate effectively with them. Technical folks really want to fix things, and non-technical users really want them fixed. But the language each group uses to understand and describe the world is not quite the same. The resulting confusion is frustrating for both.
It has long been good practice to use email-validation tools such as Sender Protection Framework (SPF) and Domainkeys / DKIM to provide confidence that a given server or domain has the authority to send emails on behalf of its own or other domains. We use Postfix and Amavisd-new on Debian to perform DKIM signing of messages on a central mail server that relays mail for many other servers. There were a couple of catches to getting it all working that I wanted to record for posterity, should anyone else run into similar problems.
First. amavisd-new can now (since version 2.6.0) handle DKIM signing itself, meaning you can do away with additional milters or the use of dkimproxy. To tell amavis that you want it to sign mail, you need only add this line to an appropriate config file (say, conf.d/50-user):
$enable_dkim_signing = 1;
Keys and selectors are assigned to domains by adding lines like so:
dkim_key('example.com', 'selector', '/var/db/dkim/example.com.key.pem');(I am omitting the details of generating keys and creating the DNS records necessary to make DKIM work. There are lots of tutorials on the net that cover that material.)
The folks at Make Poverty History wanted to make sure they had good data about their participant records, and so asked if we could make the connect module update information about existing participants.
We use multi-site installations pretty much exclusively. Moving sites around (from development to production, say) can be a pain, especially when there are a large number of modules in sites/all/modules, relatively few of which are used by a given subsite.
Apt-dater is a relatively new utility that allows easy package management of multiple Debian servers from a central control server. I wrote up the necessary steps below, as the existing instructions (http://www.ibh.de/apt-dater/) are slightly unclear on a couple of things.
OK, so the Connect module has actually been around for a while now, but the first version was painfully difficult to use, and the second version has only just seen an official, albeit beta, release.
Connect arose because we wanted to create a flexible and extensible online campaign platform for Drupal. The goal was to produce a framework that would allow different features to be added as necessary. Thus, a single tool could be used to create a simple petition or a sophisticated online email- or fax-sending campaign.
Setting up the CiviMail return channel is a notorious pain in the ass. The return channel is the mechanism by which email is passed back into the CiviMail system. It's necessary to allow replies and bounces to be handled by CiviCRM, making it fairly essential to the successful use of CiviMail.
The official way of setting things up is unfortunate in a couple of respects: it requires the installation of a customized version of the amavisd-new content-filtering daemon*, and it cannot handle multi-site installs. The "alternative" return channel implementation, although rumoured to not scale as well, requires no additional software, and can be easily adapted for servers hosting multiple domains that use CiviMail.
In recent months we have been transitioning from Fedora Core systems to Debian ones. Our standard install is Debian stable "Etch", and the standard slate of packages serves almost all our needs admirably.
With one exception.
The CiviLingua project was an attempt to build i18n/l10n into CiviCRM core in the late 1.6 / early 1.7 release era. Details are available on the CiviCRM wiki:
http://wiki.civicrm.org/confluence/display/CRM/CiviLingua+-+support+for+multi-lingual+sites