We are excited to announce that CiviCRM 3.1.5 has been released, and is now available for download. You can also try it out on our demo site. This release includes 40 bug fixes/improvements to existing functionality. We recommend that sites currently running v3.1.4 or earlier upgrade to this version as soon as possible.
Download
Blogs
Keep up-to-date with blogs from the core team, working groups, developers, users and champions worldwide. Subscribe to our newsletter to receive regular updates by email. We also have an RSS feed.
The first Toronto CiviCRM Meetup held at the RNAO headquarters near King St and University Ave last night was a great success.
There were 29 registrants and about that many attended. (It seems like the small number of regrets and no-shows were canceled out by non-registered people showing up!)
I am working on an import guide to help organizations match fields to CiviCRM's standard fieldsets. I noticed that the existing ERDs are pretty outdated. The new database schema is pretty large for one map so I decided to create a map for contacts.
There seems to be growing interest in CiviCRM in Seattle. People want to know more about what it is, how it works and how they can harness the power for their clients or their own organizations. Recently at DrupalCon in San Francisco I ran a training on CiviCRM that was attended by a fellow Seattlite, and in the weeks just before that I was introduced to a few other folks in Seattle using CiviCRM. So it seems like it is time.
I posted a recap of CiviCon late last week on the CivicActions Blog including links to all the Ignite and Lightning talks, but figured I should repost those links here.
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.
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).
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.
The following notes were gathered from the CiviCon session on what the community would like to see in CiviCRM 4.0:
* Goals * No new features * Framework switch * Not as major a rewrite as it looks * Don't want to change many of the private APIs * Want to switch away from pear * Test unit coverage * Better API hooks * What users would like to see * Continuous Integration * Hudson - as you submit code runs through suite of unit tests to see what's broken * Better decoupling * Drupal Forms API
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.
