Accueil
Le site des membres de Koumbit

Report back from CiviCRM Code Sprint, Albany, NY, 26-28 october 2011

I really enjoyed my time in Albany. The CiviCRM team are a bunch of kind and humble people who really make you feel at home. They clearly know their stuff and I learned a lot.

On the last day of the sprint, Mathieu and I presented our work on Aegir and provision_civicrm. Lobo was very interested in a blog post on our offering and business plan, to share with the civicrm community. In fact, he asked me to get on that again today over irc.

In terms of our goals in going to the codesprint I feel pretty good. I now have a much better handle on provision_civicrm, and the aegir backend in general, and have been able to resolve a few issues that have been holding us back from making full use of that drush module.

My actual codesprinting:

Of course I didn't spend my time just hobnobbing with the locals and civicrm devs.

I spent the first two days of the sprint working on provision_civicrm, and the fruits of my labours are this patch, which should simplify civicrm migrations in aegir, and this documentation, which should improve provision development for all.

After that I hit an issue with bootstrapping Drupal in CiviCRM, and learned more about that process than I really cared to. My notes, along with relevant links, follow.

Provision, drush, and all it's friends

I spent a substantual time reading the provision object model and code. Provision's context function, d(), does some impressive flipflops. cg or grep for it with function.+&.+d\('

The drush contexts also plaid a major part in my solution. See drush_get_context and drush_set_context for more details.

I also learned a great deal about the drush hook system, whichis quite an adjustment from Drupal's model: http://api.drush.ws/api/file/docs/drush.api.php. My use of hook_post_provision_migrate and hook_post_provision_verify are essential to my solution.

Bruteforcing Drush

My first hypothesis is that there would be a drush context through which I could pass the necessary values. But after guessing a couple times and coming up empty, I used the following code to try and figure it out:

In a hook_pre_provision_migrate:

    $contexts = drush_get_context();
    foreach($contexts as $context => $val) {
      if (substr($context, 0, 5) != 'DRUSH') {
        drush_set_option('sfyntest', 'sfyntest', $context);
      }

And in a hook_post_provision_verify:

    $contexts = drush_get_context();
    $sfyn_test = FALSE;
    $count = 0;
    while ($sfyn_test != 'sfyntest' && $count < count($contexts)) {
      $context = next($contexts);
      if (substr($context, 0, 5) != 'DRUSH' && isset($context['sfyn_test']) && $context['sfyn_test'] == 'sfyntest') {
        $sfyn_test = key($contexts);
      }
      $count++;
    }
    if ($sfyn_test) {
      die("sfyntest passed in $sfyn_test");
    } else {
      die("sfyntest not passed");
    }

Finally

I eventually settled on a different solution, which I documented on the aegir community site. That solution relies on passing values in migrate to verify via the command line basically. A bit hackish but as clean a solution as I could find.

The amazing Drupal 7 bootstrap

I looked at http://issues.civicrm.org/jira/browse/CRM-9107)">this issue, and set out to create some test mailings on my Drupal 7 install to try and reproduce the error. I had a number of configurations to do in civimail before I could do this, but I must say that my random flailings in Civi generally led me to a piece of helptext or doc that told me exactly what I need to do. I was able to feel my way through this process in about 10 minutes, mostly thanks to Civi's excellent documentation.

Still, here is a quick and dirty checklist:

  1. Configure the default mail account: civicrm/admin/mailSettings?action=update&id=1&reset=1
  2. Configure a global from address: civicrm/admin/options/from_email_address?group=from_email_address&action=update&id=414&reset=1
  3. Create a mailing list group and assign some users to it: civicrm/group/add?reset=1

While creating the actual test mailings, I ran across an issue for a long time beef of mine with civimail.

Testing the mailings

We can use wget to test the mailings via the REST api:

 wget -O - -q -t 1 'http://local.civicrm.dev/sites/all/modules/civicrm/bin/civimail.cronjob.php' --post-data='name=user&pass=pass&key=thesitekey'

Which worked fine for me. So I then tried to invoke the civimail script directly on the command line

 cd /var/aegir/platforms/civi-4/sites/all/modules/civicrm
 php bin/civimail.cronjob.php -u user -p pass -s siteurl

Which crashed with a database error. I then did a number of silly things, segfaulted php, and generally had a fine old time before giving up fot the day.

The problem

The command line program strace was very helpful for determining what was going on. When I ran it on my bootstrap test script in aegir, I noticed that the bootstrap was finding and trying to load settings.php for the site, then trying to load the database before crashing. I concluded that the structure of the settings.php file in Aegir is not friendly to the kind of bootstrapping that the Civi folks were doing.

I documented some of this in the provision issue queue. Once I tried again on a manual Drupal 7 and civi install, I was able to send mailings with both the wget and the command line command.

Commentaires

Nice!

Cool man awesome report back thanks :)

Publier un nouveau commentaire

CAPTCHA
Cette question sert à vérifier que vous êtes un visiteur humain afin de prévenir les envois automatisés (spam).
Image CAPTCHA
Enter the characters shown in the image.