Blog posts by michal

Slight change in plans - I was promising the recipe on packaging payment processors, but we'll do custom reports first. They are second in the hierarchy of complexity after custom searches, and they smoothly introduce small new concept that will be described below.

Continuing the series, let's look at packaging payment processors. Before digging in the text below, make sure you're up to date with previous blog posts: on info file format and on packaging custom search.

As promised previously, here is the first recipe for creating your own CiviCRM extension. We'll start with the easy one - let's create an extension providing a custom search.

First, you obviously need to create your custom search, as described in documentation. Once you have the PHP class and the template, you can start packaging it. Let's say you will be doing an activity search. You need to prepare the info file as per description in previous blog post. Please note some details around info file has changed a bit since it was originally published - that's caused by integrating some of the feedback from blog comments. The info file structure shown that blog post has been updated and reflects the current structure.

This blog post is outdated. For latest information about how to create extension, please refer to Extensions Wiki Page.

It had to happen sooner or later - CiviCRM is growing with with variety of functionality, where people can plug in their own, custom pieces and make CiviCRM more tailored to their needs. Most prominent examples at the moment include payment processors, custom searches and custom reports. Don't confuse it with "larger scale" customisation, like writing Drupal modules which - using API and hooks - modify CiviCRM behaviour. We're talking about well defined, self-contained pieces of code which throw in some useful functionality into your existing installation. As of now, it's a bit of a hassle to install them - you need to put files in proper places, register them using administrator section and so on: nothing extremely complicated, but also definitely not the easiest part of CiviCRM setup and configuration. More to that, some very useful extensions (like some payment processors) are shipped with vanilla CiviCRM, but not supported by core team, some  of them are not shipped, but available only from forums or issue tracker. In general - you can find a lot of useful things, it's just requires some effort.

We just released CiviCRM 3.2.1 - it is now available for download. You can also try it out on our demo site.

Finally, the time has come. Ladies and gentlemen, without further ado, here is CiviCRM version 3.2.0, stable - it is now available for download. You can also try it out on our demo site.

This release includes several major new features/highlights: Usability improvements - Better looking and more intuitive Contact Summary Page. The new "Actions" button provides 1-click access to most contact-related forms. New clean and consistent icons have been implemented to provide helpful visual cues. You can now get a configurable contact summary pop-up from search results by mousing over the contact icon on any row. We'll be blogging with more details on these usability features during the release cycle. Support for PHP 5.3 -This release supports PHP 5.3. CiviCase Phase 3 - Thanks to the Physicians Health Program folks for pushing CiviCase to the next level! You can check out the phase 3 enhancements here. CiviEvent workflow improvements - Streamlining the workflow for events, providing 1-click access to event related screens from the configuration panel, and generating event name badges. For more details check CRM-6230 and CRM-6294. Free-tagging, and Tags for Cases and Activities - You can add one or more free-tagging "taxonomies" - called Tagsets - for use with contacts, cases and / or activities. You can also specify which tags can be used for which types of records. Standalone version dropped - Please note that we are dropping support for the Standalone version in 3.2. We recommend that current standalone users convert their installations to run under a basic Drupal install during this release cycle. ... and lots of other improvements. Check out the complete listing of new features, improvements and bug fixes on the issue tracker.

This week we're releasing CiviCRM 3.1.6 and 3.2.beta5 - they are both regular bugfix releases, however, they also bring a fix to recently discovered security vulnerability, which in specific conditions allows an unauthorized person to access some CiviCRM functionality. Please make sure you upgrade your production installations running 3.1.5 and earlier to 3.1.6 to avoid the risk.

Here we are with the fourth BETA release of version 3.2 - it is now available for download. You can also try it out on our sandbox site. Please remember this is a BETA release and it should NOT be used on production sites, even though we're getting closer to stable.

This release includes several major new features/highlights:

Here we are with the third BETA release of version 3.2 - it is now available for download. You can also try it out on our sandbox site. Please remember this is a BETA release and it should NOT be used on production sites, even though we're getting closer to stable.

Important message for translators: beta3 is a string freeze release - which means, you can safely start your 3.2 translation work - not too many new strings and/or string changes should show up to mess with your work. For more details, please refer to previous release announcement.

Now following with information about 3.2beta3: this release includes several major new features/highlights:

Here we are with the second BETA release of version 3.2 - it is now available for download. You can also try it out on our sandbox site. Please remember this is a BETA release and it should NOT be used on production sites, even though we're getting closer to stable.

With 3.2beta2 we're introducing our new translation maintenance process. It's time to announce something we called "soft string freeze" - we reviewed and checked for formal correctness the strings that are extracted for translation. Now, we are giving ourselves and our community one week, until beta3, to review our user interface and see if we need any improvements and fixes before formal string freeze. Just as a reminder, after formal string freeze, we'll do our best to avoid changing any strings in CiviCRM user interface - this way, we won't be stepping in our translators' ways and breaking ongoing translations. "Soft string freeze" means it's a last moment to take a look at your string bundles, see what has changed since 3.1, see if there is no quirks and annoyances to be fixed - and report any problems (ideally, with patches) to be fixed before formal string freeze.