CiviCRM Community Forums (archive)

I have configured an event with online registration enabled and included both a top of the page profile and a bottom of the page profile, but on the registration page, only the top of the page profile is appearing. I've tried changing the profiles to various others thinking one of the profiles might be the issue, but it doesn't make a difference. I cannot get the bottom-of-the-page profile to appear on the registration page. Anyone else run into this?

I have configured an event with online registration enabled and included both a top of the page profile and a bottom of the page profile, but on the registration page, only the top of the page profile is appearing.

We've just done an upgrade from 3.3.2 to 3.4.5 and are running into the same issue.   Seems to be related to access.  Some additional observations in our case

- Have tried various combinations of profiles with and without custom data and migrated by  from our upgraded as well as news ones.

- I've tried creating a brand new event with 2 simple profiles (each with default settings) each with one non-custom field of type participant. I've added these to my new test event.

- When I then visit the event page, as a logged in user,  I only see the first profile.  The header of the 2nd profile is not rendered.

If I access the site as an anonymous user, both profiles appear as expected.

- if I switch the order of the 2 profiles, always the first one listed on the configuration page  is rendered to me as a logged in user. In other words, both appear to have valid fields for the event.

- I'm not having trouble with my contribution pages - both profiles appear there as expected.

Does this help pointpoint a problem? I can try to reproduce it on demo.

Good to hear I'm not the only one.

I've created a new event on demo to try to test it. On demo, the profiles are working as expected for this event I created:

http://drupal.demo.civicrm.org/civicrm/event/register?reset=1&action=preview&id=9

Any suggestions as to what we should check on our instances where this doesn't seem to be working quite right?

Thanks,

Aaron

I have the same problem on 4.0.8, and can confirm the fix.

Ok, the issue seems to be that when CRM/Event/Form/Registration.php calls filterUFGroups...

if ( CRM_Core_BAO_UFGroup::filterUFGroups($id, $contactID)  )
...it is passing an array for $id rather than the actual id of the profile. So when CRM/Core/BAO/UFField.php eventually is invoked (via CRM/Core/BAO/UFGroup.php) it is returning a null value for profile type and the profile is not showing up.

The code below allows CRM/Core/BAO/UFField.php to handle the array, but it doesn't answer the larger question of why Registration.php is passing a variable when the user is anonymous and an array when the user is logged in. The quick fix: in UFField.php find static function getProfileType and replace...

$ufGroup->id          = $ufGroupId;
With...

if (is_array($ufGroupId)) {
  $ufGroup->id = $ufGroupId[0];
} else {
  $ufGroup->id = $ufGroupId;
}


I believe this is fixed in 4.1 - I diagnosed it & found that this

UPDATE uf_match SET is_active = 0 WHERE id = 1;

makes it go away

http://issues.civicrm.org/jira/browse/CRM-9653

It was fixed in 4.1 through other refactoring (ie. was already fixed in 4.1 by the time I filed the ticket)

Hmm - I didn't try replicating on 4.1 - I just took Yashi's word for it.

You could try the patch as described in here

http://issues.civicrm.org/jira/browse/CRM-9653

Eileen - in your query above and in the referenced bug, did you mean


UPDATE uf_match SET is_active = 0 WHERE id = 1;
 
or

UPDATE uf_group SET is_active = 0 WHERE id = 1;

Thanks,

Aaron