25 August, 2014
By totten

Good testing is critical for providing quality software. Some testing is always manual but writing automated tests to do the heavy lifting is a key part of modern coding practices. For developers, the discipline of writing automated tests helps to proactively identify and control edge-cases, and regularly running tests helps to identify problems quickly (before they grow and cause greater harm). Fostering a healthy culture of testing requires easy, consistent, timely test-results which in turn requires an easy, consistent, quick way to setup a new test environment. Easy, consistent setup of a test environment helps both (a) with individual developers who write and run tests on their personal sandboxes and (b) with teams which run tests in a continuous-integration environment.

This need is shared equally by the core team and many other active development teams in the CiviCRM community: many teams need to install and run tests with CiviCRM, a CMS, and a set of modules or...

Read more
01 April, 2014
By kurund
Filed under Architecture, CiviCRM
CiviCRM has been around for 9 years, and some of the technologies that we use are older and need architectural revamping and improvements. For developers, architectural improvements will make the platform easier to adapt and easier to learn -- which means developers can spend more time creating better features to help our users and our causes. In the next few releases, we'll work to improve these technologies -- especially the core frameworks and libraries that CiviCRM is based on.
Here are two areas of our focus:
  • Database layer: currently we use PEAR DB_DataObjects
  • Presentation layer: currently we use PEAR QuickForm and Smarty templating engine for manging front-end constituent forms, back-end administration forms, and data...
Read more
10 March, 2014
Filed under Architecture

The CiviCRM community is hard at work on version 4.5 and even in its pre-alpha state I have to say it is looking really good! I'll do another blog in a few weeks about all the features and improvements users have to look forward to. But developers, this one is for you. Whether you maintain a CiviCRM extension, submit pull-requests, or develop customizations for your sites, you definitely want to read on...

FIrst, the bad news:

Yes there are a few breaking changes in 4.5 so let's get those out of the way first. As always, we try to keep the API as stable as possible, so don't worry no breakage there. But if your code relies on Civi's internal functions or packages, check this out:

  • Upgraded jQuery and jQuery UI. We always try to keep up with the latest version of javascript libraries, but this one is a particuarly big bump. Read about all the breaking changes in...
Read more
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

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