When developing with CiviCRM, one often prepares a development-build on your workstation which includes several git repositories, e.g.
- Git repositories for the official CiviCRM code (civicrm-core, civicrm-packages, and one or more of the CMS repos -- civicrm-drupal/civicrm-joomla/civicrm-wordpress)
- Git repositories for some Drupal modules, Joomla extensions, or WordPress plugins
- Git repositories for some CiviCRM extensions
Managing all these git respositories in the development-build can be challenging, and a few techniques have arisen within our community:
- Manage them all manually. This gives precise control over checkouts, branches, merges, etc., but it can be cumbersome, and it's easy to make a mistake or omission when you have more than 2 repos.
- Manage them with "gitify...
We've marked a new release of civix. Notable changes/improvements:
- generate:case-type - Add a new command to generate skeletal CiviCase XML files. (As usual, the new command is documented in the wiki page, "Create a Module Extension".)
- generate:module - Add support for generating license metadata by passing parameters "--license", "--author", and "--email". The information will be propagated to info.xml and LICENSE.txt.
- generate:module - Add hook stub for hook_civicrm_alterSettingsFolders so that files in "settings/*.setting.php" are automatically loaded.
- generate:module - Add hook stub for hook_civicrm_caseTypes so that files in "xml/case/*.xml" are automatically loaded.
- Add documentation links for hooks (using "@link").
- Reformat civix's internal...
As lobo mentioned in his previous blog, we have been experimenting on Doctrine integration with CiviCRM. So in the following week we focused on few specific tasks:
Investigate triggers / stored procedures in doctrine
Doctrine does not have explicit support for triggers and stored procedures. In the past they have not encouraged it and have an alternative called "lifecycle callbacks". For more infor: http://symfony.com/doc/current/book/doctrine.html#lifecycle-callbacks ( CRM-13989 )
- How to add custom / Civi annotations to...
A few of us have started exploring how we can integrate Doctrine into future versions of CiviCRM. A large part of this work was initiated by Peter Haight from Giant Rabbit who explained his thinking and approach in this blog post on Persistence Refactoring. One of our goals for the next few releases of CiviCRM is to improve the technology backbone that Civi is based on. It made sense to most of us to start from the database layer and then move outwards and using doctrine and working with peter seemed a good logical next step.
We decided to spend 3 weeks (till mid january) on various exploratory sprints and try and answer a few questions and see how things are done in the doctrine/symfony world of things. We also decided to start adopting more scrum - like technques and iterate on a weekly basis....
Fair warning, this post is intended to the technical part of our community, if you don't care about the architecture of civi, please skip this one, I'll come back to you soon with awesome datavisualisation and an interview of Micah about security and privacy (you'll like it).
And if you read anyway, I'm a bit of a drama queen and some of the mountains I describes are probably hills, at best.
We've started to look into changing how objects get persisted in CiviCRM and what can we do to make things easier for people extending CiviCRM. Part of our approach is to try and integrate Doctrine into CiviCRM.
We get a lot of requests for customization and feel that the current CiviCRM customization infrastructure doesn’t meet most of our customization needs. We get a lot of requests to customize event checkouts and one of the things we frequently want to do is modify what happens at the end of the checkout process. A recent example is a subscription system where subscribers get a number of free passes to an event. We did this by manipulating some of the internal form variables to not do the payment part of checkout. The main problem with this approach is that we don’t really expect it to survive updates over a long period because it uses some internal mechanisms.
We’d like to fix this situation by separating...Read more
In New Zealand workplaces it's common to see a sign in the smoko* room saying "Your mother doesn't live here - do your own dishes".
People tend to follow this instruction as longs as:
a) there is not already a pile of dirty dishes next to the sink
b) and they can see where to wash the dishes, and where to put them afterwards.
c) their colleagues aren't setting a bad example.
If they see a pile of washed cups beside the sink, another pile on a shelf above the sink and a third pile in a cupboard on the other side of the room if might not be obvious to them that the sign writer meant them to notice the new dishwasher recently installed below the sink & that was the correct place to put the dishes (and actually they didn't need to wash them first).
Code maintenance can be bit like that. If you tidy up a chunk of code people untidy it because
a) they are copying...Read more
CiviCRM configuration is largely driven through the web interface and the database: if an administrator wants to add a new "report" or new "relationship type", he can accomplish this with a few clicks of the web interface. The new item is inserted into the database and immediately becomes live. This is great for web-based administration, but it's inconvenient for developers: if a developer writes a module or extension that registers something in the database, then he needs to write an installation routine to insert the item (and an uninstallation routine to delete the item). CiviCRM 4.2+ includes a better way: use the API and hook_civicrm_managed. This technique is already used in "civix" based extensions, but it also works with Drupal modules, Joomla plugins, etc.
As an example, suppose we are creating a module/extension called "fancyreports" which defines three new report classes. Each of these classes...Read more
After my previous blog post, i have been working on making progress on working model w.r.t NoSQL and config. Starting with civicrm cache was a good idea. Keeping in mind NoSQL, new config system and what Eileen has already done with settings, here is what i planned and accomplished :
Placed cache and cache-type (mongodb) settings file on disk with default values
Sticking to plans in previous post, and eileen's work on richer metadata, created two files in settings directory of civicrm. Richer metadata does help in creating web configuration forms without any extra coding for the config-items, and i was able to use it for building the new simple config UI.
deepak@bfc:civicrm$ ls settings .... system.cache.php system.cache.mongodb.php .... deepak@bfc:settings$ cat system.cache.php return array( 'class' => array(...Read more
As of March 1st, the official source-code repository of CiviCRM has switched from Subversion to Github. Git and Github provide a number of advantages:
- Popular among FOSS projects and web developers.
- Free as in beer and (mostly) free as in speech.
- Supports off-line development.
- Supports lightweight branching, merging, and code-review.
- Supports open teams – anyone can jump-in, make changes, and share changes.
For instructions on converting an existing installation (based on SVN or tarball) to a git checkout, see:
As you get to developing and submitting patches, please try out Github's "pull-request" process. This process allows you all the benefits of git and github (publishing, offline development, lightweight branching, online code...Read more