10 February, 2014
By totten
Filed under CiviCase, CiviHR, Architecture

(This post is a follow-up to previous discussions about developing recruitment functionality for CiviHR. More information can be found in the first, second, and third blog posts well as the requirements wiki.)

We've recently had some great discussions about translating CiviHR's businss requirements for recruitment into a design with specific visuals and data models. Three concepts have been central to the discusion:

  • Job Vacancies are openings for new employees (or interns, contractors, or other selective positions).
  • Job Applications are...
Read more
15 January, 2014
By totten
Filed under Architecture

When developing with CiviCRM, one often prepares a development-build on your workstation which includes several git repositories, e.g.

  • Git repositories for the official CiviCRM code (civicrm-core, civicrm-packages, and one or more of the CMS repos -- civicrm-drupal/civicrm-joomla/civicrm-wordpress)
  • Git repositories for some Drupal modules, Joomla extensions, or WordPress plugins
  • Git repositories for some CiviCRM extensions

Managing all these git respositories in the development-build can be challenging, and a few techniques have arisen within our community:

  • Manage them all manually. This gives precise control over checkouts, branches, merges, etc., but it can be cumbersome, and it's easy to make a mistake or omission when you have more than 2 repos.
  • Manage them with "gitify...
Read more
13 January, 2014
By totten

We've marked a new release of civix. Notable changes/improvements:

  • generate:case-type - Add a new command to generate skeletal CiviCase XML files. (As usual, the new command is documented in the wiki page, "Create a Module Extension".)
  • generate:module - Add support for generating license metadata by passing parameters "--license", "--author", and "--email". The information will be propagated to info.xml and LICENSE.txt.
  • generate:module - Add hook stub for hook_civicrm_alterSettingsFolders so that files in "settings/*.setting.php" are automatically loaded.
  • generate:module - Add hook stub for hook_civicrm_caseTypes so that files in "xml/case/*.xml" are automatically loaded.
  • Add documentation links for hooks (using "@link").
  • Reformat civix's internal...
Read more
09 January, 2014
By kurund
Filed under Architecture, CiviCRM

As lobo mentioned in his previous blog, we have been experimenting on Doctrine integration with CiviCRM. So in the following week we focused on few specific tasks:

Read more
13 December, 2013
By lobo
Filed under Architecture, CiviCRM

A few of us have started exploring how we can integrate Doctrine into future versions of CiviCRM. A large part of this work was initiated by Peter Haight from Giant Rabbit who explained his thinking and approach in this blog post on Persistence Refactoring. One of our goals for the next few releases of CiviCRM is to improve the technology backbone that Civi is based on. It made sense to most of us to start from the database layer and then move outwards and using doctrine and working with peter seemed a good logical next step.

We decided to spend 3 weeks (till mid january) on various exploratory sprints and try and answer a few questions and see how things are done in the doctrine/symfony world of things. We also decided to start adopting more scrum - like technques and iterate on a weekly basis....

Read more
29 October, 2013
By xavier

Fair warning, this post is intended to the technical part of our community, if you don't care about the architecture of civi, please skip this one, I'll come back to you soon with awesome datavisualisation and an interview of Micah about security and privacy (you'll like it).

And if you read anyway, I'm a bit of a drama queen and some of the mountains I describes are probably hills, at best.

Various components of civicrm were chosen at the start of the project, when the top of the art in php component was the PEAR repository and dinosaurs were still roaming the earth. Most of them didn't age that well and there is a broad consensus we need to replace them at one point or another. We've already replaced our javascript framework and moved from dojo to jQuery and some ajax heavy part of the interface are benefiting from backbone+marionette for instance.

Replacing the...
Read more
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