Site Configuration includes two sections: Localization and Domain Information.

Localization handles your language, currency, default import, and internationalization settings.

In the countries and state/province sections within Localization, you choose which countries and their corresponding states/provinces are available for addresses in your system. In most cases you will select the same set of values for each field. If you have a site with multiple countries enabled, be sure to include the countries field in any forms (profiles) you create and place it before the state/province field. The state/province field will generate a list of available values based on the user's selection of a country, which means that you want to encourage people to select the country value first. Failure to do this will result in a very long list of states/provinces for all the enabled countries which will be cumbersome to work with.

CiviCRM has substantial multi-language capabilities, including the ability to have multiple languages supported within the same site (allowing the user to select their preferred translation). You must install an appropriate language file while installing CiviCRM if you want to use a language other than US English as your default. Refer to the discussion in the Installing CiviCRM section for details about the CiviCRM translation server.

Note that if you choose to make your site multi-lingual (where more than one language is available to users), it will require sufficient database user permissions and will make modifications to your database that cannot be undone. If you are unsure if you want to use this capability, consider testing the functionality on one of the CiviCRM demo sites before implementing on your own site.

Domain Information is used to configure the name of your organization, the FROM Email Address, mailing address, and other contact details. The settings here are important as they will be used as the default FROM address for system-generated and CiviMail e-mails sent from CiviCRM. Note that the e-mail address used needs to be a valid user on your hosting server in order for CiviCRM to send e-mails properly (this requirement will depend on your hosting environment configuration).

If you are planning to use CiviMail for broadcast e-mail capabilities from your site, be sure to complete the domain address fields so that it can be included in bulk e-mails. This is a good practice for any legitimate broadcast e-mailer, and is required by anti-spam legislation in some jurisdictions (for example, the American CAN-SPAM Act), and CiviMail itself.

The next configuration section, Viewing and Editing Contacts, handles settings related to contacts, including the contact record page, search settings, contact types, and address settings. We will walk through each of these areas.

Site Preferences controls what content areas are visible in different parts of the system. For example, if you are not planning to use tags as a categorization tool, you should remove it from your views. Don't need to have immediate access to the changelog (which records a running list of when edits to a contact record was made, with the name of the user and timestamp)? Remove it from your views.

The preferences are broken into four areas:

As you initially configure this section, you may be uncertain what options to select. Remember that you can always return at a later time to modify your settings. You will find whether you need or don't need certain elements listed here as you progress through the site implementation and begin working in the system.

The final option on this page lets you set your preferred WYSIWYG editor. The editor toolbar will appear on any HTML text area in your site. We recommend using the same one your CMS uses, if possible. For Joomla! users, future versions of CiviCRM will provide support for integrating the system default and user-specified WYWSIWYG editor (beginning in v3.3).

Address Settings provides similar functionality, allowing you to choose what is available for mailing label generation and the contact's address block.

Common changes to this page include removing {contact.supplemental_address_2} from the mailing label (most organizations operate with two line addresses), and hiding the Addt'l Address 2, Latitude and Longitude values. Generally, you will rely on the geocoding function to populate these values without the need for user involvement.

If you are interested in producing reports that are sorted by address, such as, walk lists for foot canvassing, then you should turn on Street Address Parsing. This enables a functionality that attempts to automatically parse the street number, street name, and unit number from the street addresses entered into the system. As of version 3.3, American, Canadian English, and Canadian French street addresses are supported.

The last setting on this page handles address standardization. CiviCRM will integrate with the USPS web tools API to validate the address entered. Note that the tool only checks if the address is valid; it does not determine if the contact name is on record at that address. Before completing this section and enabling the tool, you must apply to the USPS and receive an ID and URL. This can be done at: http://www.usps.com/webtools/address.htm.

The next configuration item in our checklist is Mapping and Geocoding. CiviCRM supports automated geocoding of addresses through Google and Yahoo!. First, visit your preferred service and obtain a key. Then, select the provider and enter your key on this page. CiviCRM will geocode the addresses as they are created or edited. When viewing a single contact record or search result list you can view a map of the address or multiple addresses (if you are looking at search results), while taking advantage of other functionality provided by Google/Yahoo!, such as plotting directions to the location.

Keys can be obtained from:

Moving on, the Search Settings controls which fields are searchable using the simple search tool, and how the search functions operate and display results. The options include:

Beyond the three primary contact types, you may create additional subtypes to categorize your records. You may also rename the existing primary types using this configuration tool. There are a few important things to remember when thinking through contact subtypes:

