It's becoming a common request from our clients to find user-friendly ways to integrate CiviCRM data with the rest of their Drupal website functionality. Oftentimes content creators without direct user access to CiviCRM need to do simple things, such as create, update, and delete contacts in simple, specific ways.
Example Use Case
A hypothetical organization advertises various community service projects that they organize and coordinate. Each service project can have it's own page, created by adding a Project content type to display a description, images, videos, slideshows or other information for each project. You'll probably use a View to show multiple Project listings on a page. All that is standard Drupal site building content and functionality. No problem.
But what if the organization wants to display to the user the Project Coordinator(s), which they also want to store in...Read more
CiviCRM Entity is a Drupal module which greatly enhances CiviCRM integration with Drupal. This module exposes many CiviCRM entities as true Drupal entities. That means that almost any module can use Drupal entities. As a result, these modules can access and manipulate CiviCRM data directly from within Drupal via Drupal’s Entity API. This includes many commonly used modules such as Views, Rules, Search API, Entityqueue, Entity Reference, and many more.
CiviCRM Entity was originally developed by Eileen McNaughton from Fuzion....Read more
Automated tests are important when collaborating with other developers in a large project. Even if you focus your attention on a small piece of the puzzle, your piece depends on other pieces, and others may depend on you. There will be inevitable occasions when a change in one causes an unexpected change or break in another. Automated tests form the first line of defense, providing timely feedback so that problems can be addressed while the material is mentally fresh.
Testing CiviCRM is trickier than testing a basic library -- tests may involve system services (from Civi or the CMS), and CiviCRM developers may use different CMS's, file structures, and URLs. This problem can be mitigated by creating more configuration files (for each extension, test-suite, or installation), but that grows unwieldy with multiple extensions.
We've published some updated documentation and tooling to support tests in extensions. The remainder of this post assumes that you have...Read more
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:
Core service objects (such as the settings manager, logger, and JS/CSS resource manager) should be accessed through a new facade, simply named
Civi. A few examples of using this facade:
Civi::log()->info('Hello, log!'); Civi::settings()->get('versionCheck'); Civi::service('civi_api_kernel')->getEntityNames(3); Civi::resources()->addScriptFile('org.example.mymodule', 'ex.js'); Civi::$statics[__CLASS__]['tmpCacheData'] = ...;
All remaining settings from
civicrm_domain.config_backendhave been migrated to the settings framework. These may be modified, inspected, and overridden...
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. I'd like to talk a bit about this problem and a nascent project to solve it.
The cron service is a good example of an integration. Every site running Civi needs a set of cron jobs to keep the system moving -- to deliver mail blasts, to update membership statuses, to send scheduled reminders. Cron is actually a fairly simple service, but there are a lot of small variations (which are almost trivial... but...Read more
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)
Give your input via the survey at: http://pogstone.com/civicrm/petition/sign?sid=15&reset=1
(Thanks to the CiviCampaign component, I am using CiviPetition to handle my online surveys)
Background: One of the bigger structural changes to CiviCRM in the last few versions has been CiviAccounts. CiviAccounts includes many things you may use day-to-day, such as using multiple financial types within a single priceset, partial...Read more
Beginning with CiviCRM v4.6, developing code for CiviCRM (civicrm-core.git) will require two additional tools: Composer and NodeJS. If you develop CiviCRM, then you should install them in order to continue development.
Who is affected?
- NOT AFFECTED: Site administrators who install CiviCRM (from .tar.gz or .zip files) do NOT need to install these tools.
- NOT AFFECTED: Developers who write modules or extensions do NOT need to install these tools.
- AFFECTED: Developers and maintainers who work with the CiviCRM git repositories (esp. the "master" branch -- v4.6) DO need to install these tools.
What to do?
If you are a developer who works with the CiviCRM git repositories, then please ensure that these tools are installed...Read more
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.
What I had to do:
Step 1: Update list of export options to include the new choice "CSV for AccountEdge"
In recent blog posts, we've expanded the long-term support effort to 4.4, discussed the release window (first and third Wednesday of each month), and experimented with release-candidates (RCs) for some point-releases (4.4.6, 4.4.7). This renaissance in release policy prompted a discussion of whether to continue doing RCs for all future releases. The RC concept is still controversial, but we reached a consensus on a similar concept -- nightly builds -- which achieves the original goals (and then some others).
The original goals of the RC experiments were two-fold:
- "To allow system-implementers to...
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.
When Zing first approached us about the work we started with ideas and sketch of repeating events, however one of our key goals was to ensure the work became part of the core civicrm codebase and not an extension. The main reasoning behind this was to ensure that other extensions, such as CiviVolunteer and CiviBooking, could also take advantage of the repeating nature of events for their implementations. Up stepped our Core Recursion...Read more