CiviCRM Community Forums (archive)

I'm using buildForm hook to add js file to some contribution pages that i want to customize.

function example_civicrm_buildForm($formName, &$form) {
  var_dump($form);
  if ($formName == 'CRM_Contribute_Form_Contribution_Main' || $formName == 'CRM_Contribute_Form_Contribution_Confirm' || $formName == 'CRM_Contribute_Form_Contribution_ThankYou') {
    if ($form->_id == 1) {
      CRM_Core_Resources::singleton()->addScriptFile('com.example.crm', 'contribform-1.js');
    } elseif ($form->_id == 2) {
      CRM_Core_Resources::singleton()->addScriptFile('com.example.crm', 'contribform-2.js');
  }
}

This works as expected when you use the regular uri's:

• http://example.com/civicrm/contribute/transact?reset=1&id=1
• http://example.com/civicrm/contribute/transact?reset=1&id=2

However, I'm working on a multilang setup and when I add the lcMessages parameter to the query string to select the language, the hook is not triggered and the script file is not added.

• http://example.com/civicrm/contribute/transact?reset=1&id=1&lcMessages=nl_NL
• http://example.com/civicrm/contribute/transact?reset=1&id=2&lcMessages=fr_FR

It seems that the buildForm hook is triggered twice: before and after the form is build. However, with the lcMessages parameter added to the query string, buildForm is triggered only after the the page is build.

Is this a bug? Is there a way to work around this problem?

My setup is Drupal 7 & CiviCRM 4.2.16

Thanks

Yes, i'm sure because it works just fine without the lcMessages parameter. I need to add this parameter in order to select the right translation (id 1 is a page in dutch, id 2 is a page in french).

I've also tried a different approach. Instead of adding the lcMessages parameter to the url, i set the language in the buildform hook by setting lcMessages on the session object. This works, the script is added and the page is displayed in the right language, but not a 100% correct: the confirmation email is always in the default language and often an additional page refresh is required in order to get the language of the included profile right.

I check the ID of the contribution form in order to load a js file with jquery to customize that specific form. Maybe I should give some more background so you understand better want i want to accomplish.

• We have a bilangual (dutch and french) CiviCRM setup. Dutch is the default language.
• We want to have a fundraising page in both languages. My approach to handle this was to create 2 contribution pages, one in dutch (id=1) and one in french (id=2). I've implemented URL rewrites that append lcMessages parameter to force the contribution page to be displayed in the correct language.
• And that is where i run into trouble. When I load the page without the lcMessages parameter, the buildForm hook is triggered twice: once before the content is build and once after. In this case the js file that belongs to the form is loaded before the content is build and the jquery to customize the page is executed. When I load the page WITH the lcMessages parameter, the buildForm hook is only triggered once: after the content is build. The js is not loaded and the page remains uncustomized. This seems a bug to me. I'm on CiviCRM 4.2, i've yet to check whether this is still an issue in 4.4.

In the mean time I've implemented an ugly hack to work around the problem.

• Instead of adding an lcMessages parameter to the URL, I set the language in the buildForm hook, like so:

if ($form->_id == 1) {
  $session =&CRM_Core_Session::singleton();
  $session->set('lcMessages', 'nl_NL');
  CRM_core_Resources::singleton()->addScriptFile('com.example.civicrm', 'contribform-1.js');
} ...


• The problem here is that setting the correct language in the buildForm hook is set too late. When you switch language is the same session or when you want the page in another language than the default language, parts of the contribution page is still displayed in the incorrect language. A page refresh solves this but this is unacceptable in a production environment.
• To overcome this, i've implemented the alterContent hook where I do a str_replace to 'translate' all untranslated strings. Ugly, but it works.

Often the reason for that is a form snippet being embedded on the main form, e.g. for some extra custom data, etc.