05 October, 2010
Filed under CiviCRM, Sprints

Today is the last day of the Bristol code sprint, which was a great experience! Lots done, climbed the Cheddar Gorge and tasted Kurundś famous lamb.... I will also always remember it for finding out I was part of the API team :-)

On a serious level, it is a good idea to have a team of people that take care of the API's. And taking care I think involves:

  • be present in the API forum, trying to help people, share ideas, discuss suggestions etc
  • maintain a Wiki page devoted to the API's with to do list, wishes for the next release, conventions, tutorials etc.
  • fix reported bugs for the API's that need fixing on a core level
  • standardize the API's to follow the conventions as much as possible

Lobo explained yesterday that we have 3 members at the moment: Xavier, Eileen and me. (Xavier and Eileen, were you aware of this :-)) And we recruited Coleman Watts yesterday, so that makes 4. Do we have more volunteers?...

Read more
05 October, 2010
By shot
Filed under v3.3, CiviCRM, Sprints
One of the goals of the (ongoing) Bristol code sprint was taking a stab at making the API calls properly permissioned, and I’m happy to report that after two days of very fruitful hacking with Erik and Xavier we’ve landed the crux of it on trunk (to be released as CiviCRM 3.3 later this autumn). For backward compatibility the PHP and Smarty APIs won’t be checking the permissions by default (for now), while the REST and Ajax ones will. This is done by the check_permissions setting in $params – if it’s set and true the permission check is performed, otherwise it’s skipped. Later in the code cycle we’ll also add ACL checks (next to the general permission checks). The civicrm_api_check_permission($api, $params, $throw = false) method located in api/v2/utils.php will either return a predicate whether the given call (with the given params, to be used in the future…) is allowed – or, if $throw is... Read more
03 October, 2010

Today at the Bristol Code sprint a few of us made a concerted effort on getting making Giftaid 'plug and play' for Civi.

Our starting point is code written by Millertech and our aim is to get it into a state that we can package it as a Drupal module.  Once we've done that, we're hopeful that we'll be able to package it for Joomla also.

We're having to make a few improvements to Civi's hooks, and some modifications to the existing functionality to enable us to package it up, but the benefits are obvious: much easier installation and thus wider uptake of the module, and thus higher CiviCRM adpotion in the UK :)

We spent most of the morning familiarising ourselves with the code and discussing the necessary changes we would need to make.  This threw up some difficult problems (I'll spare you the details) but the result was this outline of...

Read more
01 September, 2010
By kurund
Filed under CiviCRM, Meetups, Sprints, Training

CiviCRM Trainings / Code Sprint:

Read more
02 May, 2010
By scyrma
Filed under CiviCRM, Drupal, Sprints

Over the first three days of the code sprint, we got through most of the tasks to be done. So, on the last day it was decided that some time could be allocated to something different, taking advantage of developpers from different continents being together. Three of us spent a few hours working on coding a way to deploy CiviCRM site with Aegir.

Aegir is an installation profile and a group of modules (mostly hosting and provision, along with drush) that make it possible to provision (install, update, clone, backup, etc.) new Drupal sites with the click of a button. Leveraging this system for CiviCRM will have great benefits: making installation quick and easy for non-technical users, keeping the Drupal and CiviCRM installations up to date more easily, which improves security....

Read more
29 April, 2010
By lobo

The past 8 days have been an amazing period for the CiviCRM community and core team members. Its been incredibly intense, extremely fulfilling and mind-blowing. A huge thank you and tip of the hat to the members of the community who participated in the event and came together from various parts of the world (asia, europe, north america) to push the project to greater heights, from a usability, documentation and localization viewpoint.

Thank you to Jimmy H, Erik B, Goran G, Matheiu L, Mathieu P for working on improving CiviCRM's localization and internationalization features. Thank you to Michael M, Xavier D, Adam H, Sarah G, Mari T, Alice G, Jack A, Josue G, Kyle J for burning the midnight oil to update, improve and extend the CiviCRM: A comprehensive guide. Thank you to OSI and our program officer: Janet Haven, Chintu Gudiya Foundation, Yellow Dog Foundation and ...

Read more
28 April, 2010
By shot
As you have already read in the previous blog posts, one of the outcomes of the translation sprint is the fact that we’re switching our translation server to a new tool, Transifex. We decided to go with Transifex for various reasons:
  • Transifex allows teams of people to collaborate on translations – this is not an issue when you have a single person working on a translation, but as soon as you have two or more contributors working remotely, it’s crucial to use a tool that streamlines the process and allows for easy and centralised communication,
  • the user hierarchy is simple, clean and seems to be efficient: project maintainers accept language maintainers who, in turn, accept language team members and coordinate given language’s...
Read more
27 April, 2010
By goran
Filed under Architecture, CiviCRM, Sprints
It is said that optimizing too early is the root of all evil. However it is not so easy to say when is the right time. Looking at CiviCRM performance there are a number of instances where even on medium sized installations search queries take a long time to execute. One of the searches that caught my eye is the AJAX search at the top left in the menu bar. Returning a maximum of ten entries from a medium sized database (~50k records) should take negligible time and on the CiviCRM test data this request was taking around 3 seconds (putting full load on server). The culprit query from CRM/Contact/Page/AJAX.php is: $query = " SELECT DISTINCT(cc.id) as id, CONCAT_WS( ' :: ', {$select} ) as data FROM civicrm_contact cc {$from} {$aclFrom} {$additionalFrom} {$whereClause} ORDER BY sort_name LIMIT 0, {$limit} "; First of all, MySQL does not have DISTINCT(field) statement that returns rows distinct only in value of a single field. Still MySQL does not give errors on ... Read more
26 April, 2010
By bgm
Today's localisation sprint started with a presentation from Piotr on how multilingual installations works in CiviCRM. Multilingual is when you want to have not only a localised interface, but many co-existing languages. So for example the labels of custom fields may need to be in English or Spanish if the organisation has a bilingual website. In general, most labels can be translated using multilingual, but not the data itself. The main except to this is the contact name, so that it can be entered in multiple alphabets. Multilingual was labeled as an experimental feature until CiviCRM 3.1, but this warning might be removed in 3.2. A few large installs have reported using it successfully. On the coding side,
  • Lobo and Goran have pretty much wrapped up the multi-currency support. For now this allows to enter contributions offline (in the backend) in multiple currencies. Changes in the frontend will probably appear in 3.3.
  • Lobo and Goran have also worked on "per...
Read more
25 April, 2010
By scyrma

Well, it's been done, we chose the translation platform: Transifex. We're fully aware that we did not actually choose a platform that fully supports the ideal situation, but such a platform does not exists. This is more the choice of a promising back-end which we hope we can eventually develop into the ideal situation.

The interesting part in the discussion was finding a balance between the technical and functional interests.

Programmers were not too keen on choosing a platform that would require big changes to the way strings are stored and manipulated. On the other hand translators would benefit from more intuitive user interface, giving immediate feedback on results and overall progress, such as being able to find the context in which a string is used. The Drupal localization client's "on-screen translator" offers...

Read more