PTP's first official contribution to the extensions repository is out: Summary Fields!
PTP folks and friends have been working hard to enhance the fundraising aspects of CiviCRM. We have big plans, and expect to release the bits and pieces as they are completed.
With the 4.3 upgrade, the Progressive Technology Project has made a number of important steps toward breaking out our work into pieces that others can use on their sites. This blog will begin a series of (hopefully) weekly blogs outlining new functionality that others can use.
Progressive Technology Project has released a new Drupal module called CiviCRM Cicero that integrates with the Cicero service from Azavea. If you are using CiviCRM with Drupal, you can now add legislative district and more information to your database.
Thanks to successful Make It Happen on consolidated cron jobs, we can set just one cron job per site.
As described in the docs, you can set this cron job using either an "URL" method or a "CLI" method.
As of the Bourne, UK sprints last August, bin/cli.php has been completely re-written for 4.1.
If you are an integrator or user, you might not have noticed this file. It used to be a PHP class that was used by many of the individual scripts in the bin directory.
Now, it's a command line program designed to be run directly.
With cli.php you can run any function defined in the API version 3.
If you run the script without any arguments, you'll get a usage statement explaining how it works:
Last spring I started working on a Drupal module that would keep CiviCRM contacts in sync with Salsa contacts. I did a lot of the work on it and then, upon joining PTP's staff, the project unfortunately fell to the bottom of my stack.
The code is available...
git clone git://git.mayfirst.org/ptp/civicrm_salsa
... but it's barely code-complete and has had absolutely no testing, so we're not releasing it yet.
CiviEngage is a Drupal module that (in the next release of CiviCRM) automatically configures CiviCampaign to make it easier to get up and running by setting many of the configuration tasks with sensible defaults.
After a big conversation at the coding sprint, we seem to be in consensus about transitioning CiviCRM's revision control system from using subversion to using git.
If you are a user or integrator that installs CiviCRM by downloading the zip or tar ball from the CiviCRM site, this transition won't affect you in any way.
If you've ever configured a schedule task (aka cron job) for CiviCRM, you know the routine. You have to look up the username and password for a user in your database that has database permissions, you have to find a really long mess of characters known as your site key, you have to find the proper name of the job you want (like UpdateAddress.php or civimail.cronjob.php) and then you must string them all together in precisely the right way to make the cron job.
What a tedious drag.
