Today marks the 5th stable release of CiviCRM 4.3. The CiviCRM community has truly rallied to make 4.3 the most reliable and feature-rich version yet - over 60 people contributed patches and testing to 4.3.4 alone.
This is a security release. You should upgrade your site immediately. If you are unable to do so, read the following security bulletins for alternate instructions for securing your site:
As we gear up to work on our next major milestone release CiviCRM 4.4, there's been a considerable excitement within the team for our MIH campaign. We believe the new features and new improvements to existing features outlined for 4.4 definitely will add value to the CiviCRM software.
Based on our project plan, the fundraising deadline for the MIHs is 16th of June - that is just under two weeks away.
Recently I was asked to compile a list of all CiviCRM releases since 3.1.0, identifying which were security releases so that we could make sure clients' sites were secure.
Imagine you're a non-profit employee or volunteer, responsible for managing donations. You get into the office, pick up the first coffee on the way to your desk, to find a HUGE bank statement for you to process today. Good news for your employer, not for you, because even at the rate of roughly two payments per minute, you'll be spending 19.5 hours processing them. Yay !
If you are not fundraising in any of the Single European Payment Area countries, feel free to skip this blog -- unless you want to discover how the amazing CiviCRM community is building support for what is becoming Europe's most important recurring payment instrument.
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.
A few weeks ago, I went to CiviCon. As a fairly new end-user, this was an incredible experience. Not only did I learn an insane amount of information and receive a wonderful training at the User and Admin training, but I got to interact with other people that use CiviCRM in the same way I do.
At CiviCon San Francisco, and at the sprints that followed, we spent a fair amount of time on the subject of ‘CiviCRM as a self-sufficient and financially sustainable ecosystem’. These discussions were wide ranging and super interesting (thanks to Peter Petrik from Skvare for his input and help facilitating). Following from these discussions, we have set ourselves two high level goals for the next 3 years:
I started out with CiviCRM as an end user who installed it for organization where I used to work. My colleagues and I were self-taught through trial and error, and after a little while, we understood the concepts and day-to-day contact management fairly well. However, we lacked the opportunity to fully explore functionality before diving in and using it.
