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.
As hinted previously, I’ve been working on dedupe improvements for CiviCRM 2.1. The first thing I wanted to handle is to move as much of the dedupe search from the PHP code to the database side.
I created a wiki page describing the plan; it would be great if any interested parties gave it a read and commented. Thanks!
CiviCRM is an open source constituent relationship management system used by NGOs and advocacy groups (like Amnesty International, Wikimedia Foundation or the Joomla!
CiviCRM is an open source constituent relationship management system used by NGOs and advocacy groups (like Amnesty International, Wikimedia Foundation or the Joomla! and Drupal projects) all over the world. Judging by the number of community-contributed and -maintained translations and civicrm.org statistics, CiviCRM installations exist in over twenty languages using various alphabets (Latin, Cyrillic, Arabic, Devanagari, Chinese).
Sunday 20th and Monday 21st April was CiviCRM Bootcamp in Melbourne - an excellent couple of days of training, discussion, and discovery.
Thanks to the wonderful people from Joomla! who took us under their Google Summer of Code umbrella and personal commitment from Wes Morgan, of Environment America (who will be mentoring on CiviCRM’s behalf), we’re very, very happy to announce that we have two student projects funded by Google this year!
Drupal 6 introduced a new menu system. CiviCRM had modeled its menu system after drupal 4.x which meant we needed to upgrade the menu code significantly to upgrade CiviCRM to Drupal 6. We took the opportunity to learn and understand more from drupal's new system and also simplify the interface between CiviCRM and Drupal with regard to the menu hook.
The CiviCRM menu system has been based on the Drupal menu system, so all credit for the below goes to chx and the Drupal folks (all blame should be assigned to us). We have simplified and extended it a bit to meet our needs. Similar to Drupal menu system, the CiviCRM menu data now resides in the database. civicrm_menu stores all the information for a menu item.
Brian Shaughnessy is working on some layout improvements for a client - which may potentially result in some core code contributions. He posted this question on the forums today:
I notice there's some inconsistencies regarding how some of the forms are laid out. Specifically, I'm running into forms that use a mix of table/tr/td tags with dl/dt/dd tags to layout the form labels and fields. This makes it more difficult to have consistency laying out the page using css, because those tags are structured differently.
My personal preference is to use table tags exclusively. Because of the built-in structure of dl/dt/dd tags, I find them hard to layout on a consistent and growable/shrinkable manner. I know that in a strict-css-world we shouldn't use table tags for layout, but for a long list of form labels and fields, many of which have option contingencies, tables seem like the most logical way to handle layout.
Since this is an issue we've struggled with, and because we're looking at changes to some key screens and forms to improve usability - I'm posting my response here as a blog. Hopefully we'll grab a few more eyeballs and get some useful input from folks with expertise in this area...
We’re currently planning on various improvements to the duplicate contact finding (and merging) engine for CiviCRM 2.1. Among others, we plan to have a more responsive mechanism by caching the dedupe search results in a more effective way, add the ability to restrict deduping to a certain group, as well as move at least parts of the dedupe out of PHP and into MySQL (now that we require MySQL 5 anyway).
