jaapjansma's blog

In this blog post I want to show how you could use the new form processor extension to handle form submissions from an external website.

My (imaginary) organisation provides buddies for young people and the form on our website is submitted when somebody is interested in becoming a buddy for a teenager. We ask for the name, address, e-mail, telephone number, birth date and gender.

This is a first blog post about how we build the team portal for Roparun.

I have finished a working prototype of the form-processor and action-provider extension. See my previous blog post for where the idea came from.

Below I will explain what you can do with this extension. Lets assume we have an external website where students can signup to volunteer in a summer program. When a student has signed up we want this data to be present in CiviCRM and the student added to the group student volunteers.

Last month I made a proposal for a client to integrate CiviCRM with Outlook 365. This proposal was rejected because the client did not go for an e-mail migration to Outlook 365. So the need for this plugin was gone.

The plan was that this integration would do the following:

Last week we had a Sprint in the wonderful city of Brussels. This blog post is a recap of what I have been up to.

Form Processor

I started the sprint to work on a new extension the form processor.  This idea came to my mind as I had a few clients at which I had to develop a custom api for data coming from their website (in those cases CiviCRM was separated from the website). And my idea was that I wanted to give system administrator and implementers a tool in which they could create those kind of API by themselves. So the form processor was born.

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?

This year we had a sprint after CiviCon Cologne. So far I have only been to a sprint in Edale UK. The Germans copied everything from that sprint, remote location with hardly any internet. But with Germans you know it is done well. So the internet was faster (but still slow). The remote location had a bbq place, swimming pool and sauna.

Thursday 23th and Friday 24th of March we are having a mini-sprint in the Ede (NL) in which we will fix CiviCRM bugs. We are with four of us already (Erik Hommel, Alain Benbassat, Klaas Eikelboom and me) so it is going to be fun! That is the main reason and the other reason is that we want to contribute to CiviCRM Core.

Our plan is to have two days for fixing CiviCRM bugs once in the month or once in the two months. But at least regularly and fitting to our busy schedule.

So if you are in the neighborhood we want to invite you for joining us so it going to be more fun.

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