CRM_Contribute_Form_ContributionBase

Set context variable.

Constructor for the basic form page.

We should not use QuickForm directly. This class provides a lot of default convenient functions, rules and buttons

Set translated fields.

This function is called from the class constructor, allowing us to set fields on the class that can't be set as properties due to need for translation or other non-input specific handling.

Add one or more css classes to the form.

Register all the standard rules that most forms potentially use.

Simple easy to use wrapper around addElement.

Deal with simple validation rules.

Set variables up before form is built.

Called after the form is validated.

Any processing of form state etc should be done in this function. Typically all processing associated with a form should be done here and relevant state should be stored in the session

This is a virtual function and should be redefined if needed

Main process wrapper.

Implemented so that we can call all the hook functions.

The postProcess hook is typically called by the framework.

However in a few cases, the form exits or redirects early in which case it needs to call this function so other modules can do the needful Calling this function directly should be avoided if possible. In general a better way is to do setUserContext so the framework does the redirect

This virtual function is used to build the form.

It replaces the buildForm associated with QuickForm_Page. This allows us to put preProcess in front of the actual form building routine

Set the default values.

This is a virtual function that adds group and global rules to the form.

Keeping it distinct from the form to keep code small and localized in the form building code

Performs the server side validation.

Core function that builds the form.

We redefine this function here and expect all CRM forms to build their form in the function buildQuickForm.

Add default Next / Back buttons.

Getter function for Name.

Getter function for State.

Getter function for StateType.

Getter function for title.

Should be over-ridden by derived class.

Setter function for title.

Assign billing type id to bltID.

This if a front end form function for setting the payment processor.

It would be good to sync it with the back-end function on abstractEditPayment & use one everywhere.

Format the fields in $this->_params for the payment processor.

In order to pass fields to the payment processor in a consistent way we add some renamed parameters.

Format the fields in $params for the payment processor.

In order to pass fields to the payment processor in a consistent way we add some renamed parameters.

Handle Payment Processor switching for contribution and event registration forms.

This function is shared between contribution & event forms & this is their common class.

However, this should be seen as an in-progress refactor, the end goal being to also align the backoffice forms that action payments.

This function overlaps assignPaymentProcessor, in a bad way.

Handle pre approval for processors.

This fits with the flow where a pre-approval is done and then confirmed in the next stage when confirm is hit.

This function is shared between contribution & event forms & this is their common class.

However, this should be seen as an in-progress refactor, the end goal being to also align the backoffice forms that action payments.

Setter function for options.

Render form and return contents.

Getter function for renderer.

If renderer is not set create one and initialize it.

Use the form name to create the tpl file name.

A wrapper for getTemplateFileName.

This includes calling the hook to prevent us from having to copy & paste the logic of calling the hook.

Add the extra.tpl in.

Default extra tpl file basically just replaces .tpl with .extra.tpl i.e. we do not override - why isn't this done at the CRM_Core_Form level?

Error reporting mechanism.

Store the variable with the value in the form scope.

Get the variable from the form scope.

Getter for action.

Setter for action.

Assign value to name in template.

Assign value to name in template by reference.

Appends values to template variables.

Returns an array containing template variables.

Simple shell that derived classes can call to add buttons to the form with a customized title for the main Submit

Add a search for a range using date picker fields.

Based on form action, return a string representing the api action.

Used by addField method.

Return string

Classes extending CRM_Core_Form should implement this method.

Classes extending CRM_Core_Form should implement this method.

TODO: Merge with CRM_Core_DAO::buildOptionsContext($context) and add validation.

Adds a select based on field metadata.

TODO: This could be even more generic and widget type (select in this case) could also be read from metadata Perhaps a method like $form->bind($name) which would look up all metadata for named field

Adds a field based on metadata.

Add a widget for selecting/editing/creating/copying a profile form

Add date.

Function that will add date and time.

Add a currency and money element to the form.

Add currency element to the form.

Create a single or multiple entity ref field.

Convert all date fields within the params to mysql date ready for the BAO layer. In this case fields are checked against the $_datefields defined for the form and if time is defined it is incorporated

Function that can be defined in Form to override or.

perform specific action on cancel action

Helper function to verify that required fields have been filled.

Typically called within the scope of a FormRule function

Get contact if for a form object. Prioritise - cid in URL if 0 (on behalf on someoneelse) (@todo consider setting a variable if onbehalf for clarity of downstream 'if's - logged in user id if it matches the one in the cid in the URL - contact id validated from a checksum from a checksum - cid from the url if the caller has ACL permission to view - fallback is logged in user (or ? NULL if no logged in user) (@todo wouldn't 0 be more intuitive?)

Get the contact id that the form is being submitted for.

Get the contact id of the logged in user.

Add autoselector field -if user has permission to view contacts If adding this to a form you also need to add to the tpl e.g

{if !empty($selectable)}

{/if}

Add the options appropriate to cid = zero - ie. autocomplete

Set default values on form for given contact (or no contact defaults)

Sets form attribute.

Sets form attribute.

Sets page title based on entity and action.

Create a chain-select target field. All settings are optional; the defaults usually work.

Add actions menu to results form.

Assign billing name to the template.

Get the currency for the form.

Is the form in view or edit mode.

The 'addField' function relies on the form action being one of a set list of actions. Checking for these allows for an early return.

Alter line items for template.

This is an early cut of what will ideally eventually be a hooklike call to the CRM_Invoicing_Utils class with a potential end goal of moving this handling to an extension.

Assign line items to the template.

Get the configured processors, including the pay later processor.

Is the price set quick config.

Assign the minimal set of variables to the template.

Add the custom fields.

Enable ReCAPTCHA on Contribution form

Display ReCAPTCHA warning on Contribution form

Check if ReCAPTCHA has to be added on Contribution form forcefully.

Add onbehalf/honoree profile fields and native module fields.

Check template file exists.

Authenticate pledge user during online payment.

Cancel recurring contributions.

In case user cancel recurring contribution, When we get the control back from payment gate way lets delete the recurring and related contribution.

Build Membership Block in Contribution Pages.

Determine if recurring parameters need to be added to the form parameters.

• is_recur
  • frequency_interval
  • frequency_unit

For membership this is based on the membership type.

This needs to be done before processing the pre-approval redirect where relevant on the main page or before any payment processing.

Arguably the form should start to build $this->_params in the pre-process main page & use that array consistently throughout.

Get the payment processor object for the submission, returning the manual one for offline payments.