CiviCRM Community Forums (archive)

Hi,

I've been investigating some odd behaviour around price sets on a 4.3.8 site, e.g. when editing contribution pages, multiple new instances of price sets and price set fields being created by Civi and the membership price set select not having a default value selected, despite a price set having been selected on the last edit.

I've tracked down at least some of the weirdness to the presence of duplicate entries in civicrm_component:

mysql> select * from civicrm_component;
+----+----------------+----------------+
| id | name           | namespace      |
+----+----------------+----------------+
|  1 | CiviEvent      | CRM_Event      |
|  2 | CiviContribute | CRM_Contribute |
|  3 | CiviMember     | CRM_Member     |
|  4 | CiviMail       | CRM_Mailing    |
|  5 | CiviGrant      | CRM_Grant      |
|  6 | CiviEvent      | CRM_Event      |
|  7 | CiviContribute | CRM_Contribute |
|  8 | CiviMember     | CRM_Member     |
|  9 | CiviMail       | CRM_Mailing    |
| 10 | CiviGrant      | CRM_Grant      |
| 11 | CiviPledge     | CRM_Pledge     |
| 12 | CiviCase       | CRM_Case       |
| 13 | CiviReport     | CRM_Report     |
| 14 | CiviCampaign   | CRM_Campaign   |
+----+----------------+----------------+

I've found some places in the code that use hard-coded component ids and others that use CRM_Core_Component::getComponentID(), e.g. two examples from CRM/Member/Form/MembershipBlock.php :

line 69 on:
    if ($this->_id &&
      ($priceSetId = CRM_Price_BAO_Set::getFor('civicrm_contribution_page', $this->_id, 3, 1))
    ) {
      $defaults['member_price_set_id'] = $priceSetId;
      $this->_memPriceSetId = $priceSetId;
    }
    else {
      // for membership_types
      // if ( isset( $defaults['membership_types'] ) ) {
      $priceSetId = CRM_Price_BAO_Set::getFor('civicrm_contribution_page', $this->_id, 3);
      $this->assign('isQuick', 1);

- The 3 passed as third parameter to CRM_Price_BAO_Set::getFor() is $usedFor:
   * @param int    $usedFor ( price set that extends/used for particular component )
Which I believe is a component id. So here, the component ID of CiviMember is hard-coded as 3.

Later in the same file, line 348 on of CRM/Member/Form/MembershipBlock.php:
          $setParams['extends'] = CRM_Core_Component::getComponentID('CiviMember');
Here the component ID of CiviMember is looked up with CRM_Core_Component::getComponentID('CiviMember'), which on this site returns 8, the id of the second entry in civicrm_component for 'CiviMember'. The duplicate entries in civicrm_price_set have `extends` = 7 or 8, the ids of the 2nd entries for 'CiviContribute' and CiviMember'.

First question is how to sort out the mess! Looking on a working 4.3.8 site, we have:

mysql> select * from civicrm_component;
+----+----------------+----------------+
| id | name           | namespace      |
+----+----------------+----------------+
|  1 | CiviEvent      | CRM_Event      |
|  2 | CiviContribute | CRM_Contribute |
|  3 | CiviMember     | CRM_Member     |
|  4 | CiviMail       | CRM_Mailing    |
|  5 | CiviGrant      | CRM_Grant      |
|  6 | CiviPledge     | CRM_Pledge     |
|  7 | CiviCase       | CRM_Case       |
|  8 | CiviReport     | CRM_Report     |
|  9 | CiviCampaign   | CRM_Campaign   |
+----+----------------+----------------+
Which makes me think...
- The duplication in civicrm_component occurred on a much earlier version of Civi, after CiviGrant was added but before CiviPledge, so before Civi 2.1.
- We have a problem if there are other places in the code where component ids are hard-coded. E.g. in the working site, id 8 = CiviReport, in the broken site ids 3 and 8 = CiviMember.
- We potentially have a problem anywhere in the database where a component id is stored, e.g. in the `extends` column in civicrm_price_set, as either of two ids could be present for CiviEvent, CiviContribute, CiviMember, CiviMail or CiviGrant.

I guess to fix, we'll need to restore civicrm_component to what it is on a normal 4.3.8 site and then find and change manually every reference to component ids 6, 7, 8, 9 & 10 in the entire database. :-(

If we leave civicrm_component as is and change the hard-coded component ids in CRM/Member/Form/MembershipBlock.php and any others we find to use CRM_Core_Component::getComponentID(), then these will pick up the higher ids (6-10), so will not match records which use the lower ids (1-5), such as the reserved price sets in civicrm_price_set.

Has anyone come across this before or have any advice?

Thanks,

Dave