Civi v4.7 introduces some overhauls to the core CiviCRM development framework. Some of the planning discussions can be found in the forum, but now that it's merged and stablized a bit, I wanted to give a walk-through for other developers. A few highlights:
CiviCRM sits in the middle -- exchanging data with your CMS, payment processor, email service, SMS service, spreadsheets, ad nauseum. CiviCRM is also extremely flexible -- supporting multiple CMSs, multiple payment processors, multiple email providers, multiple SMS providers, ad nauseum. These are great power features, but they also come with a cost -- complexity. The on-boarding process for a new organization requires evaluating and configuring a plethora of integration options, and the configuration is not always easy.
Do you use CiviCRM for contributions, pledges, and related financial data? Does your organization use the financial reports in CiviCRM? Does your organization export data from CiviCRM to your general ledger? Or do you want to start doing some of these things? If so, your input is needed on CiviAccounts. (You do not need to be a CPA to give input, but having a general understanding of how CiviCRM financial areas work currently is helpful)
I recently had a requirement to allow for export of Accounting Batches to a format that AccountEdge can use. The good news was AccountEdge has many CSV import wizards for many different types of data. The bad news was the layout of the accounting batch export CSV file from CiviCRM did not match what AccountEdge expected. So I set about creating a new export format for CiviCRM which is compatible with the "File ... Import Data ... General Journal Entries" wizard in AccountEdge.
If you’ve ever wanted to setup a repeating event in CiviCRM, for example weekly church groups, then you’ll know thats its not the most straightforward task in CiviCRM at the moment, requiring large amounts of manual labour to get the desired end result. Up steps the Zing funded MIH with a large dose of user input from Lindsey @ Woodlandschurch and others who fed back on the wiki.
Good testing is critical for providing quality software. Some testing is always manual but writing automated tests to do the heavy lifting is a key part of modern coding practices. For developers, the discipline of writing automated tests helps to proactively identify and control edge-cases, and regularly running tests helps to identify problems quickly (before they grow and cause greater harm). Fostering a healthy culture of testing requires easy, consistent, timely test-results which in turn requires an easy, consistent, quick way to setup a new test environment.
The CiviCRM community is hard at work on version 4.5 and even in its pre-alpha state I have to say it is looking really good! I'll do another blog in a few weeks about all the features and improvements users have to look forward to. But developers, this one is for you. Whether you maintain a CiviCRM extension, submit pull-requests, or develop customizations for your sites, you definitely want to read on...
When developing with CiviCRM, one often prepares a development-build on your workstation which includes several git repositories, e.g.
We've marked a new release of civix. Notable changes/improvements:
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:
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. Our goal is to come up with a list of things that we are curious about going forward and work on some potential answers during the week. So without further ado, here are some of the things that we decided to investigate and research this week:
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 ssl (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.
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.
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.
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
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:
As part of my course i have been doing research on what would it require plug an external storage engine into CiviCRM, and how other open source systems doing it. Answer lies in a better config system which allows doing it in a scalable pluggable manner. As i make progress i'll be showing more reasons to get excited and curious about building a better config system. Drupal 8 has spent a fair bit of time on configuration management to make things easier. And we shouldn't shy learning from them and others.
Just created a quick ERD for CiviCase, and shared it on this page http://wiki.civicrm.org/confluence/display/CRMDOC42/CiviCRM+ERD+3.3.
It is version 3.3, so not the latest and greatest. But I am sure I will have to check the same ERD for version 4 at a near point in the future and update the ERD too. And I do not think there are major differences in the data model......
I have also attached the ERD to this blog post.
Extensions are a growing part of the CiviCRM way of doing things. We need to develop a process and toolset to facilitate getting them translated and making those translations easily installable. This post is intended to lay out some issues and a potential approach in order to generate discussion.
Here are some assumptions and suggestions I have:
Brian Shaughnessy (lcdweb), who has been working with the New York State Senate's CiviCRM project, recently raised the issue of simultaneous editing: What happens when two users simultaneously make changes to same contact record? We've held a few discussions on IRC to examine the issue and draft some solutions. We would appreciate further feedback and ideas on how to address the issue.
As described by Brian:
Many CiviCRM customizations have been packaged and distributed as Drupal modules. This can be desirable when a customization delves into both the CMS and CRM functionality, but -- when a customization focuses only on CiviCRM -- Drupal modules are a drag: they need to be patched for CMS upgrades (D6/D7) as well as CRM upgrades (Civi 2.x/Civi 3.x), and they don't work with CiviCRM's other CMS's (Joomla and WordPress). This article introduces a proof-of-concept solution.
Last week I wrote a blog about technical debt (comparing it to keeping a kitchen in order). I got a lot of feedback - most of it constructive. I'm going to resist belabouring the whole metaphor & limit this blog to a quick summary of some of the discussion that came out of it.
Do you like to whinge about CiviCRM code? Have you sat through others doing having a rant? I've certainly done both. Being in the drupal world people often like to compare CiviCRM code with drupal & CiviCRM usually comes up a bit short. I think that's like comparing my kitchen with Bill Gate's kitchen. There are a few good reasons why my kitchen is not as nice as his. However, should I look at his kitchen (in a magazine) then I might glean a few good ideas that I could use in designing my own. (Copying the colour scheme would be in my budget :-))
The code sprint in London has finished yesterday. It's always a pleasure to see old civi friends and meet new ones. Thanks to Michael and Katy to have organized it. Time for a quick update of what I've been working on with the most obscure title I could find. My focus has been on usuability to make civicrm easier and faster to use.
Thus, functions implemented according to the API v3 conventions can be invoked several different ways. If you would like to leverage this infrastructure for use with a new or customized API call, then download the latest release. With 3.4.6/4.0.6, external developers can expose API functions for new entities, new actions, and even generic actions.