How much server (disk space and memory) do I need to run my CiviCRM implementation....

The answer is, of course, it depends. But what are the critical factors?

-- Data base size (Number of contacts and number of custom data fields, relationships, groups, etc.)
-- Number of users (light usage vs. heavy usage)
-- What other applications will be running? (A CMS with a small data base or Jasper Reports with a lot of simultaneous users.)

I think it would be good to put forth some guidelines or rules of thumb.

Recently someone asked about setting up an autocomplete in a profile where the person completing the form would be offered the name of existing organisations in the database.

We have implemented this with a couple of different variations and I did promise to provide some information on this so here goes. I’ll try to explain a whole lot of ‘customising civicrm’ concepts but this isn’t a step-by-step recipe you’ll have to add a fair bit of technical know-how/ extra reading to flesh this out for your own purposes. I have added a recipe-type summary at the end just to sum up. Areas I will touch on are:

• Customising a template
• creating an autofill
• REST calls & the API
• Permissions & autofills/ API calls
• creating an autofill using my custom API
• Adding a ‘menu item’ (url) using a module (Drupal)
• Quicksteps

As we’re closer and closer to the release of CiviCRM 3.1, we began thinking what to schedule in CiviCRM 3.2. As one of the features we want to add is the ability to undelete certain CiviCRM entities, we want to discuss with the community the initial approach to undelete that we came up with – along with a sketch of logging functionality that we consider for a future release.

The past two days a group of us gathered at the Mitchell Kapor Foundation offices in downtown San Francisco for the first CiviCRM Test Sprint. Some of the highlights of the event were:

• Introducing the concept of testing and our current framework for unit testing. CiviCRM uses PHPUnit for unit testing. We also use XDebug for code coverage. You can see the latest results of our testing here
  

I'm working on deploying CiviCRM for my kids school website. Part of the project requires us to expose the parent <-> child relationship information on the website and allow parents to edit their child information.

I accomplished this using a combination of civicrm hooks, custom templates, permissioned relationships and custom code in a drupal module. You can access the module and template code here.

The broad steps are:

• Implement hook_civicrm_pageRun for the profile view page (CRM_Profile_Page_Dynamic). Only implement this hook for the specific profile id's you want relationship information. In this case we have two profiles, a Parent Profile (gid=3) and a Student Profile (gid=4)
• The pageRun hook also adds the module's template directory to the smarty include path, so we dont have to set it globally. This also allow multiple modules to append different template directories to the template include path (check the function _sfschool_initialize)
• The hook gets either the parent or the child information using a custom query. We ensure that only permissioned parents can see their child information (in case of some complicated family structures). The queries are relatively simple at this stage, i suspect they will increase in complexity over the next few weeks
• The hook exposes the information gathered from the database to the smarty template
• The custom template (templates/CRM/Profile/Page/3/Dynamic.tpl) uses that information to display the relationship data on the page. I also edited the View.tpl template to eliminate the "Back to Listings" link.

Some recent discussions and debates about Active Record and Data Mapper have popped up in the context of new architectural proposals for CiviCRM from Dharmatech and raSANTIAGO. We think it is important that the differences between each is known and to clarify what are some erroneous perceptions. This is not to claim that either design pattern is above criticism. It is to say, that there are some misperceptions that prevent a more intelligent discussion of the trade-offs between these two design patterns. Our hope is to bring some clarity to this discussion.

Current CiviCRM architecture pitfalls

rasantiago has proposed a new CiviCRM architecture with details of the ORM layer. Torenware commented on the latter and mentioned some particular scalability issues.  Our own experience with the Active Record design pattern proposed by rasantiago is that it works well for small projects but doesn't scale well.  We believe that CiviCRM is now facing serious scaling problems in several areas, to wit:

This is a follow up to our last post proposing a new architecture for CiviCRM. Much appreciation for everyone's patience. Following from our last post we want to go over the use of Doctrine, a PHP implementation of the Active Record design pattern made popular through Ruby on Rails. The Doctrine Project has done a great job of maintaining detailed documentation and has a lot of features that we believe everyone will find useful when working with CiviCRM objects. We have posted some of our working code for the new ORM and REST API here at git hub.We have given this code set the working name civiBASE.

Here at raSANTIAGO we are entering our third year with CiviCRM and still find ourselves struggling to make desired changes to the codebase. Too often we have expressed desired to re-architect and re-factor the CiviCRM. Recently we have completed two major projects that had us deeper in the codebase then before and realizing that we had to stop complaining.

Do you wish you could configure custom fields to store Employment History, Educational Background, Volunteer Skills or other types of information where you may need to enter multiple sets of values for a contact? Starting with CiviCRM 2.2, you can do just that.

For example, if you need to collect Employment History - you might have fields for Job Title, Start Date, End Date, and Reason for Leaving. Enabling the "multiple records" setting in that custom data group will allow you to enter that information for multiple jobs. You can also set the maximum number of records which can be recorded per contact (you might only want data for the three most recent jobs).