A big thank you to all our CiviCON UK Sponsors. Here's a special post from Gold Sponsor Yoti:
Doing things differently: Registrations in seconds, logins without passwords and minimising data.
Over the last 15 years I’ve probably been responsible for around 50 or so websites or microsites that in some way or another have tried to gather people’s data. Either to enter into an event, join a forum or buy something. And like most other marketeers I’ve been obsessed by two things. Funnels and Data. i.e how easily are people signing up and how much do I now know about my customers. I’ve always known that by asking people for more information there was a danger people would drop out of my acquisition funnel but we marketeers are hungry for data. We want it all and we want it now.
I’ve now come to realise that less is more. I still want the customers, and loads of them, but I want them to join me on their terms. If I ask people less about themselves I’m more...Read more
CiviCooP and Systopia and Palasthotel have been working together on CiviProxy and CiviProxy. This blog is a round up of what we have achieved in the last couple of days. The first thing we have achieved is that we had fun and a very good work atmosphere. We made long days and made lots of progress.
What are CiviProxy and CiviMcRestFace?
CiviProxy is a script to act as an application firewall for CiviCRM. It could be used to put your civicrm in secure network. CiviProxy is the gatekeeper to which external systems, such as your website, connect (this is for example when a user signs a petition on your website and the website submits this data to your CiviCRM). CiviProxy will make sure the call is from the right place (ip-adress) and is only doing what allowed to do.
CiviMcRestFace (CiviMRF) is a framework to be used in other systems (such as your external website) to connect to CiviCRM. The framework itself is...Read more
If you are a Drupal developer coming new to CiviCRM, it can be a bit of a "culture shock" to realize that CiviCRM is not your typical Drupal module.
CiviCRM has a separate and independent evolution and ecosystem, and its standard practices and APIs reflect that. From installation of the module itself, to creating customizations and modifications of its standard behavior, you are entering into a different "world" when you implement and develop client solutions with CiviCRM.
CiviCRM Entity can help a Drupal developer make the transistion by enabling them to use some of the standard Drupal API features they have grown accustommed to, while still providing insight into the data structures and interconnections of CiviCRM.
For people who spend the majority of their time developing in CiviCRM, it can feel the same way, in reverse. For all-day CiviCRM developers, CiviCRM Entity can be an...Read more
CiviCRM Entity Reference Field is a submodule of the CiviCRM Entity project. One of the many advantages of installing the CiviCRM Entity module is the ability to use Drupal’s Entity Reference module to reference CiviCRM data from nodes, terms, or other entity types. Many people are using the Inline Entity Form module, which provides field widgets that allow you to create, edit, or delete a referenced entity from the parent form.
If you reference CiviCRM contacts via an Entity Reference field and use Inline Entity Form, you’ll often want to include the ability for the user to create or edit subsidiary CiviCRM entity types, such as the email, phone, and address entities. This can get tricky with CiviCRM integration. A regular entity reference field stores a target entity id in a Drupal field table of the Drupal database. CiviCRM Addresses are stored in the CiviCRM database, and can be created by different types of users and in many different ways. In addition, Drupal and...Read more
As of CiviCRM Entity 2.0-beta4 the sub module called CiviCRM Entity Price Set Field provides a Drupal field type for the Event entity type. In this article we’ll review the features of this submodule and discuss how to configure and customize it to fit your needs.
Event Registration on the Event view page
When configured to display on the Event view pages, this field generates a registration form that supports:
- Registering multiple Participants
- Uses the event’s price set and all price fields of any type
- Pay later or credit card transactions utilizing CiviCRM’s payment processing
- Default values for the profile fields corresponding to the logged in user’s contact information ...
CiviCRM Entity 2.0-beta7 has been released.
Pick it up now at the Drupal.org Project Page
Changes since beta6:
Add Rules action Assign Contact to Group
Add Rules action Remove Contact from Group
Add Integration for IM entity
Add Integration for Website entity
Add integration for Contribution Recur
Add Rules event for CiviCRM Price Set Field 'After Successful CC Transaction'
CiviCRM Price Set Field , improved support for price fields with multiple checkboxes
Fix issues with CiviCRM Core Contribution Recur Views integration
Enable CiviCRM Entity Reference field on parent entity 'add', Inline Entity Form Single widget, for Contacts...
CiviCRM Entity is a contributed module for tightly integrating and extending CiviCRM with Drupal. This module exposes CiviCRM API entities as proper Drupal entity types. This is HUGE as it allows you to make CiviCRM data available within your favorite Drupal tools such as Rules, Views, and EntityReference. I’d like to present another advantage of Drupal entity types, and that is Drupal fields.
By enabling CiviCRM Entity, you can add Drupal fields and associate with CiviCRM entity types such as Contacts and Events. In fact, any of the hundreds of Drupal field types can be used with CiviCRM Entity. You may be asking yourself, “Shouldn’t I use a CiviCRM custom field? Why would you want to use Drupal fields?” The correct answer is, you should choose the right tool for the job.
CiviCRM is great at having the business logic and infrastructure to support event registrations. CiviCRM has price sets, price fields,...Read more
In this blog I want to explain the round up we have done around the refactoring of the acl_contact_cache. In the previous sprints we discovered that a lot of the performance was slowed down by the way the acl_contact_cache was used (or rather not used at all). See also the previous blog post: https://civicrm.org/blog/jaapjansma/the-quest-for-performance-improvements-5th-sprint
At the socialist party they have 350.000 contacts and around 300 users who can access civicrm. Most of the users are only allowed to see only the members in their local chapter.
In the previous blog we explained the proof of concept. We now have implemented this proof of concept and the average performance increase was 60%.
We created a table which holds which user has access to which contacts. We then fill this table once in a few hours. See also issue...Read more
When email was first designed, security was not considered important and up until fairly recently it was still possible to send an email from any address and get away with it.
However, as spam, phishing and spoofing attacks by email have become increasingly common there have been various attempts to make email more secure. In the last year or so the major providers (AOL, Google, Microsoft etc.) have all seriously tightened their security and authentication requirements for validating and receiving email. The result of this is that a lot of legitimate email is now being classified as spam or rejected by those providers. In order to ensure that your email continues to be marked as legitimate and received by these larger providers it is now almost essential that you implement SPF, DKIM and DMARC on your domains otherwise many of your...Read more
The last two days we spent another sprint at socialist party to improve performance. And again we used a guy with database knowledge to analyze our queries. We have optimized a few things so far one of the major areas to improve next was the ACL part of queries. That is the part of the query to decide which contacts you are allowed to see. So at the socialist party they have local chapter administrator who are only allowed to see the active members in their local area.
To decide which contacts you are allowed to see a search query is rebuild to include this ACL part. So there is a join on the membership table and a join on the chapter-structure table and then a where expression is to filter on the chapter and to filter on active memberships. Meaning that the MySQL will scan all records in the table civicrm_contact which at the socialist party is around 350.000.
We have worked on a proof-of-concept solution so far which is to create a table with the user_id and which...Read more