For a more complete review of contact subtypes and additional guidance on how to think through your system structure, refer to Chapter 4.

Having addressed core configuration and contact-related settings, we now turn our attention to e-mails generated from the system. CiviCRM may be configured to automatically generate e-mails for end user actions, such as registering for an event or making a donation. Additionally, administrators can send e-mails to one or more contacts using activities or CiviMail, the mass e-mail distribution tool. Though you are not required to use e-mail sending capabilities in order to use CiviCRM, you will miss out on a significant functionality if you choose not to.

First, set up your Outbound Email configuration at Administer | Configure | Global Settings | Outbound Email (SMTP/Sendmail), and then choose mail(), sendmail, or SMTP-based mailing mechanisms. SMTP may provide more complete bounce headers for return mail processing, though the default mail() option is generally sufficient. Your hosting provider may also have a preference, or may only support certain options. Regardless of which option you choose and configure, be sure to use the built-in testing function and confirm receipt of the e-mail. This quickly and easily ensures that the outbound e-mail is working.

Once you have tested outbound e-mail, configure the settings at Administer | Configure | From Email Addresses. When sending e-mails from CiviCRM, the logged in user's e-mail will be the default FROM address. However, you may configure additional addresses available to the system and select them while sending an e-mail.

For example, your organization might have service-based generic e-mails, such as [email protected], [email protected], and [email protected]. Depending on your hosting setup, the FROM e-mail addresses used may need to exist in your mail server as mailboxes or forwards.

The CiviMail component provides important functionality for processing the inbound e-mails. These e-mails are received and processed by the system for three purposes:

Unfortunately, configuring the return e-mail channel can be tricky, and may be one of the more technically challenging aspects of installing and configuring CiviCRM. It is much easier now than it was a few years ago, but is still an area where you may want to obtain professional support to ensure proper functioning.

