Blogs

Slight change in plans - I was promising the recipe on packaging payment processors, but we'll do custom reports first. They are second in the hierarchy of complexity after custom searches, and they smoothly introduce small new concept that will be described below.

We are extending the 3.3 deadline to the 3rd of October to make one last push towards getting more of the initiatives into 3.3 and after that the focus will move to trying to get some more momentum for 3.4. Personally I would LOVE to see the dedupe exception table item get some funding. Anyone who has done deduping themselves will understand why!

Continuing the series, let's look at packaging payment processors. Before digging in the text below, make sure you're up to date with previous blog posts: on info file format and on packaging custom search.

As promised previously, here is the first recipe for creating your own CiviCRM extension. We'll start with the easy one - let's create an extension providing a custom search.

First, you obviously need to create your custom search, as described in documentation. Once you have the PHP class and the template, you can start packaging it. Let's say you will be doing an activity search. You need to prepare the info file as per description in previous blog post. Please note some details around info file has changed a bit since it was originally published - that's caused by integrating some of the feedback from blog comments. The info file structure shown that blog post has been updated and reflects the current structure.

We just completed a CiviCRM Code Sprint in NY. A big tip of the hat to Rayogram for providing the space and coordinating the logistics, especially to Kyle Jester. Thanx to Chang and Matt from emotive LLC for providing breakfast and lunch during the sprint.

As hinted in the blog post on upcoming features, CiviCRM 3.3 will ship with the first cut of database-level logging.

Last week, thanks to the invitation and sponsorship from Fundacja TechSoup, I was able to attend the Local Philanthropy Workshop organised by the Odorheiu Secuiesc Community Foundation in the lovely town of Odorheiu Secuiesc in Transylvania.

Many folks (including me) are occassionally (or even frequently) frustrated in our ability to find answers to our CiviCRM questions. It may be:

This blog post is outdated. For latest information about how to create extension, please refer to Extensions Wiki Page.

It had to happen sooner or later - CiviCRM is growing with with variety of functionality, where people can plug in their own, custom pieces and make CiviCRM more tailored to their needs. Most prominent examples at the moment include payment processors, custom searches and custom reports. Don't confuse it with "larger scale" customisation, like writing Drupal modules which - using API and hooks - modify CiviCRM behaviour. We're talking about well defined, self-contained pieces of code which throw in some useful functionality into your existing installation. As of now, it's a bit of a hassle to install them - you need to put files in proper places, register them using administrator section and so on: nothing extremely complicated, but also definitely not the easiest part of CiviCRM setup and configuration. More to that, some very useful extensions (like some payment processors) are shipped with vanilla CiviCRM, but not supported by core team, some  of them are not shipped, but available only from forums or issue tracker. In general - you can find a lot of useful things, it's just requires some effort.

I'm pleased to announce that the target for the first of the Civi-Make-it-Happen initiatives has been reached. We have raised $750 to fund enhancing the dedupe functionality to merge CMS user accounts when de-duping. Those of us who are familiar with the experience of clicking on each contact to see which one has a userID before clicking merge will be pleased to see this enhancement and grateful to those who donated.