The code sprint in London has finished yesterday. It's always a pleasure to see old civi friends and meet new ones. Thanks to Michael and Katy to have organized it. Time for a quick update of what I've been working on with the most obscure title I could find. My focus has been on usuability to make civicrm easier and faster to use.
To make our crm more user friendly, we need to make the pages more "application like", where you can add, edit remove and reorder from the same page without having to switch and go to more pages with forms to fill and save. And load. And wait. And save, and load and wait more...
For instance -and that will be a make it happen that we launch next week to improve- creating a survey today means you have to go to visit a different page to create the survey, the profile, for each field you add in the profile, for each custom field you need to...Read more
Thanks to a successful Make-it-Happen campaign the 4.1 release comes with a much improved and super flexible approach for running Civi's critical back-ground processing tasks. These tasks include keeping membership statuses up to date and sending renewal reminders, sending scheduled CiviMail mailings, sending pledge payment reminders, and more. I've spent the past 10 days testing and documenting the new "consolidated cron" functionality, and the good news is that I think it fulfills the promise of providing a convenient and friendly way to administer and run all the required tasks for a site.
The "bad" news is that these improvements are NOT backward compatible. The set of PHP scripts which were previously used to run these tasks have all been deprecated (and moved to a 'deprecated' directory). This means that all CiviCRM-related cron jobs will stop working as soon as any site is upgraded to 4.1...Read more
Notice to non-developers: This post is about how some functionality in 4.2 will be implemented in code and in the database, with very minor changes to anything visible through a browser. If you're not a developer, it probably won't interest you.
Simplifying the Codebase
As part of the CiviAccounts project we are looking to redo some of the implementation of the configuration and processing of payments for contributions, memberships, and events. Currently the processing for each of these three types of objects has two paths: one for a simple configuration of the objects, and one using price sets. This means there is more code, more complexity, more possibility of errors, more work when making changes, and more need for testing.
As we refactor the existing code we're looking at keeping the simplified UI for configuration and administration, but implementing everything under the hood using price sets. Before going ahead with that, we wanted some...Read more
This month we did a fairly complex migration for a customer of about 90,000 contacts to CiviCRM. I have been using Migrate module to do migrations for a while now but this time for the first time I used version 2 of the migrate module. I put up a how-to-blog on our site just before Christmans but Fen has inspired me to get on with sharing it more widely.
Migrate allows you to run a specific number of items, to roll back or update items and is primarily intended to be used by drush. Data can be adjusted on the way in if you add a 'prepare' function and you can use the...Read more
I think there were few discussion in the forum about adding 'Custom Data Group' with multiple records in a profile. We wanted the same for one of our clients, who wanted an Application Form in which they wanted to collect Qualifications and Experience, which obviously is multi-record custom data against contact. As they needed it in a very short period of time, we managed to do a work around to accomplish this. As usual, the wonderful CiviCRM API version 3 and hooks come to the rescue.
So the aim was to expose the fields under the multi-record custom group in the contribution page(using buildForm hook) and allow the users to enter multiple rows and save it against the contact(using API).
We created a drupal module which does the following
- Allows admin to set the custom data group, for which the fields can be exposed to the contribution page. View Screenshot...
I've just released a new version of the CiviCRM Webform Integration module for Drupal 6 and 7.
This module provides a flexible and powerful way to create forms linked to the CiviCRM database. Version 2 of the module is built for CiviCRM 3.4/4.0, and can create and update contacts, group subscriptions, tags, relationships, cases, activities, event participants, and custom data.
New in 2.3:
- Contact Clone Feature - a real timesaver for multi-contact forms
- Now works with event registration limits
- Improves Group Subscriptions
- Deduping works with shared addresses
- Better and more consistent performance with Country/StateProvince chainselect
- Other minor bug fixes
If you're interested in the future of this module, check out ...Read more
As many of you know with 3.4 & 4.0 a new API came out (APIv3). The new API had a number of improvements over the previous v2 including
- Consistent naming of entities & actions
- civicrm_api() wrapper that eliminated the need to do lots of 'require_once' & allowed us to move functionality into the wrapper rather than replicating it. (note that as long as civicrm is initialised you don't need any 'require_once' to call api functions using civicrm_api()).
- A consistent format for the results returned
- Consistent use of the 'id' param (& returning in in results using 'id')
- A new API explorer to see the API functions.
- wrapper functions such as getsingle, getvalue, getcount to allow you to get simpler result output
- API chaining - the ability to pass results from one API call to another
- Consistent handling of...
As of the Bourne, UK sprints last August, bin/cli.php has been completely re-written for 4.1.
If you are an integrator or user, you might not have noticed this file. It used to be a PHP class that was used by many of the individual scripts in the bin directory.
Now, it's a command line program designed to be run directly.
With cli.php you can run any function defined in the API version 3.
If you run the script without any arguments, you'll get a usage statement explaining how it works:
0 jamie@chicken:bin$ php cli.php
The --action argument is required
Usage: cli.php -e entity -a action [-u user] [-s site] [--output] [PARAMS]
entity is the name of the entity, e.g. Contact, Event, etc.
action is the name of the action e.g. Get, Create, etc.
user is an optional username to run the...
As most non-profits know, driving revenue exclusively off of events can be a hit or miss adventure. Revenues YOY are not consistent, and its difficult to find those supporters who will organize and host fundraising events to support your cause. Many are intimidated by hosting large fundraisers or simply don't have the time or resources to pull it off. So to sum up our problem: we needed a broader more consistent source of revenue to fund our programs. To expand our source of revenue, we looked to our community of donors, families, and fundraisers to raise money on our behalf through their own social networks. The average user on facebook has 30 friends [http://www.facebook.com/press/info.php?statistics] which means that we could exponentially increase our reach through online social networking...Read more
Thus, functions implemented according to the API v3 conventions can be invoked several different ways. If you would like to leverage this infrastructure for use with a new or customized API call, then download the latest release. With 3.4.6/4.0.6, external developers can expose API functions for new entities, new actions, and even generic actions.
This would, for instance, allow you to create an API that returns the top donations of a person, grouped by contribution...Read more