Alternatively, CiviSMTP (http://civismtp.uas.coop/drupal/node/3) is a paid service that takes care of most of the technical challenges involved in setting up and running CiviMail. The service is provided by the Urban Alliance for Sustainability. While the cost is low, there are some constraints on the staff support available to users. Besides the obvious negative factor of having to pay regular fees for the service, there is a small degradation in performance that may sometimes result from having this service located external to your site's server (and potentially geographically remote to your server). That being said, this is a relatively easy-to-set-up-and-operate service that should be an attractive option for a large number of CiviCRM installations. Note that it is not an official service offered by the CiviCRM project, but is owned and operated by a third-party provider. There are many other third-party SMTP service providers that can also be integrated into CiviMail.

Before walking through configuration of the return channel processor, let's review the broader subject of maintaining a good mailing reputation.

Any broadcast e-mails sent by your system will be monitored by various spam detection systems operating on the Internet. While you do not have direct control over those systems, you do have the ability and responsibility to construct and manage your broadcast e-mail systems in such a way so as to minimize the likelihood that you will be flagged as a spammer. This process of reputation management involves domain record configuration, including sender details in your e-mails, providing unsubscribe and opt-out tools, and processing bounced e-mails so that you are not repeatedly mailing to bad e-mail addresses, and so on. Each of these things will help contribute toward lower spam scores and ensure you are able to continue reaching your constituents effectively through broadcast e-mails. In this section we will take a look at DNS (domain record) related considerations.

The first step is to set up an SPF record in the DNS for your domain, and ensure that it is correctly configured whenever you move servers. The Sender Policy Framework (SPF) identifies to the world the hosts that are specifically allowed to send e-mail from your domain, those not allowed, and others about which nothing can be said. Your CiviCRM server and domain's outbound mail server (if different), should both be identified in the SPF as "allowed to send (pass)". The more specific and limited your SPF record is, the more effective it will be in contributing toward reducing CiviMail deliverability issues. Unfortunately, users who travel with laptops through various IPs while sending e-mails may make it difficult to lock down the sender policy framework tightly.

A second useful approach to improving your server's reputation is to set up a reverse DNS. In the Sending Email section, you should have configured and successfully tested your outbound e-mail settings. In order to determine if everything is really working correctly, use CiviCRM to send an e-mail to an account you can access that is not on your server, for example a Gmail or a Hotmail account. Then, examine the e-mail header for a couple of things. In Gmail and Google Apps, you can do this by:

Look for a Received-SPF header record. It should indicate either neutral or pass. You may also find other records such as Authentication-Results: spf=neutral.

If you are having trouble with SPF, the issue can sometimes be traced to the identity that is provided by or about your server when it sends e-mails. Check through the Received: From header records until you get to your originating server, and perhaps beyond it, to your domain on a localhost. Raise any issues or questions you have with the tech support at your ISP.

Reverse DNS is the process of translating IP addresses to hostnames, the opposite of the forward DNS process, which takes the commonly used domain name and translates it to an IP address. Setting up a reverse DNS record (if not done so already) can help improve your e-mail reputation as the sending IP is validated as a legitimate sender for your domain. If your server has multiple domains sharing a single IP, it may be worthwhile to spend the small amount of money necessary to purchase a dedicated IP (useful for SSL certificates for CiviContribute, as well) so that you can set up the reverse DNS for your domain. A shared IP environment may result in your domain being scored poorly if it resides in the same bank of IPs as spammers or other accounts that are not as careful with their e-mail reputation management.

The third approach to improving your server's reputation is to monitor DNS blacklists and to request organizations that maintain these lists to remove your server from the list, if it is present. You may find yourself listed for a variety of reasons, legitimate or not, including: you haven't been processing bounces properly, recipients of your e-mail may make mistakes in their complaints, or other sites have affected your reputation. It is important to respond to blacklisting promptly as it typically propagates from one service to another.

To process the inbound e-mails, you must have an e-mail account to receive the inbound e-mails and configure a cron job to periodically process the e-mails received (addressed later in this chapter).

Although not required, you will typically want the e-mail account used for bounce processing to be dedicated for this purpose. You also would not typically want it to be a publicized account that constituents would send e-mails to. It should be created and configured solely for the purpose of bounce mail handling.

CiviMail uses Variable Envelop Return Path (VERP) processing as the method for tracking bounces. The method adds a unique sender address to every outbound message. When a bounce is returned, this unique sender address is used to determine which message, e-mail address, and contact record generated the bounce. Bounces are classified by type (whenever possible) and processed based on the rules configured in the system. Different bounce types will trigger a temporary or permanent hold placed on the e-mail, or record the delivery attempt for future processing, should there be additional bounces on the address.

The preferred setup for VERP is called sub-addressing, which uses a local part format. If your invisible bounce processing e-mail address is [email protected], then the VERP address appends a unique value after the separator but before the domain, such as [email protected]. While this is the preferred method, some ISPs deliberately prevent sub-addressing on their servers because of its prevalent use in broadcast mailing.

In order to test if you can use this approach, try sending an e-mail to the account you have set up, appending +test or test to the account before the @ symbol ([email protected]). If you receive the message successfully, then you've confirmed support for local part handling and are ready to set up the account for inbound message processing.

If sub-addressing/local part handling is not supported or you prefer not to use that method, you may still be able to process bounced e-mails using a catch-all e-mail account. A catch-all account is configured to receive all the e-mails not addressed to the other mail accounts set up on your domain—it "catches" any e-mails not "caught" by the other mail accounts. In general, catch-all accounts are less desirable as they will typically "catch" quite a bit of spam e-mails, which may be processed along with legitimate bounces. To determine if your hosting environment supports a catch-all account, log in to the system that administers your e-mail accounts and look for the option to designate an e-mail as the catch-all, or contact the hosting support to determine system capabilities. If your system supports catch-all addresses but not sub-addressing, you'll have a slightly higher load on your server, but the system should function fine.

Many CiviCRM installations run on virtual private servers. In most cases, the administrators of VPSs have the authority to configure their e-mail systems to their own needs and preferences. If you don't have the technical skills yourself, it's worth putting in a support request to have things set up the way you want.

The final way to support VERP if your e-mail system can't support either sub-addressing or catch-all addressing is to use a third-party account such as Gmail. The processing time and resource load to support processing remote e-mail stores is higher, and there may be a slight hit to your reputation if the sender domain is different from the FROM e-mail domain; but this is still a viable and effective solution. Note that depending on the system used, you may need to configure filters so that bounced e-mails are not flagged and filed as spam. For example, Gmail accounts should have a filter created that redirects anything flagged as spam back into the inbox so it can be processed by CiviCRM.

Configure CiviMail with the bounce processing account you have set up as follows:

Once the account is configured, manually check if the mail processor script is working by entering the following URL in your browser address bar, where the values in ?name=<username>&pass=<password>&key=<sitekey> are the ones explained in the Setting up Cron Jobs section below. For example:

You should receive a message in the browser window stating that the account was successfully accessed and whether any e-mails were processed. Continue testing by creating a contact record in CiviCRM with an intentionally incorrect e-mail address. Add the e-mail to a mailing list group, send a test e-mail through CiviMail, and then run the script again. This time, you should see a message that one e-mail was processed and if you review the contact record, you should see the e-mail placed on hold.

After you have confirmed that bounce processing is functioning properly, don't forget to configure a cron job as detailed later in the chapter to automate the regular processing functions.

Note that the configuration guidance outlined above covers the standard setup options for bounce processing. Other configuration options are available, such as return-path headers and alternate protocol options, which may be used if your server setup is non-standard. For more details on how these options may be used, review the online documentation or search for guidance in the forums.

It's likely that one of the reasons you've decided to implement CiviCRM is to benefit from the ability to process payments through your website, and have it immediately recorded in your contact management system. Whether you are collecting donations, campaign contributions, sponsorship commitments, pledges, membership fees, or event registration fees, all of those transactions will flow through CiviContribute.

However, before you can collect and process payments through CiviCRM, you must configure a payment processor. Your payment processor, also referred to as the payment gateway, is a service you purchase to allow credit card processing either directly through your site or through redirection to the processor's site. The processor receives the credit card, authorizes the payment, and transfers the funds to your bank (either manually or automatically, depending on the service).

Choosing what service(s) you will use can be challenging as there are many options available. You will want to make sure that whatever service you choose has a corresponding CiviCRM payment processor plugin available; otherwise, you may need to develop a new plugin to integrate with your selected service.

At the time of writing this book, the following plugins were available:

A few additional processors, including Chase Paymentech and Quickbooks, have been created or partially created, but for one reason or another, they are not fully integrated or packaged with the core software.

Not all payment processors are created equal. Some are only available in limited regions or have limitations on what currencies can be used. The structure and model for what fees are charged will also differ significantly. If you are planning to use recurring contributions, be sure to investigate if the processor will allow such functionality and ensure that it has been built into the CiviCRM plugin.

RewriteEngine On # Redirect root domain to www. form RewriteCond %{HTTP_HOST} ^yoursite.com$ [NC] RewriteRule ^(.*)$ http://www.yoursite.com/$1 [R=301,L]

System workflow templates

After completing the setup of your payment processor, return to the configuration checklist and visit the System Workflow Templates page. As people visit the CiviCRM forms on your site and you, as an administrator, work with contact records, there are various e-mails generated by the system and sent to your contacts. Each of these e-mails can be customized through this page.

If you edit any of these e-mails and save the changes, you will have the option of viewing or reverting to the original version.

The templates contain tokens that are placeholders for contact and record-specific field values. For example, if you want the e-mail to be addressed to "Dear First Name," you would insert the First Name token. When editing the template text, you may use the Insert Tokens button to insert basic contact fields.

Take care when editing templates. Most of these contain a number of conditional clauses (if/else statements) in order to ensure that the resulting e-mail is customized to the specific transaction. After making edits, make sure you test it with various options to confirm that it is functioning properly.

Note

CiviCRM uses the Smarty template engine (http://www.smarty.net) to render pages, including workflow e-mails. You may insert basic logic and make use of other Smarty functions when creating your e-mail template.

At this point you've completed the most essential steps in your initial site configuration. The Configuration Checklist includes additional sections that we will briefly review here and cover in more detail later while walking through the full implementation of their respective functions. These additional sections are Organize your contacts, Customize Data, Forms and Screens, and Components.

Although we have completed a review of the configuration checklist, there are several additional settings we want to explore. You may choose to configure these areas now, or simply make note of them and return to modify them later in your implementation process as the need arises.

As you work with CiviCRM, you'll quickly find that there are numerous option lists providing selection choices for fields. These include location types, phone types, individual prefixes and suffixes, activity types, and many more. A full list of configurable options is found on the Administration Console, and a partial list of the most frequently modified options is available in Administer | Option Lists, as shown in the following screenshot:

The available settings for each of the options will be specific to the option type. In most cases it will be self-explanatory; and most are documented with inline help text. If the option contains both a name and a label field, the name field is used for the unique option value, and the label field is what will display in the option list.

If your Joomla! or Drupal website has been in operation for some time, you likely have an existing list of website user accounts. These user accounts will not immediately have corresponding CiviCRM contact records unless the user has logged into the site and visited a CiviCRM page. As part of your initial system configuration, it is best to synchronize those CMS users with CiviCRM. Access this option by visiting Administer | Manage | Synchronize Users to Contacts.

Triggering this tool will create a linked contact record for each CMS user in your website. It should only be necessary to initiate this synchronization once. Thereafter, new CMS users will be linked to CiviCRM as they are created or visit a CiviCRM resource.

Let's take a moment and understand exactly how CiviCRM contacts relate to CMS users.

Your website (CMS) users are individuals having the permission to log in to the site using a username and password. CiviCRM contacts are records residing in your constituent database. CiviCRM creates a link between the CMS user and its corresponding CiviCRM contact record. When the user logs in to your site, you can then expose the data fields specific to that contact. For example, you could enable your logged in contacts to edit their address and phone details.

While every CMS user should have a corresponding CiviCRM contact record, the reverse is generally not true. You will typically maintain the contact records for individuals (and certainly organizations and households) that do not have a corresponding user account.

As you configure and plan your site, begin thinking through who exactly should have access to the site; what data fields might you expose to your website users for editing and updating, and what workflow you prefer for creating and granting permissions to new users.

Drupal has an effective fine-grained permissioning system built in to its core that can be extended in numerous ways through specific modules. CiviCRM extends the Drupal access control system to allow control over specific functions within CiviCRM. We will assume a basic understanding of the Drupal access control system throughout this section (visit http://drupal.org/node/22275.

Access is provided to users based on their roles and can be added or removed as a person takes on, or gives up responsibilities for accessing and administering functionality and content in CiviCRM.

Drupal sites always have two built-in roles: anonymous user (anyone who is not signed in, including those who do not have user accounts), and authenticated user (anyone who is currently signed in). Additional roles are typically created for system administrators and for groups of people who need to be allowed to do some things that others are not permitted to do, for example, moderating comments or other user-generated content.

We don't recommend creating an overly complex set of roles for CiviCRM. Ideally, you will set up permissions so that people are always allowed to do what they need to do, and aren't allowed to do things that are dangerous to the system, its data, or the organization's reputation for preserving the privacy of the personal data it holds. Often you can get by with a single role called CiviCRM administrator, and perhaps another one allowing users to view and edit financial information.

Here are the permissions that can be selectively enabled or disabled by role in Drupal at Administer | User management | Permissions:

As you can see, these permissions fall into different sorts of groups:

Drupal permissioning is cumulative—if a user is assigned three roles, the combined permissions from all three roles will determine what the user can do in the system. Because permissioning explicitly allows the specified access, if any of the three roles have been granted permission it will impact the users's access.

Three Drupal modules are included in CiviCRM that allow information about contacts in CiviCRM to be used in ways that interact usefully with the Drupal access control system.

In addition to the permissions that CiviCRM exposes to the Drupal access control permissioning system we saw above, CiviCRM has its own access control capabilities that provide finer-grained control. In general, you can control more types of operations through CiviCRM's interface. Also, you can specify subsets of data to receive permissions; for example, you can restrict editing fields on a group contact by a group of users.

To simplify configuring your access control system in both Drupal and CiviCRM, you may want to consider using the CiviGroup Roles Sync module. The same users can then be in the same CiviCRM roles, as in the Drupal roles used for Drupal access control. Giving the same names to CiviCRM and Drupal roles is a very good practice when you are adopting this approach.

A Drupal permission that can be assigned to a role tends to combine two concepts—an operation and a set of data. For example, "access comments" includes the operation of "access" and "comments" as the data to be operated on. Permissions in CiviCRM access control formalize and split these notions apart. As a result, they include three elements as follows, instead of Drupal's two:

Though this makes it a bit more cumbersome to specify permissions, it provides a very flexible structure for controlling access.

In the discussion on CiviGroup Roles Sync and CiviMember Roles Sync in the preceding section, we reviewed how to create CiviCRM access control roles (at Administer | Manage | Access Control, Manage Roles) and how to assign users to those roles (at Administer | Manage | Access Control, Assign Users to CiviCRM ACL Roles). Now it is time to put it all together and create the CiviCRM access control lists:

ACL permissioning can be tricky as you must make sure that the roles assigned to users don't conflict with each other. If you are using CiviCRM's internal granular permissioning, you must also be careful that you don't conflict with the Drupal/CiviCRM permissions assigned to the user via the Drupal role. For example, a user with access all custom data permission in Drupal would override a specific custom data set permission defined in CiviCRM.

As a general rule, take the time to do sufficient testing for any roles you've created, be it in Drupal or CiviCRM. Especially if you have sensitive information, you must be sure to restrict access to it.

When you first log in to your CMS and visit CiviCRM, you land at the Dashboard page. This page can be configured to display reports from your system in two columns. It is configured directly from this page using the Configure Your Dashboard button.

Clicking displays a visual representation of two columns and a list of available reports. Simply drag and drop from the available reports block to one of the two columns and click on Done to save your settings.

The available reports, or dashlets, come from the main reports list (Reports menu). You must configure a report to be available as a dashlet before it will appear in the Dashboard configuration page.

Throughout our review of CiviCRM, we have referenced the default location of tools and options in the horizontal navigation bar. However, you may add, move, remove, or rename the menu options in your site. For example, if your organization is a heavy user of activities (used to track communications with constituents) you may want to move the Activity Search and New Activity menu items to the main header.

You modify the navigation menu by going to Administer | Customize | Navigation Menu. The menu is displayed as an expandable tree. Click on the New Menu Item button to create a new option, right-click on an existing option to modify it, and drag and drop items to move them to a new location.

While creating or editing an option, you enter the URL for the page. Pages found within the site can be referenced using relative URLs. However, you also have the flexibility to create menu options to non-CiviCRM locations and links outside of your site using a full URL (including http://). Drupal sites will use the Permission selection tool to determine which users may see and access the menu item.

After making modifications to the menu, a notification block will appear at the top of the page. Click on the Click here link to reload the menu and review your changes.

A cron job is a time-based trigger configured on your hosting server. You set up cron jobs to automatically run scripts on a periodic basis. CiviCRM ships with several optional scripts that can be run through a cron, providing automated batch record processing for various functions.

Most hosting services will provide a control panel tool where you can schedule the cron jobs using a graphical interface. You may also set up cron jobs by using the crontab command over SSH. Different flavors of Linux also have locations you can place scripts in, in order to have them executed periodically. For example, the files in /etc/cron.daily, /etc/cron.hourly, /etc/cron.montly, and /etc/cron.weekly are executed at appropriate periods on Debian servers. We will focus on reviewing the scripts available with CiviCRM and how best to configure them. You should contact your hosting provider or seek other resources if you need guidance with creating cron jobs on your server.

Before you can run any of the CiviCRM cron scripts, you must configure a key value in your civicrm.settings.php file and create a user account permissioned to run administrative tasks on your site (in Joomla!, this must simply be a public backend user; in Drupal, the user should be permissioned to perform CiviCRM administrative tasks). The combination of a site key value and username/password help ensure that your cron jobs can only be run by a valid source. The key value should be a 16-32 character alphanumeric string. You may generate one using online services such as http://www.thebitmill.com/tools/password.html. Note that your key value should not contain any reserved special characters, including& = + $ ? % , / : { } | ' #.

The civicrm.settings.php file will generally be located in the following directory, depending on your CMS:

Locate (or create) the site key definition line and add your configured key:

define( 'CIVICRM_SITE_KEY', 'your_key_value' );

Each cron job you configure will have the following string appended to it:

?name=<username>&pass=<password>&key=<sitekey>

For Joomla!, the cron scripts are located in /path_to_docroot/administrator/components/com_civicrm/civicrm/bin/, and in Drupal, they will generally be located in /path_to_docroot/sites/all/modules/civicrm/bin/. Let's review each of the scripts that can be run through a cron job:

Note that some of the scripts require certain values be configured in the code before they can be run. Those that require configuration are saved as .txt files. You will see the section that must be configured clearly delineated with commented code. After modifying the file, remove the .txt extension so they are recognized as .php files, and then configure your cron. For example, the UpdateMembershipRecord.php file requires that you determine the FROM e-mail address used for sending out renewal reminders.

Scripts can be run via cron using curl or wget. Check with your hosting provider for their preferred method and any specific requirements for configuring the cron. The following examples may be helpful:

Note that all of the scripts can be run through the browser. If you are running into problems configuring the cron jobs, first confirm that the URLs, with username, password, and key values, are functioning correctly by entering them into your browser address bar. CiviCRM will render errors if any of those parameters are incorrect. Once you are confident that you have the correct URL, continue with the cron job configuration.

This part of the configuration process is admittedly more technical than most other areas. However, if you take the time to understand the concepts and seek assistance where necessary to wade through the technical pieces, you will find the resulting functionality very rewarding.

As with anything else, be sure to test it thoroughly. Cron jobs can generate logs that are sent to an e-mail address, which is a great way to ensure that they are functioning properly. You should also schedule periodic system reviews in order to confirm that your crons are running as expected.