How to customize a few things on Contribution Forms

[Hershel]

No you can't put Javascript code into a CSS file. CSS files are for CSS code.

Javascript must go into a .js file. Or inline.

As far as running on every page, it's actually safe, meaning it won't generate an error whether or not the item in question is found. Note that the actually text after the # should be the id of the HTML object in question.

To make it run only on certain pages you can either do that via targeting the body id of your page, if that's unique for each page, or by only including this JS file on the relevant pages, via PHP code. But this is a bit more complicated. First thing is to just get it working at all--as noted, it can run on every page and it won't break anything.

 

[mdlueck]

Oh cool hershel, it actually works!

The page loads, and a second later I see the jQuery do its thing and the correct radio button is selected.

Acceptable duct-tape for now. Thank you, thank you, thank you!!! 

[Hershel]

It works? Fantastic.

Duct tape? Much better than white-out on your screen anyhow.

Glad to help.

[mdlueck]

"Duct tape" in the sense that now business logic is within our custom theme and NOT in a .php file. I am just having a very hard time understanding the positive value for putting business logic code in the theme. I also have a hard time getting my mind around business logic that is defined in the data rather than .php files on the server. Both in my mind are not the places to go searching to track down a business logic bug.

Anyway, we need to get this site LIVE, then we can work on refinements. Pre-Selecting the correct radio button is going to prevent many support contacts!!! Thank you again!!

[torrance123]

We had an issue where we had a recurring contribution form and we wanted to set the default to "I want to contribute this every XX months" and then hide the "I want to make a one time contribution" option.

In Drupal this would be a simple hook_form_alter (possibly adding your own vlidation function too). In Civi, I created my own wee module and used hook_civicrm_buildForm to edit the form as such:

Code: [Select]

function civicrm_form_alter_civicrm_buildForm($formName, &$form) {
 if ($form->_id == 2) {
    $form->setDefaults(array('is_recur' => 1));
    unset($form->_elements[$form->_elementIndex['is_recur']]->_elements[0]);
  }
}}
This works, but right off the bat the things wrong with this are:

• Accessing private properties directly (eg. $form->_elements)
• Modifying private properties directly which is much worse (ie. unset($form....))
• That this leaves a single option with a radio toggle still attached.

Still, despite these issues, I'm not sure how else we could change these. Quickform wasn't giving me the methods I needed to make the changes I wanted.

[Donald Lobo]

Would doing this via a jquery snippet be a lot easier?

Basically seems like it might be a lot easier and cleaner in this case (u hide a div for one, and set the value for the is_recur)

In the php code, u could also freeze the element, so users cannot modify it.

Yes, QF does not have nice public functions to manipulate stuff (i.e. is not very hook friendly)

lobo

[Hershel]

Would doing this via a jquery snippet be a lot easier?

I would think so. torrance123, see:

http://civicrm.org/blogs/hershel/how-customize-civicrm-pages-jquery

for ideas.

[torrance123]

No doubt it would be easier, but a big part of me feels very uneasy using javascript (or css) for anything other than page behaviour (which must degrade gracefully for those without javascript). I would only feel right about doing something like form modification on the server, not on the client, and only in the appropriate places in the server code too, or else modifications to core civi will result in spaghetti code.

Drupal's form api (and related form hooks) handles this really well, and allows for modules to radically change the form, its validation rules, and the manipulation of incoming data. I know a change to QF is on the the cards, and I'd like to throw my money behind further investigation of Drupal's fapi as a replacement.

[Hershel]

No doubt it would be easier, but a big part of me feels very uneasy using javascript (or css) for anything other than page behaviour (which must degrade gracefully for those without javascript).

This is true in many cases, but not for CiviCRM. Without Javascript, a user will not be able to use CiviCRM. Virtually at all actually. It depends on Javascript for some of its most basic functions.

[torrance123]

Without Javascript, a user will not be able to use CiviCRM.

For the backend administration of civi, it certainly appears to rely on a lot of js. But for, eg., front end contribution forms? These appear to work just fine without js (to not do so would be bug, imo). Therefore, modifications must also work without requiring js, surely.