CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site

This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Upgrading CiviCRM (Moderator: Deepak Srivastava) »
  • Activity details Alternatives problem after 3.2.3 upgrade
Pages: [1]

Author Topic: Activity details Alternatives problem after 3.2.3 upgrade  (Read 656 times)

grahamgilchrist

  • I post occasionally
  • **
  • Posts: 70
  • Karma: 3
Activity details Alternatives problem after 3.2.3 upgrade
October 18, 2010, 03:00:07 am
Hi there everyone,
I'm hoping someone can help with this problem. We recently upgraded from 3.1.3 to 3.2.3 and it went generally painlessly, however some of our users have complained about the body fields having disappeared from certain activity view pages. (the page at:
/civicrm/contact/view/activity?atype=2&action=view&reset=1&id=xxxxxx&cid=xxxx&context=activity )

This is most noticeable on the 'send email' activity, as our administrators frequently look at these past activities to reference the message content of previous messages, and since for this activity there is no 'edit' option they use the activity view page.

At first I thought perhaps the activities had not been saving correctly, and perhaps the activity details fields were blank, but having looked directly in the database, I found that the message content is still there, but the 'message alternative' processing is chopping it out.

In the in Activity/Form/ActivityView.tpl template, when I change the line
Code: [Select]
{$values.details|crmStripAlternatives|nl2br}to
Code: [Select]
{$values.details|nl2br}
I get the following displayed on the activity view page


-ALTERNATIVE ITEM 0-
<br />

-ALTERNATIVE ITEM 1-
**plain text message**
-ALTERNATIVE END-


It appears that for some reason, some activities (mostly sent emails, but also some others) have been saved with Alternative 0 being blank HTML (apart from line breaks etc.), and Alternative 1 being the plain text version. The template is auto selecting Alternative 0, presumably because it thinks there is some HTML there, even though it is only a <br/>, and is thus displaying nothing.
For the moment, I have removed the 'crmStripAlternatives' option from the template, so at least the users can now see the activities, but it's displays the rather ugly and confusing text above where both alternatives are listed.

This problem was not there in 3.1.3, so why should it suddenly appear in 3.2.3?
I wonder if it is related to this issue:
http://issues.civicrm.org/jira/browse/CRM-6265
which implies that the 'alternatives' order was swapped round in 3.2?

If so, does anyone have any suggestions how I can fix this so the plain text versions show up if the HTML is effectively blank?
Or is a patch needed to the stripalternatives function which treats white space, line breaks and paragraphs with no text as effectively blank html?

Any help greatly appreciated.

grahamgilchrist

  • I post occasionally
  • **
  • Posts: 70
  • Karma: 3
Re: Activity details Alternatives problem after 3.2.3 upgrade
October 18, 2010, 03:33:53 am
After some investigation, I tracked the stripalternatives PHP function to this file: CRM\utils\String.php

To solve my problem, I changed the function:
Code: [Select]
    static function stripAlternatives($full)
    {
        $matches = array();
        if (preg_match('/-ALTERNATIVE ITEM 0-(.*?)-ALTERNATIVE ITEM 1-.*-ALTERNATIVE END-/s', $full, $matches)) {
            return $matches[1];
        } else {
            return $full;
        }
    }

to this:

Code: [Select]
    static function stripAlternatives($full)
    {
        $matches = array();
        preg_match('/-ALTERNATIVE ITEM 0-(.*?)-ALTERNATIVE ITEM 1-.*-ALTERNATIVE END-/s', $full, $matches);

        if (trim(strip_tags($matches[1])) != '' ) {
            return $matches[1];
        } else {
            return $full;
        }
    }

and it seems to work fine. Does this need to be patched or am I the only one with this problem?
Patch for 3.2.3 attached in case it helps anyone else.

Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Upgrading CiviCRM (Moderator: Deepak Srivastava) »
  • Activity details Alternatives problem after 3.2.3 upgrade

This forum was archived on 2017-11-26.