CiviCRM Architecture - Introduction

Over the next few weeks, I will blog about the architecture of CiviCRM and some basic principles that we follow in the design/coding phase. In this series I’ll also talk about how we integrate with Drupal/Joomla and the scalability/performance/memory bottlenecks in CiviCRM. CiviCRM is built on top of some incredibly powerful open source toolkits. They include:

• PHP, we use PHP 5.1 for development and will probably switch to PHP 5.2 in the next few weeks as our primary development platform. We restrict ourselves with the features that we use in PHP 5 to enable an auto-translation of the code to PHP 4. I suspect we will drop support for PHP4 around the time we release CiviCRM 2.0 :)
• MySQL, we use MySQL 5.0 for development. We also support MySQL 4 and do not use MySQL 5 specific features. I suspect we will drop support for MySQL 4 when we release CiviCRM 2.0, primarily to use advanced features that MySQL 5 offers including views, stored procedures and triggers, all of which can improve CiviCRM performance significantly (i think) and also make the code more manageable
• Apache, for our web serving needs :) Some core apache modules that we use include mod_expires, mod_deflate and mod_ssl
• PEAR, the PHP PEAR library. This is the main PHP library that we use and find it incredibly useful and relatively stable. We do upgrade all our PEAR libraries to the latest version on every CiviCRM release (i.e. every 3 months). Some of the components we use include HTML_QuickForm, HTML_QuickForm_Controller, DB_DataObject, Mail, Pager, Image, Validate. More on this in future articles
• Smarty, the Smarty templating engine. This allows us to make a nice and clean seperation between the HTML / JavaScript and the PHP code. 99% of our HTML/JavaScript/CSS resides in the top level directories templates/js/css which are outside the PHP code (a good practice to follow in general)
• Postfix, as the mailer for CiviMail. A few folks have ported this to qmail. In conjuction with this, we also use AMaViS for content filtering (primarily to intercept and process incoming email)
• Dojo Toolkit, for the ajaxification process of CiviCRM. A very impressive piece of software and we’ll continue to blog on our experiences with Dojo over the next few weeks
• Pootle, for our translation needs.
• In addition to the above, we also use the SimpleTest and Selenium for unit and browser testing, the PayPal SDK for integration with PayPal web services, fpdf for mailing labels and other smaller packages that I’m forgetting to mention…

To make the installation process a bit easier, we package a large majority of the above packages in our distribution (now you know why our download file size is HUGE!). As evident above, We do believe in using other open source projects in a significant manner. This has its pros and cons, but from our perspective the pros outweigh the cons significantly. In addition to not reinventing the wheel, we also have other open source communities that we can fall back on for support and help. More on architecture and CiviCRM building blocks in the next post… lobo