11 October, 2013
By peterh

We've started to look into changing how objects get persisted in CiviCRM and what can we do to make things easier for people extending CiviCRM. Part of our approach is to try and integrate Doctrine into CiviCRM.


We get a lot of requests for customization and feel that the current CiviCRM customization infrastructure doesn’t meet most of our customization needs. We get a lot of requests to customize event checkouts and one of the things we frequently want to do is modify what happens at the end of the checkout process. A recent example is a subscription system where subscribers get a number of free passes to an event. We did this by manipulating some of the internal form variables to not do the payment part of checkout. The main problem with this approach is that we don’t really expect it to survive updates over a long period because it uses some internal mechanisms.


We’d like to fix this situation by separating...

Read more
26 July, 2013
By Eileen
Filed under API, Architecture, CiviCRM

In New Zealand workplaces it's common to see a sign in the smoko* room saying "Your mother doesn't live here - do your own dishes".


People tend to follow this instruction as longs as: 

a) there is not already a pile of dirty dishes next to the sink

b) and they can see where to wash the dishes, and where to put them afterwards.

c) their colleagues aren't setting a bad example.


If they see a pile of washed cups beside the sink, another pile on a shelf above the sink and a third pile in a cupboard on the other side of the room if might not be obvious to them that the sign writer meant them to notice the new dishwasher recently installed below the sink & that was the correct place to put the dishes (and actually they didn't need to wash them first).


Code maintenance can be bit like that. If you tidy up a chunk of code people untidy it because

a) they are copying...

Read more
24 May, 2013
By totten
Filed under API, Architecture, Extensions

CiviCRM configuration is largely driven through the web interface and the database: if an administrator wants to add a new "report" or new "relationship type", he can accomplish this with a few clicks of the web interface. The new item is inserted into the database and immediately becomes live. This is great for web-based administration, but it's inconvenient for developers: if a developer writes a module or extension that registers something in the database, then he needs to write an installation routine to insert the item (and an uninstallation routine to delete the item). CiviCRM 4.2+ includes a better way: use the API and hook_civicrm_managed. This technique is already used in "civix" based extensions, but it also works with Drupal modules, Joomla plugins, etc.

Example Use-Case

As an example, suppose we are creating a module/extension called "fancyreports" which defines three new report classes. Each of these classes...

Read more
16 March, 2013
Filed under Architecture, CiviCRM

After my previous blog post, i have been working on making progress on working model w.r.t NoSQL and config. Starting with civicrm cache was a good idea. Keeping in mind NoSQL, new config system and what Eileen has already done with settings, here is what i planned and accomplished  :

Placed cache and cache-type (mongodb) settings file on disk with default values
Sticking to plans in previous post, and eileen's work on richer metadata, created two files in settings directory of civicrm. Richer metadata does help in creating web configuration forms without any extra coding for the config-items, and i was able to use it for building the new simple config UI.

deepak@bfc:civicrm$ ls settings

deepak@bfc:settings$ cat system.cache.php
return array(
  'class' => array(...
Read more
01 March, 2013
By totten
Filed under Architecture, CiviCRM

As of March 1st, the official source-code repository of CiviCRM has switched from Subversion to Github. Git and Github provide a number of advantages:

  • Popular among FOSS projects and web developers.
  • Free as in beer and (mostly) free as in speech.
  • Supports off-line development.
  • Supports lightweight branching, merging, and code-review.
  • Supports open teams – anyone can jump-in, make changes, and share changes.

For instructions on converting an existing installation (based on SVN or tarball) to a git checkout, see:


As you get to developing and submitting patches, please try out Github's "pull-request" process. This process allows you all the benefits of git and github (publishing, offline development, lightweight branching, online code...

Read more
10 February, 2013
Filed under Architecture, CiviCRM

As part of my course i have been doing research on what would it require plug an external storage engine into CiviCRM, and how other open source systems doing it. Answer lies in a better config system which allows doing it in a scalable pluggable manner. As i make progress i'll be showing more reasons to get excited and curious about building a better config system. Drupal 8 has spent a fair bit of time on configuration management to make things easier. And we shouldn't shy learning from them and others.     

Standardizing config with hierarchical storage

The second layer of drupal's proposed configuration system is to store config data from file system to database for fast access. That is storing all config data in one place. CiviCRM has already been doing this decently for quite some time with civicrm_settings table. Whats new things to learn here are -

1. Standardising access to config

So we...

Read more
20 November, 2012

Just created a quick ERD for CiviCase, and shared it on this page http://wiki.civicrm.org/confluence/display/CRMDOC42/CiviCRM+ERD+3.3.

It is version 3.3, so not the latest and greatest. But I am sure I will have to check the same ERD for version 4 at a near point in the future and update the ERD too. And I do not think there are major differences in the data model......

I have also attached the ERD to this blog post.

26 September, 2012

Extensions are a growing part of the CiviCRM way of doing things. We need to develop a process and toolset to facilitate getting them translated and making those translations easily installable. This post is intended to lay out some issues and a potential approach in order to generate discussion.

Here are some assumptions and suggestions I have:

  • Extension developers should be responsible for coding their extensions with ts(), and can be expected to do things like extract strings from their extension and upload somewhere for translation.
  • Transifex is the tool used for translating CiviCRM strings. It has a team for each language translation, who do the translations. This approach is working fairly well. Having extension strings presented for translation in the same space, and displaying percent translated for them, etc. would be ideal.
  • Translations are done in spurts and at somewhat unpredictable times, depending on the interest and...
Read more
22 July, 2012
By totten

Brian Shaughnessy (lcdweb), who has been working with the New York State Senate's CiviCRM project, recently raised the issue of simultaneous editing: What happens when two users simultaneously make changes to same contact record?  We've held a few discussions on IRC to examine the issue and draft some solutions.  We would appreciate further feedback and ideas on how to address the issue.

The Problem

As described by Brian:

The issue is that if you and I get into the same record around the same time, and you save the record first, when I save, it will overwrite your changes.  So let’s say you add a middle name, and I get in and add a birthdate.  The data is not in conflict, and both changes should be preserved, but they aren’t -- when you save the birthdate (where the edit form was loaded before I saved the middle name), the empty middle name overwrites the value I had saved. 


Read more
27 March, 2012
By totten
Filed under API, Architecture, Extensions

Many CiviCRM customizations have been packaged and distributed as Drupal modules. This can be desirable when a customization delves into both the CMS and CRM functionality, but -- when a customization focuses only on CiviCRM -- Drupal modules are a drag: they need to be patched for CMS upgrades (D6/D7) as well as CRM upgrades (Civi 2.x/Civi 3.x), and they don't work with CiviCRM's other CMS's (Joomla and WordPress).

Fortunately, dlobo has been making progress on support for native modules (built around the "CiviCRM Extension" system) in 4.1 and 4.2. An example module is here:

Of course, this still poses a challenge: a native module needs to use native tools for packaging code, adding new web pages, developing templates, etc. -- and all those tools come with a learning curve. To improve the learning curve, I've taken a...

Read more