Following the great response from OpenCamp and the recent Dallas Drupal User group meeting, the Dallas / Fort Worth CiviCRM Meetup is a reality!
Blogs
Keep up-to-date with blogs from the core team, working groups, developers, users and champions worldwide. Subscribe to our newsletter to receive regular updates by email. We also have an RSS feed.
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.
So, far the response to Civi-Make-it-Happen has been good. We have got one small item sponsored into 3.3 and a number of donations towards the other items. It also shows on the second search page when you google for 'Make it Happen' :-). As discussed previously there is an option to have your money refunded if the target is not reached by the deadline. Of the contributions made so far the only person who took up that option was contributing towards the CMS User Merge enhancement that is being funded. My perception is that the contributions made so far are primarily by individuals and consultants or end-users who engage directly with CiviCRM (rather than larger organisations who may engage the services of a consultant) and that they are primarily given in support of CiviCRM rather than reflecting a business decision to invest in getting desired functionality. Perhaps I should ask more questions on the contribution page!
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:
finding a particular page on the Wiki that documents a feature finding forum posts that might have answers to a tech support problem finding a blog post that covers a new / unique way to implement a custom extension ... and on and onThis 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.
