New Extensions
Extensions are installable packages which give CiviCRM new functionality, and this directory provides a centralized list of extensions which the CiviCRM community has created.
This listing displays CiviCRM extensions that were recently added to this extension directory. We also have an RSS feed. Click here to return to the extension directory.
This extension adds a card display type for SearchKit, which allows you to create a responsive card grid from your SearchKit search results.
This extension aims to be a toolkit to help you comply with the GDPR.
What does it do?
The core of this toolkit is a new custom group where you can store consent records with your contacts. These records can be explicit or implicit consent, opt-outs, and similar things.
It integrates neatly with the UI, and gives you some search and data entry helpers.
Each record has the following fields:
date and time
category (e.g. "newsletter")
source (e.g. "main website")
type (e.g. "opt-in", "opt-out", "soft opt-in")
In addition, there are also some optional fields for each consent record:
expiry date (consent expires after the given date/time)
terms and conditions. (the full text of the TOC that the user agreed to*)
note (in case you want to add a remark)
(*) it has a clever mechanism so that it doesn't store the same TOC text over and over.
How do I use this?
Since the actions or consequences derived from the collected data differ greatly between organisations, this toolkit doesn't do anything automatically. However, it can be used as a basis for further automation, e.g. by using the SQL Tasks extension to tag contacts for deletion if the basis for a contact's retention is not there anymore.
That's it?
Yes and no. There are some additional features that might interest you as a developer:
- There is a feature to make the communication preferences read-only, in case you want to derive them from the contact's consent record.
- There is a fully functioning API
- It defines a custom hook to be triggered if the consent records are modified for a contact. This way you can add code update the contact's permissions/subscripts/whatever right away.
What's next?
We'll keep on extending the built-in functionality of this extension, while aiming to keep it compatible with earlier versions. However, since the implementation of the GDPR is very specific to the individual organisation, this will never be "plug&play" solution for any user.
Feel free to raise ticket if you have a question.
What does it do?
The core of this toolkit is a new custom group where you can store consent records with your contacts. These records can be explicit or implicit consent, opt-outs, and similar things.
It integrates neatly with the UI, and gives you some search and data entry helpers.
Each record has the following fields:
date and time
category (e.g. "newsletter")
source (e.g. "main website")
type (e.g. "opt-in", "opt-out", "soft opt-in")
In addition, there are also some optional fields for each consent record:
expiry date (consent expires after the given date/time)
terms and conditions. (the full text of the TOC that the user agreed to*)
note (in case you want to add a remark)
(*) it has a clever mechanism so that it doesn't store the same TOC text over and over.
How do I use this?
Since the actions or consequences derived from the collected data differ greatly between organisations, this toolkit doesn't do anything automatically. However, it can be used as a basis for further automation, e.g. by using the SQL Tasks extension to tag contacts for deletion if the basis for a contact's retention is not there anymore.
That's it?
Yes and no. There are some additional features that might interest you as a developer:
- There is a feature to make the communication preferences read-only, in case you want to derive them from the contact's consent record.
- There is a fully functioning API
- It defines a custom hook to be triggered if the consent records are modified for a contact. This way you can add code update the contact's permissions/subscripts/whatever right away.
What's next?
We'll keep on extending the built-in functionality of this extension, while aiming to keep it compatible with earlier versions. However, since the implementation of the GDPR is very specific to the individual organisation, this will never be "plug&play" solution for any user.
Feel free to raise ticket if you have a question.
This extension adds an api to generate and validator one time passwords. This password is send to the users email address and the user can then sign in with this password at a portal.
This extension provides an optimized batching functionality for CiviSepa. When pressing update recurring an alternative method of creating pending contributions used. One can also use this with coworker when Background Queues are enable din CiviCRM.
Turns CiviCRM "Street Address" field into modal based all-in-one address lookup field. A modern UK address autocomplete for CiviCRM forms using the Ideal Postcodes Address Finder API https://ideal-postcodes.co.uk.
Adds instant UK address autocomplete to all CiviCRM forms that contain address fields, including contact, contribution, event registration, membership, profile.
Adds instant UK address autocomplete to all CiviCRM forms that contain address fields, including contact, contribution, event registration, membership, profile.
Recurring contributions occasionally go missing — a payment processor fails silently, a webhook is dropped, or a charge is refunded without a matching CiviCRM record. Over time these gaps accumulate and contact giving histories become inaccurate.
This extension provides an admin UI and API4 endpoint to:
1. **Detect** billing periods where a recurring contribution was expected but no contribution record exists
2. **Create** the missing contributions in bulk, backdated to the expected payment date
It works with any payment processor and requires no processor-specific configuration.
This extension provides an admin UI and API4 endpoint to:
1. **Detect** billing periods where a recurring contribution was expected but no contribution record exists
2. **Create** the missing contributions in bulk, backdated to the expected payment date
It works with any payment processor and requires no processor-specific configuration.
Provides a SearchKit Task (i.e. in the Actions drop-down) to export the results to a CSV file. The export is prepared in the background and a notification email is sent when it is ready. Useful for very large exports.
This extension integrates the PayFast payment provider into the Omnipay Multi Processor Payment extension
Provides the ability to preview documents without actually downloading them using the PhotoViewer and PDF-Js libraries. It can be useful to preview files without having to leave CiviCRM and/or potentially prevent people from download confidential documents. Presently, this supports both image and PDF files.
If you have the Documents extension installed it will provide an additional View link to view uploaded documents on the Documents tab of the Contact record.
If you have the Documents extension installed it will provide an additional View link to view uploaded documents on the Documents tab of the Contact record.
Automatically logs a use out after an inactive period. This extension works with CiviCRM standalone.
This extension allows you to redirect to other Forms or Contribution Pages in the same way as using secret links/checksums.
This means you can give the user a secret link to a form instead of them logging in. They can then submit that form and be redirected
to another Formbuilder form or a Contribution Page where they will still have the same access as the original secret link.
In FormBuilder you must configure the post-submit redirect as follows:
`civicrm/affredir?csr=0&token=[token]`
such that it contains:
- csr: A number which tells the redirect which rule to use.
- token: The JWT token provided by FormBuilder.
This means you can give the user a secret link to a form instead of them logging in. They can then submit that form and be redirected
to another Formbuilder form or a Contribution Page where they will still have the same access as the original secret link.
In FormBuilder you must configure the post-submit redirect as follows:
`civicrm/affredir?csr=0&token=[token]`
such that it contains:
- csr: A number which tells the redirect which rule to use.
- token: The JWT token provided by FormBuilder.
Implements a ContributionLog entity per https://lab.civicrm.org/dev/financial/-/issues/122
