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).

As the various localisations of CiviCRM get traction, the first localised versions of documentation pages begin to show up – and this brings us to the issue of how to internationalise these of the CiviCRM strings (texts) that contain links to documentation pages so that when a given string is translated to, say, German, it also refers to the German version of the documentation page (if such is present).

It's that time of year again!

No, not what you think. :-) It's the time of year when new a CiviCRM version is behind the door, and it has cool new features. Code freeze is going to be introduced any day now - and we'll move on to quality assurance, alphas, betas and other equally exciting stuff.

Let me briefly introduce you to two new 2.2 features: one of them already mentioned here and there - Personal Contribution Pages (PCP), and a "last minute" addition - Soft Credits.

The CiviCRM core team is currently meeting in San Francisco. We tend to meet 2-3 times a year. These meetings help us crank out a few large projects as a group and also help improve our communication when we return to our respective home bases.

Implementing support for multiple organizations with hierarchy is one of the main themes of the phase 2 part of the CiviCRM / The Public Interest Network (PIN) project. PIN has a fairly complex structure. It is a federation of organizations which include US PIRG, Environment America and others. It is made up the National PIN organization and has a number of child organizations at the National Level. One of them is Environment America (EA).

Integrating CiviCRM with an email client (specifically Outlook) has been a long requested feature. Unfortunately we dont really have any internal windows expertise to make this happen (for now). For now, we've built some code for the HRD project that attaches incoming email as an activity to the contact record of emails that are in the from / to / cc / bcc fields (we create a contact record if not found)