CiviCRM Community Forums (archive)

I'm running CiviCRM 3.1.4 on a Drupal 6 site for a client (so this may be bug that has already been addressed, but I thought I'd post this anyway in case it is not):

Just sent a message to a fairly small number of recipients using CiviMail. The message included links to external sites and also to a couple of pages on the site (one a Drupal node and one a CiviCRM event info page), and the click tracking is enabled.

I quickly received a report from a recipient of the message that the link to the on-site Drupal page was broken, and they were getting a 'page not found' error. I checked the link  and found that the link worked perfectly for me when using Safari, but broke when using Firefox and also with Chrome (regardless of whether I was logged in to the site or not). I've yet to check it with IE.

I tested the other links in the same email, which point to third party websites and an internal CiviCRM event info page, and these work fine in all browsers that I've tested. The click-through tracking report for the message indicates that click-throughs to the on-site pages (both Drupal and CiviCRM pages) were working for at least some recipients.

The behaviour of the broken URL with Firefox was as follows:

The embedded link in the email was of the form:
http://www.example.com/sites/all/modules/civicrm/extern/url.php?u=20&qid=1057

And Firefox, having rendered a "page not found", reported the final URL as:
http://www.example.com/sites/all/modules/civicrm/extern/www.example.com/node/1622

where http://www.example.com/node/1622
is the correct URL

Anyone else seen anything like this? Has it been fixed in later versions?
anks
Graham
Th

I think you may want to check your settings.civicrm.php file and check your BASE URL variable. Is it set?  If not, try setting it and see if that helps.

Question: Can I test this on the demo site?

Hi,

Are you sure the links where correct to start with in the original email ? ie. starting with "http://" ?  The wysiwyg and copy/paste have a tendency to "translate" the links into relative urls, and brake it for instance.  Then some browsers are better as handling a specific type of broken links than others.

As for the report, is simply says that someone clicked on the link and it has been forwarded to the page. This page being 404 or not is not taken into account.

I quickly received a report from a recipient of the message that the link to the on-site Drupal page was broken, and they were getting a 'page not found' error. I checked the link  and found that the link worked perfectly for me when using Safari, but broke when using Firefox and also with Chrome (regardless of whether I was logged in to the site or not). I've yet to check it with IE.


The embedded link in the email was of the form:
http://www.example.com/sites/all/modules/civicrm/extern/url.php?u=20&qid=1057

And Firefox, having rendered a "page not found", reported the final URL as:
http://www.example.com/sites/all/modules/civicrm/extern/www.example.com/node/1622

where http://www.example.com/node/1622
is the correct URL

Xavier, thanks for your input. The email content was constructed in 'Source' view so that I could easily double-check the urls and ensure that they were not relative links. I've since gone back and taken another look as this was the most likely cause of errors (i.e. me), but it all looks to be in order.

No idea then, sorry. Is the url ok in the test emails ?

As for the click tracking report, if this is the case, then perhaps the code for the click tracking needs to be reviewed, as presumably the purpose of that report is to enable the sender to see how successful their email has been, and would therefore wish to see the number of successful click-throughs to correct target pages (assuming that this is possible to track), rather than simply some vague measure that logs solely the fact that a link was clicked on.

This would mean fetch the target pages and verify that it's not a 404 error. It can't be done at every click for obvious performance reasons. How often should it be done? And what if the page goes down between two controls and someone clicks? And what if it's accessible only from some parts of the net and not others ?  And what if it's an online video that doesn't work even if it's within a page that does? And what if this video is watchable only from some countries? And what if it redirects to a page, and that isn't the page that was intended when you sent the email? or that the page doesn't display properly in the browser of that specific visitor) and what if 

Got a few dozen more what if if you want . In essence, it isn't possible to cover all the cases, so I'd rather have civi simple and possibly wrong than complex and possibly wrong. Putting the right link and checking it works it the duty of somewhere else.

BTW the report is not vague, it properly tracks how many clicked on the link. That the link points to a correct page that is properly displayed is not a "click" issue.

This being said, all the links are stored in a table, you could develop a cron that read them, fetch the url (in practice, a HEAD request is good enough, no need to GET), and flag the invalid links in some kind of reports (or alert the user that created the mailing. You can check at other programs in the bin folder if you want to start working on it.

X+

Update: Finally found the error. Of course it was me - a simple typo. Often the hardest thing to spot I find.

Apologies to all, and thanks for your help.

Just goes to show how forgiving Safari is as a browser, that it still got me there. (Or does that make it flawed and insecure? - I guess it depends where you are coming from).

Thanks
Graham
my new motto: Measure twice, cut once.

Hmm, it's going back a little way now, but it was an embarrassingly simple error, along the lines of http:///foo.bar in a url, or maybe http://www,foo.bar
Small enough for me to miss in at least three close reads-through to try and spot it, convincing me that Civi was at fault and not me, and small enough for Safari to still reach the links correctly.