Architecture Series

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). This article introduces a proof-of-concept solution.

Last week I wrote a blog about technical debt (comparing it to keeping a kitchen in order). I got a lot of feedback - most of it constructive. I'm going to resist belabouring the whole metaphor & limit this blog to a quick summary of some of the discussion that came out of it.

Do you like to whinge about CiviCRM code? Have you sat through others doing having a rant? I've certainly done both. Being in the drupal world people often like to compare CiviCRM code with drupal & CiviCRM usually comes up a bit short. I think that's like comparing my kitchen with Bill Gate's kitchen. There are a few good reasons why my kitchen is not as nice as his. However, should I look at his kitchen (in a magazine) then I might glean a few good ideas that I could use in designing my own. (Copying the colour scheme would be in my budget :-))

Hi,

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.

CiviCRM 3.4.x and 4.0.x introduced API v3, a more consistent set of interfaces for integrating with CiviCRM using PHP, Smarty, Javascript, and REST. Building on this consistent core API, recent CiviCRM updates have introduced even more ways to manipulate your data -- such as chaining and CSV batch importing.

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.

CiviCRM 3.3 introduced a new hook that allows you to interact with and alter dedupe queries. Unfortunately, it was something of a "hidden hook" as it lacked documentation for quite a while. But it can be quite useful and powerful, and thus deserving of a review.

Imagine for a moment that CiviCRM is a garden. In all its object oriented complexity lie bugs and weeds that need to be effectively discovered and managed. Managing a garden the size of CiviCRM is a daunting task for one individual, and even a team of developers along with a community of end-users and testers still need help. There is indeed help to be found! 

Hi,

Some improvements on permissions and the API are landing on 3.4.2 and 4.0.2.

On the previous versions, the permissions where not enforced (on php and smarty) and checked on the same permission "access civicrm" for the rest and ajax no matter the operation and entity.

Many modern web applications have a lot of spam deterrent such as Captcha, Bayesian filters, URL, ip detections etc. One example is trying to do 2 consecutive search on the CiviCRM.org forum and you will get a an error that look like

"Your last search was less than 5 seconds ago. Please try again later."

The concept behind this is flood control is to prevent a webbot (automated script) that is trying to spam and flood the server. 

I’m happy to announce the rebuilding of CiviCRM translation resources. If you’ve been a visitor to our Transifex page previously, you know that CiviCRM always ran two concurrent sets of translation resources – one for the stable version and one for the upcoming version (since its first beta release). This was cumbersome – and is the past now.