I installed CiviCRM 1.5 with Drupal 5.0 following the same steps I took installing it with Drupal 4.7 and got no errors.
CiviCRM wouldn't show up in the modules list in the admin section, so I poked around a bit to see what the overall setup was of the Drupal 5.0 modules.
I moved the civicrm.css file into the main civicrm folder, moved the civicrm.module file into the main civicrm folder and then created a civicrm.info file and follwed the same format as the other .info files (a couple of lines of code describing the module) to write to the civicrm.info file. I copied the civicrm.settings.php file to drupal/sites/default folder and went back to the Drupal 5.0 admin area and lo and behold, CiviCRM 1.5 was there. I enabled it and it worked.
The link to my test Drupal 5.0 site with CiviCRM 1.5 is here:
Based on the adjustments I made it would take all of 15 minutes or...Read more
It is important for CiviCRM to have a full fledged un-structured search engine in addition to the current structured query. I don't think MySQL full text searching (MFTS) is a good model for a couple of reasons. Firstly MFTS is restricted to myisam tables and CiviCRM uses innodb tables. Secondly MFTS is still a table level search and i don't think it can handle hierarchical data. CiviCRM contacts are hierarchical data sets.
Would be great to integrate something like Lucene into CiviCRM. A potential work flow could be as follows:
1. Publish an xml specification of the CiviCRM data model. We have done a fair amount of this work for the Branner project. We could extend and automate this quite nicely using our code generator. Also xml fits quite nicely since we can represent hierarchical data
2. Extend the logging functionality so we are aware of all modifications to any...Read more
We are happy to announce that our 1.6 Alpha release is now available for preview and testing on our servers. We'd like to get as many folks trying out the new features as possible over the next week. This will help us move quickly to a downloadable Beta release - which is currently scheduled for November 29.
You can login to the sandbox at:
User - demo
Password - demo
Highlights of the release - and things we especially like folks to try out are:
* Ajax-based suggestive search in the Contact Search box (left column)
* Dynamically loaded sections in Advanced Search and Contact View Screens
* Mouseover help in Administer Profiles, Import and other spots (look for the ? icon)
* Progress Bar during the import process
Check out the 1.6 Roadmap for a summary of new features and improvements:
There's been a lively discussion on the mailing list about requirements for linking CMS (Drupal / Joomla) Users to CiviCRM contacts and handling contributions from both types of contacts. We recognize that there is still work needed to handle the variety of use cases out there - but we've made decent progress in the upcoming 1.6 release:
- CMS (Drupal / Joomla) users can be "linked" to either an Individual contact (default behavior) OR and Organization contact.
- Sites will be able to provide a separate user registration link which will expose Organization profile(s) and create a user record, a new contact Organization record - and "link" them.
- Offline Contributions can be manually input OR imported for any contact type (Individual, Organization or Household)
- Online Contributions by authenticated users will be linked to the associated contact record. If the authenticated user IS an organization - the contribution will show up...
Finding the Template(s) Used by a Form or PageThe easiest way to find the base template used to render a particular CiviCRM screen is to do a "View Source" while on that screen. Then search for the string '.tpl file'. This will take you to a commented HTML line that looks like this (this is the Edit Contact form):... Read more
CiviCRM Forms and Wizards (multi-page forms) are based on PEAR's HTML_QuickForm_Controller. (QFC). QFC in turn is based on HTML_QuickForm (QF). It was easier for us to model a single form as a one page wizard, and hence all CiviCRM forms are instances of QFC
The basic Form object is CRM_Core_Form. All forms are derived from this class. Each derived class is expected to implement the following functions
- function preProcess( ): This function is called before a form is built. All objects needed to build the form should be built in this function.
- function buildQuickForm( ): This function builds the form. There are some helper functions in CRM_Core_Form to build some elements (Radio, Select, Yes/No etc). Classes typically call a mixture of these helper functions and QF functions directly
- function setDefaultValues( ): Default values when the form is first rendered. Typically we use the same form...
We now move onto the more interesting stuff of what really happens when a request is made and the objects that are responsible for building the response. The top level CiviCRM objects are:
- Form (CRM_Core_Form): CiviCRM forms are based on HTML_QuickForm. For drupal folks, this is more of an object representation of the much loved form api
- Wizard (CRM_Core_Controller): A set of CiviCRM Forms that collectively make up an action (Import Wizard, Mailing Wizard etc). For simplicty sake a one page Form is represented as a Wizard (CRM_Core_Controller_Simple)
- Page (CRM_Core_Page): A Page represents all html pages that are not of the above two types
- Selector (CRM_Core_Selector): A selector is a tabular/grid representation of the database data. Selectors are not high level objects, but are embedded in either a Page or a Form object.
Each of these objects offer a...Read more
CiviCRM uses the PEAR package DB_DataObject to access the mysql database. Doing so reduces the amount of sql we need to write to fetch / store values for a single table. For queries involving more than one table, we write them manually since since it was fairly painful to try to force complicated queries using DB_DataObject (we did use DB_DO for multiple table queries when we wrote EmailNow, in the end we felt the hoops we had to jump through was not worth the effort and hence the current scheme)
The basic PHP classes that represent a table are called DAO's (Data Access Objects). These are generated automatically by (xml/GenCode.php) which also generates the sql structure for that specific table. The xml files representing the schema is stored under CIVCRM_ROOT/xml/schema. The sql file generated (civicrm_41.mysql and civicrm_40.mysql) are stored under CIVICRM_ROOT/sql (note that the generated files are not present in the svn repository). The DAO files are stored under...Read more
Some of the important directories under CiviCRM svn root are:
- CRM: Most of the CiviCRM specific source code is stored in the directory. This directory is further sub-divided into other directories based on functionality (Core, Utils, Contact, Contribute, Mailing etc).
- xml: CiviCRM schema and the base Data access objects (DAO) are automatically generated from a simplified xml scheme which contains a fair amount of sql and type information. This makes it relatively easy for us to change the sql code, figure out what changes were made in a version and add meta information to a table within PHP.
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...