We have a node called sponsorship that is a person, place, or thing. Person is likely a child, but it could be a teacher, nurse, etc. A person generally has one donor that pays a monthly amount. A place could be a building that would have one or more donors, and a thing is an resource; such as a projector.

Using a View we would allow the site visitor to review the opportunities for sponsorship. When the user clicks on "donate" (or "sponsor") in the view, we want to associate the donation with the item they are sponsoring. If the item is fully covered by a donation the item status would change and it would no longer we displayed to a site visitor.

We are looking for suggestions on how we should proceed.

  • How many pages are you talking about? I can't think how you might do this other than by having a unique Contribution page or Personal Campaign Page for every entity that could be sponsored and then figuring a way to set the 'page' to be closed when the target is met (or at least in the view use some php to compare the amount raised for that 'page' with the 'goal' and not display that row if X > Y)
    – petednz - fuzion
    Commented May 23, 2015 at 4:05
  • estimate of 40 to 220 items that could be identified for sponsorship (mostly children). Would be possible to have three types of contributions (Person, Place, Thing) and then associated the sponsorship node with the contributor. If a contribution stops or the sponsorship need reaches an end point (child graduates, etc.) we need to make the appropriate decisions for funding.
    – mike_kc
    Commented May 23, 2015 at 15:50

2 Answers 2


There are a bunch of ways to tackle this. I think the approach you're describing of using Views might be writing a bit more custom code than need be, but I'll work within those constraints.

First, @petednz has the right general approach - store some data in the contribution tying it to the entity being sponsored, and use PHP in the View to determine whether to show/hide the entity in the View.

Personally, I'd use the principles outlined in this page to embed a variable in the URL that gets stored in a hidden field on the contribution page, and ultimately as custom data on the contribution. This gets around needing to have a separate contribution page for each entity. The page is a bit dated IMO, but the general principle is sound.

  • One caveat about using a contribution page is that there is no API (that I'm aware of) to automatically add things like "widgets" or "PCP" so this will be a lot to manage. I'm working on something similar. Commented Aug 26, 2015 at 19:14

I'm not sure how the "things" would fit into this model, but I might begin to tackle the child/person sponsorship this (Drupal-specific) way:

  • Create a custom field for individuals (and/or potentially use a separate sub-type based on Individual) to indicate that they are available for sponsorship
  • Create a relationship such as "Sponsor of/Sponsored by"
  • Create a View that lists all contacts that are available for sponsorship and do not have an active "Sponsor of/Sponsored by" relationship
  • Create a Membership type with the settings for your sponsorship(s) (e.g. monthly/annual/etc.) Potentially use Word Replacement (Administer > Customize Data and Screen > Word Replacement) to change "Membership" to "Sponsorship".
  • Create a custom Webform-CiviCRM form that has two contacts: first contact is the sponsor (filling the form), second contact is the person to be sponsored (this could be filled via the URL with contact ID so links from the View could prefill this value, and/or an autocomplete field for searching). This form could also be set up to take a required contribution towards a membership/sponsorship of the type you created. The form could also be set up to create a relationship between the two contacts (which should then remove the second contact from the list of people available for sponsorship).

Obviously thorough testing would be needed, and I don't recall off-hand whether Webform-CiviCRM allows you to set up recurring payments or if you'd have to rely on membership reminders to have them come back to make subsequent payments.

I suppose the places could be set up in a similar way using a subtype of Organizations, potentially with different rules in Views (for example, you may want to allow any number of people to sponsor a place, I don't know).

Some of your more complex functionality may be more difficult to fit in (such as partial payments or a combined sponsorship among multiple people), and I'm not sure about how I'd handle the things (like projectors) in this model.

EDIT: It would be a different workflow then described above for the 'things' but you might be able to set up a contribution page with these items as the 'premiums' offered. (e.g. "Make a donation of at least $150 and you can select a projector for a school...")

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.