Skip to main content

Time only goes forward, or does it? A time turner for civimail bad links!

Recently a client sent out an email with a bad link in it.

Normally, I'd sympathise with them but tell them that the horse has bolted and there's no point in closing the barn doors (because I like to use old fasioned expressions).  (And yes - if the link was on my server, I could give them an apache redirect.)

But, if the message went out via civimail and you're tracking click-throughs of links (actually this trick also works with simplenews if you're using simplenews_stats), then there's still hope.

This is because the actual link embedded in the mail isn't the final destination, but a civicrm url with a magic trackable url id, which then redirects to the final url, which is stored in a civicrm table. The rest you can probably do as a simple homework exercise, but here's the details since I've got more room for this post.

Start with loading up a mysql client and use your civicrm database, then find out the right id using this:

select * from civicrm_mailing_trackable_url order by mailing_id desc limit 30;

The first thing you'll want to do is fix that with something like

update civicrm_mailing_trackable_url set url = 'your-corrected-url' where id = the-id-of-the-bad-url;

If you caught it early enough, then you're done, but you might want to try this query as well:

select distinct contact_id from civicrm_mailing_event_trackable_url_open o inner join civicrm_mailing_event_queue q on o.event_queue_id = q.id where trackable_url_id = the-id-of-the-bad-url;

Which will give you a list of the contact ids of people who have already clicked through your bad url - in which case you can resend them the corrected version and some humble pie.

Popular posts from this blog

The Tyee: Bricolage and Drupal Integration

The Tyee is a site I've been involved with since 2006 when I wrote the first, 4.7 version of a Drupal module to integrate Drupal content into a static site that was being generated from bricolage. About a year ago, I met with Dawn Buie and Phillip Smith and we mapped out a number of ways to improve the Drupal integration on the site, including upgrading the Drupal to version 5 from 4.7. Various parts of that grand plan have been slowly incorporated into the site, but as of next week, there'll be a big leap forward that coincides with a new design [implemented in Bricolage by David Wheeler who wrote and maintains Bricolage] as well as a new Drupal release of the Bricolage integration module . Plans Application integration is tricky, and my first time round had quite a few issues. Here's a list of the improvements in the latest version: File space separation. Before, Drupal was installed in the apache document root, which is where bricolage was publishing it's co...

IATS and CiviCRM

Update, Nov 2009: I've just discovered and fixed a bug I introduced in the 2.2 branch for the IATS plugin. The bug was introduced when i updated the API files from IATS and failed to notice that the legacy method for C$ one-time donations was no longer supported. If you're using a version greater than or equal to 2.2.7, and are using IATS for C$, non-recurring donations, then you're affected . To fix it edit the file : CRM/Core/Payment/IATS.php, and remove the line that looks like this: $canDollar = ($params['currencyID'] == 'CAD'); //define currency type The full fix removes a conditional branch based on that value a little further on, but by removing this line, it'll never actually use that branch. Drop me a line if you have any questions. Update, May 2009: This post is still getting quite a bit of traffic, which is great. Here are a few important things to note: The IATS plugin code is in CiviCRM, you don't need to add any code. Y...

Orchestrating Drupal + CiviCRM containers into a working site: describing the challenge

In my previous posts, I've provided my rationale for making use of Docker and the microservices model for a boutique-sized Drupal + CiviCRM hosting service. I've also described how to build and maintain images that could be used for the web server (micro) service part of such a service. The other essential microservice for a Drupal + CiviCRM website is a database, and fortunately, that's reasonably standard. Here's a project that minimally tweaks the canonical Mariadb container by adding some small configuration bits:  https://github.com/BlackflySolutions/mariadb That leaves us now with the problem of "orchestration", i.e. how would you launch a collection of such containers that would serve a bunch of Drupal + CiviCRM sites. More interestingly, can we serve them in the real world, over time, in a way that is sustainable? i.e. handle code updates, OS updates, backups, monitoring, etc? Not to mention the various crons that need to run, and how about things ...