The kernel of my home office

I'm at a CiviCRM developer training and have to share my discoveries. Before yesterday, I always felt like a CiviCRM hacker, without really knowing why, and now I think I do. For me, the difference is between knowing a few tricks to accomplish what I want to do, compared with actually understanding the code as a whole and feeling like I could responsibly contribute stuff and not just cross my fingers that I'm not missing something important. So, no, it's not a secret handshake, but here's  what I've learned: 1. Dispatcher and permissions In Drupal, we have a bunch of code called the "menu system" which takes care of (among other things, like the actual visible menu), how a particular url maps onto a specific piece of code to be executed - i.e. which callback function gets invoked. This mapping of urls to callbacks is implemented by modules in the hook_menu function and stored in a table that gets rebuilt when modules get added and rebuilt or the menu c...

Recently a client sent out an email with a bad link in it. Normally, I'd sympathise with them but tell them that the horse has bolted and there's no point in closing the barn doors (because I like to use old fasioned expressions).  (And yes - if the link was on my server, I could give them an apache redirect.) But, if the message went out via civimail and you're tracking click-throughs of links (actually this trick also works with simplenews if you're using simplenews_stats), then there's still hope. This is because the actual link embedded in the mail isn't the final destination, but a civicrm url with a magic trackable url id, which then redirects to the final url, which is stored in a civicrm table. The rest you can probably do as a simple homework exercise, but here's the details since I've got more room for this post. Start with loading up a mysql client and use your civicrm database, then find out the right id using this: select * from ci...

A CiviCRM user and administration training in Toronto has just been announced for Nov 14-15, here: http://civicrm.org/civicrm/event/info?reset=1&id=240 If, like most people including myself, you wish you understood a bit more about this multi-headed beast called CiviCRM, then this should be a great opportunity. If you've grown a little complacent with your CiviCRM install, this is a great place to learn about all the new things you can do with it, and hear what others like you are already doing. Non-profit types already know that community is an essential part of success and sustainability, and events like this put that into practice within the CiviCRM ecosystem. In addition, there's a developer training and a 'code sprint', for the weeks following. And it reminds me that it's past time to publish a new civicrm integration module I wrote this year. Thanks to Joe Murray and Louis-Charles Lavallee for getting this going!

As faithful readers of this blog will know, I'm a fan of IATS  as a payment processor solution for non-profits. Many years ago I wrote a CiviCRM payment plugin that is still in wide use by most of my clients and many others as well. Although my Drupal module contributions have been minimal over the recent past, I'm happy to announce a new one to integrate IATS payments into the new Drupal Commerce module/distro/framework/thingy. Tada:  http://drupal.org/project/commerce_iats Many thanks to Karin Gerritson, my colleague at Blackfly Solutions , and her project to develop a new site for the school she sends here kids to, here: https://secure.cfis.com/ What this means for the rest of the world: non-profits have a nice solution to get e-commerce going on Drupal 7 with a minimum of cost and hassle.

Inspired by this post: http://rarepattern.com/nodes/2012/recovering-contrib-image-modules-content-upgrade-drupal-7 I thought I'd dig out and contribute a script I wrote for a similar issue I had with a number of old sites. Specifically - in the old days before imagecache, one way to safely enable your site editors to add pictures to posts was using a combination of the image module with the image attach module. Functionally, most of the sites I've seen it on were doing the same thing as the imagecache, only not as well, and now that D7 is mainstream I can't prolong keeping it going any longer. The main difference with Laura's post above is trying to deal with the image attachment bit - i.e. getting the images into the fields of the posts to which the original image nodes where being 'attached'. The other key difference - this script was written for D6, so do this before you do your D7 upgrade. It's making use of the D6 table structure, it's not...

Varnish is front-end web proxy that I've been using with my Drupal sites for 18 months now. I talked about it in a presentation at Drupal camp with Khalid . A front-end web proxy means that instead of visitors directly accessing the Drupal site, they go through a caching layer. I like to think of varnish as a protective bubble around Drupal. Using Varnish has a number of benefits, and in my presentation I was particularly interested in demonstrating how it enables a site to survive huge spikes of sudden traffic , beyond what a web server would normally be able to handle. So that's one of the benefits. Another important benefit is to reduce the load on the server , enabling better response. Or more cynically, it would enable you to pile more sites onto your server. But to explore this more closely: by moving most of your 'easy' page loads out of the php/apache stack, you can tune your stack better to what it's got to do - and you're not wasting 128Mb or mo...