CiviCRM Drupal extended API

I'm currently working on a project that is heavily involved with the inner workings of drupal and CiviCRM. In the course of this I am increasingly needing to write my own hooks and calls to CiviCRM from within a drupal module. I agree that the api could get bloated and full of unnecessary functions but the fact remains, I need the data. So begins my quest to extend the tentacles of a drupal module into CiviCRM.

Features that are currently either in progress or at a point where they do the job they should and are waiting for refinement. None of this code is security tested although I do my best to keep things safe from the script kiddies.

Membership signup / Contribution block - displays a link to the contribution page.
Upcoming events block - displays a simple list of upcoming events

Events additions:

• Ability to add extra income and expenditure to an event.
• General reports pages - tabs link to events reports and CiviCRM's Reports pages

To come are:

• Augmented delegate lists - with printable badges.
• Event register - like delegate list but allows you to keep track of attendees at the event - printable

Once the module is ready you will be able to download it below.

CiviCRM hook_page for drupal

While I'm not overly competent with CiviCRM I recently needed to work on the content of a page from within a drupal module. The hook system seems to be in active development but as of v2.1.2 it hasn't got to the point of exposing the template to the hook api. I added a few lines of code to enable this. I also files a feature request for version 2.2 so hopefully it'll be added for that.

During the meanwhilst here's my effort:

edit CRM/Core/Page.php

first add

to the top of the doc.
next alter the run() method.

Now we add a corresponding hook function in CRM/Utils/Hook.php
Add this before the end of the class.

And now in your module you can write your hook.

The only thing remaining is to add this to the template which will look something like {$someVar}

IMPORTANT:
At this point we are not checking what page we are using. I suggest looking at the smartyDebug=1 info to find out what makes your page unique and check for it OR just use the arg() from drupal to get your url. This method will add the var to all pages of your site although it will not be displayed unless it is added to you template.

Drupal Ajax with JQuery

Drupal is a fantastic CMS which I have been actively developing for, for some time now. Yesterday was the first time I had really ventured into the Ajax territory but I learnt a lot and hopefully this guide should help others.

Currently this example is Drupal 5.x only. I will update it for Drupal 6 in another post in due course.

I'm going to create a simple module to demonstrate the communication between client and server. There is already a module out there that does more or less exactly what this demo will do so I'd advise using that if you require the same functionality.

The demo module will be a simple username checker for new registrants. We will add a button to the registration form which will query the server for an existing user of that name. If it already exists we put up a warning otherwise we display a confirmation that they can safely use that name.

So, to begin, we will need the .info file which looks something like this:

Okay so now we want to create the .module file. We need 3 things: we need to hook into the registration page, a menu callback for our jquery and a function for it to call.

We'll start with the menu system.

This should be fairly straightforward if you're familiar with writing modules.

Next stop, the callback function we just defined.

So what have we done here? We grab the username from the POST array and make sure it's safe to use with our db query by using check_plain(). Then we do a very simple query to see if the name exists and return the number of rows of that name. We should never get more than one but a simple check to see if it is greater than zero will suffice.

The last call before the exit() is the one we are really interested in. This handy method will convert the array we sent it into a JSON formatted string. This is very important as we will need to undo this action on the client's machine to reconstitute the data. For more information on JSON and why we use it see here

If you're happy (and you know it) that you understand everything so far, the next step will be to hook into the registration form.

At the top if this function we are adding our as-yet non-existent javascript file plus a couple of settings. These settings have been lifted almost directly from the username_check module

There's not much else to this other than a quick mention that we are passing $form by reference so any changes we make to $form will be passed back to the originator.

We can now move on to the exciting bit; the javascript. JQuery is built in to the core of Drupal but I can recommend getting hold of the jquery_update module to make sure you have a more recent version. In Drupal 6 it is up to date at the time of writing.

Create a new file called jquery_example.js and add this code:

Lets go through this. Firstly we find out if javascript is enabled for the site with the line:

if (Drupal.jsEnabled) {

Then we ask JQuery to perform our function when the document is loaded and ready.

The second line of this will tell JQuery to find the item with ID of 'edit-checkUser' (remember that Drupal adds 'edit-' to form elements) and then bind the click event to a function declared straight after.

So what are we doing? We grab the name that has been typed into the username textfield 'edit-name' by using the JQuery val() function.

We now do a call to the server with $.post(). On the JQuery website www.jquery.com the signature of this function is:

jQuery.post( url, [data], [callback], [type] )

Items in [] brackets are optional. If you look at this and apply it to our call you will see that we are reading the url from the Drupal.settings object. After this we send some data as an object {theName: username} as key-value pairs and then our callback will be the next function declaration.

Very simply this will parse the reply using Drupal's JSON parser helper and we can do what we want once we have the information back. In this case we find the message div we set up in the form and was previously hidden with $("#replyMessage").hide(); declared further down the page just inside the $(document).ready() function. Once we have the message box we set the value and tell it to unhide itself with .show();

So there you have it. A simple ajax call to the server. Perhaps as an exercise you might like to see the effects of this javascript code:

Note the new classes being added. You'll need to add these to your css file for your theme. Also the .ajaxStart() function is useful for doing things once a call to the server is being made. Disabling buttons and altering messages is a good way to inform the user that something is going on.

That's all for now. Any questions please leave a comment or contact me from the contact page.

SugarCRM with Drupal

A while ago we were charged with the task of using drupal with SugarCRM. Unlike CiviCRM, these 2 systems have never been designed to work together nicely. Rather than hack into core code to share a user table we decided to take advantage of the existing SOAP functionality that SugarCRM affords us.

Unfortunately we had to alter about 2 lines of SugarCRM's core code to get this to work. Also I don't think the code is as secure as we would like it. There is a point at which the password is sent (although encrypted) via a GET request. This would not be our preferred choice.

As a result of these imperfections I am not posting the full module here. If you would like a copy or would like to help the continuing development of this project, please get in touch and I'll see what I can do.

Things a Drupal Dev Should Know

Where to begin? There's a lot of fundamental knowledge which helps the Drupal learning curve but I've found some rules that I stick as close as possible to, to help me through the day.

Respect the core

There's a good reason to not alter the core files. Its called maintenance. Drupal allows a developer to keep custom code in only one or two locations which makes replacing core files that much easier.

If you have to alter the core files, DOCUMENT IT. A small text file for your own purposes in the root of the site could really help. Call it something obvious like README.txt or MODIFICATIONS.txt or whatever you choose, then have a clear readable structure to the doc to help you out. Here's an example:

Think of the Hackers

There are so many script kiddies around now that we constantly have to keep our guard up. In the past we had several Joomla sites compromised because the clients did not keep up maintenance or want to have any kind of support package in place so we would do it. By documenting any core module changes you can update to the latest, most secure version at a moment's notice.

When writing your code. Never output submitted text directly to the screen and never use it without checking it first in an SQL query. Let me show you a non-drupal specific example.

You are creating a login box of your own for some reason. The user has the usual username and password fields. The values of these fields go straight into a db query.

Normal user

When we get to the query:

Now for the malicious user

It may look odd but see what happens

And there you have it. An instant admin login.