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. The organization I work for (Freeform Solutions) is focused on doing sites for other non-profit organizations, many of whom are still running older versions of CiviCRM due to budgetary or other constraints, so we wanted to be sure that no one was running a version known to contain security vulnerabilities. Since this seemed like the sort of resource that might be useful to other CiviCRM users, I'm sharing it here.
Of course, the simplest approach is probably just making sure any given client is running the latest release of their particular CiviCRM version (4.3.x, 4.2.x, etc.). But this isn't always reliable (as pointed out by Herb in a comment below), because security fixes are not always applied to older versions (currently, versions prior to 4.2 are not being...Read more
IMPORTANT: You do NOT need to upgrade CiviCRM to remove this vulnerability. See "Prevent Attacks: Delete the Vulnerable File" below.
In recent days, multiple site admininistrators have reported evidence that their sites were attacked using vulnerabilities in the OpenFlashChart library included with prior versions of CiviCRM. This vulnerability was eliminated in the CiviCRM v4.2.6 release (Dec 2012), and site administrators were strongly advised to apply the upgrade. However, as older versions of CiviCRM are still vulnerable, site administrators running outdated versions of CiviCRM should take steps immediately to prevent new attacks and identify past attacks. This blog post provides some background and suggestions.
You can check what version of CiviCRM you are using by looking on any CiviCRM page. The version is displayed at the bottom of the screen (see screenshot...
Vanco Payment processor
BackOffice Thinking is pleased to release the Vanco payment processor to the CiviCRM community. Today we are releasing versions for 3.4x and 4.1x and hope to have a 4.2x version shortly.
This processor allows single payment and recurring for credit cards and ACH (electronic check)
The Vanco payment processor is quite popular among religious organizations and we have been utilizing this processor for past 2 years with many of our clients. Thanks for all the support from the Vanco team along way.
The files, including detailed instructions, can be downloaded here.
The installation is more involved than other...Read more
The Progressive Technology Project has compiled a list of scenarios related to doing searches from our groups’ support requests. We would like to put these forward as suggestions/modifications for Advanced Search or custom searches. Perhaps some have already been solved and are lurking quietly as custom searches that we just don’t have on our radar yet. Please share comments and reactions to these - have any of your clients needed something similar?
In case you don't know us, PTP has trained and supports over fifty community organizing groups in the US using CiviCRM, in addition to our other programmatic work. The version of CiviCRM we support is called PowerBase - it includes the CiviEngage module and CiviCampaign component that facilitate activities that all of these organizing groups do regularly to build people power.
There have been several hook() or Drupal module based solutions for "members only" pricing for events or for other 'discounts' related to memberships.
The whole concept of this code is that any 'member only' fee label must contain a specific word or phrase, in my example this word is "Member". Staff must be trained to do this - it is relatively simple to do so.
How it works:
1. Place this code in a block, selecting "full HTML" or "unfiltered" input type, and assign the block to an inconspicuous region in...Read more
Okay, I'm double-posting today in case you don't find this buried in the forum. My forum posting contains all of the details regarding a custom hack written for a client to automate 7 renewal email reminders based on expire date.
I do hope you find this useful. http://forum.civicrm.org/index.php/topic,6176.msg98034.html#msg98034
Hey gang sorry it's taken me so long to get back to you but we've been busy slogging through a few outstanding issues. For those of you who are currently in the throes of your data conversion here are a few quick words of advice.
1. Set up a local site for your data conversion so you don't run into any restrictions on how many records you can import at one time on your server, otherwise, you will spend a lot of time creating many, many small text files.
2. Learn as much as you can about the database tables and how many tables make up a single transaction. You will not be able to import all of your transaction data through the admin interface alone. I will explain about this in detail further.
3. In order to convert past events you must create separate event records for every event. There is no way to get around this that I can see. We tried to avoid this when we converted to Kintera only to be faced with it again upon converting to CiviCRM...
Notice to non-developers: This post is about how some functionality in 4.2 will be implemented in code and in the database, with very minor changes to anything visible through a browser. If you're not a developer, it probably won't interest you.
Simplifying the Codebase
As part of the CiviAccounts project we are looking to redo some of the implementation of the configuration and processing of payments for contributions, memberships, and events. Currently the processing for each of these three types of objects has two paths: one for a simple configuration of the objects, and one using price sets. This means there is more code, more complexity, more possibility of errors, more work when making changes, and more need for testing.
As we refactor the existing code we're looking at keeping the simplified UI for configuration and administration, but implementing everything under the hood using price sets. Before going ahead with that, we wanted some...Read more
The team is excited to announce the release of CiviCRM 3.4.8 and 4.0.8. This point release has quite a few bug fixes as listed here. Some of recently added features have been included in the last release blog post
If you haven't upgraded to a 3.4 / 4.0 series release yet, you may want to review the 3.4/4.0 highlights post
New and improved CiviCRM API
CiviCRM 3.4 and 4.0 bring you a new and improved API 3, designed from scratch by non-core CiviCRM developers (i.e., people who actually use the API calls on a daily basis). Your existing code utilising API...Read more
Having just had to import data that included a membership number for a client, rather than make a new field for the number it made sense to use the Contact ID, given that this is already a consecutive number and unique to each contact. The problem was that over the years there were big gaps in the consecutive numbers.
While the following is pretty straightforward, I've seen this issue brought up a number of times on the forum so I've written up what we did so that others may find their solution here! I hope its useful: