These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

Version Control

• You use svn to access most recent versions of CiviCRM code
• git is more useful for keeping track of your own changes with local commits, which is not possible in svn
• there’s a git-svn tool that pulls from a svn repo into a git repo
• code.creativecommon.org includes the cron job they use for git-svn
• branching in git is far more trivial than branching in svn
• there’s also a git-cvs tool out there (useful for Drupal code)

These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

These sessions are very hands-on, so my notes will be more sparse than normal as I try to keep up!

Session One

• CiviCRM-specific Drupal modules don’t need to go in /sites/all/modules/civicrm/drupal/modules; they can go anywhere in the modules folder (e.g. /sites/all/modules)
• Lobo advises not closing the
• CRM_Core_Error::debug - displays debug error on the screen on page load. CRM_Core_Error::debug_var dumps info to a log file in the civicrm upload directory
• When creating custom CiviCRM templates, you should save them in a directory outside of /sites/all/modules/civicrm and then tell CiviCRM where that directory is in Administer >> Configure >> Global Settings >> Directories. If your changes don’t go into effect, you need to get rid of the sites/default/files/civicrm/templates_c directory (where templates are cached) either through your filesystem (rm -rf) or by enabling Debugging in CiviCRM (Administer >> Configure >> Global Settings >> Debugging) and adding the “directoryCleanup=1″ argument to a civicrm URL (e.g. http://localhost/sandbox/civicrm/admin/setting?reset=1&directoryCleanup=1)
• When you see stuff like “CRM_Utils_Array::value”, it’s a CiviCRM class. CiviCRM classes tend to correspond to the code & directory structure, so if I go to civicrm/CRM/Utils/Array.php I’ll find a function there called “value.” Brilliant!

Session Two

• Looked at multicurrency module: http://svn.civicrm.org/tools/trunk/drupal/modules/multicurrency/ - ways to deal with currency conversion for events with international participation & managing discounts
• Also looked at multisite module: http://svn.civicrm.org/tools/trunk/drupal/modules/multisite/
• Random tip: when using the buildForm hook, $formName corresponds with the form’s .tpl file (which you can get by viewing source) 99.9% of the time

These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

• After hearing many requests for reports, CiviCRM decided to write CiviReports

These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

• Highlights in v3.0:
  • ships with 20+ premade reports
  • ability to automatically email reports via cron
  • export reports in .csv and .pdf formats
  • supports graphical reports (not just tabular, pie charts + bar charts too
• You can put all records that come up in a report into a group directly from the report view
• Report URLs accept arguments that can alter the search parameters for the report

These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

• When first creating CiviCRM Views, if CiviCRM & Drupal are in different databases (which is recommended), the user for the Drupal MySQL user in has to have permissions (perhaps just Select permissions?) for the CiviCRM database. You also have to go into CiviCRM Global Settings >> Administer >> Configure >> CMS integration and follow the instructions in the Views integration settings box to update your Drupal settings.php file.
• When you create a new view, you’ll see different CiviCRM options under View Type. Even though you select a specific view type, e.g. CiviCRM Contributions or CiviCRM Contacts, other fields that are related to those types’ tables will be available to you in your view.
• You can add the available CiviCRM fields to your view as usual. Also as usual, you can do neater, more powerful stuff by creating Relationships and Arguments in your Views that are based on the newly available CiviCRM fields.

These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

Lobo extended CiviCRM for use in his kids’ school. This is a high-level overview of what he did.

Basic Overview

• Writing a Simple Extension
  • Write a .info and .module file
  • Enable the module
  • Implement your CiviCRM and/or Drupal hooks in the .module file
• What does the module do?
  • For parents to manage their info themselves
  • update address/email/phone
  • sign up for extended care classes
  • sign up for parent teacher conference meetings
  • answer teacher questionnaires
• How did they do it?
  • Custom Groups and Fields
  • Profiles
  • Permissioned Relationships - if User A has a permissioned relationship with User B, User A can edit User B’s data.
  • Hooks
    • buildForm / postProcess
    • pageRun
    • xmlMenu
• More details
  • Used multi-record Custom Data Groups; implemented save/update via hooks
  • Customized templates to improve look of multi-record custom data groups display
  • Customized menu handlers for some functionality
  • Manage one custom table to hold data
  • Custom reports for teachers
• Code is publicly available, same CiviCRM license - http://svn.civicrm.org/sfschool/trunk

A more intensive look

• The Drupal module
  • http://svn.civicrm.org/sfschool/trunk/drupal/sfschool/sfschool.module
  • sfschool_civicrm_pageRun is the civicrm_pageRun (render a page) hook used within the sfschool module
  • Drupal takes care of all of the hook implementation
  • And this is where I get lost; think I’m missing some basic understanding of hooks, Drupal modules, etc. Might be time to finally learn that stuff! From here out I’ll take some sparse notes on key tips, resources, etc.
  • Smarty template engine: http://www.smarty.net/
  • check out civicrm/drupal/civitest.module.sample for examples of hooks implementation
  • on the CiviCRM wiki in the developer section, list of all the hooks with explanation and some examples: http://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+hook+specification
• Custom Template for Multiple Record Custom Data Groups
  • Lobo changed the view for a specific custom data group, not for the other custom groups.
  • Created two new templates: CustomDataView.tpl and StandardCustomDataView.tpl. CustomDataView.tpl has some Smarty code that tests for the right $groupId and redirects to StandardCustomDataView.tpl if it’s not the specific group ($groupId = 2) that Lobo wanted to show differently.

These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

Custom Fields & Profiles

• Custom fields come in sets; a given set of custom fields will be use to extend just one type of record (e.g. contacts, contributions, activities, events, etc), so you need to think carefully about where this information really belongs. You designate the record type that the custom data is used for at the set level, not at the individual field level, so choose carefully!
• Create and edit custom fields in Administer >> Customize >> Custom Data (v3.0 navigation structure, may not be the same in v2.x)
• Every new custom data set that you create becomes a new table in your system, named civicrm_value_your_custom_group_name_id_of_custom_group (example: civicrm_value_participant_info_16); every field you create in that custom group is a column in that table. There’s also a foreign key column to the table of the record type that this custom data group is for.
• When creating a custom field, you choose the type of data for the field and the input field type. Additional options will appear depending on the type of data and input field type you select.
• Neat data type - Contact Reference, which provides an autocomplete list of the other contacts in your database.
• There’s a hook that allows your custom field to look up options and values for a select field from an external data source.
• For Custom Data Groups created for Contacts (Contacts, Individuals, Organizations, or Households), there’s a relatively new “Does this Custom Data Group allow multiple records?” option to record multiple instances of information for a custom data group. Example: a “Past Employment” custom data group with Organization, Job Title, and Employment Dates fields; you could record many past jobs for that contact, not just one.
• Current Limitations of Custom Data Groups: Can’t export information in a custom data group with multiple records (though someone could probably right some custom SQL to do it, just can’t do it through the CiviCRM export interface); you can’t use custom data groups with multiple records in profiles.
• Create new profiles in Administer >> Customize >> CiviCRM Profile
• To include custom fields on, for example, an event registration form, you would add the custom field to a profile. When creating or editing the event registration form, you would tell it to embed that profile in the online registration form.
• You can also embed profiles in Drupal User Registration and View/Edit Drupal Users.
• Advanced Settings for profiles: limit listings to a specific group, add contacts to a group, notify when profile form is filled out, redirect URL for after profile form is submitted, cancel redirect URL for if someone cancels filling out the profile, use reCaptcha for the profile, Drupal account registration options, etc.
• Batch Update Via Profile - allows you to update records of a single type - do a search, select “Batch Update via profile” for the found set, then presented with a grid of editable fields from your selected profile for all of the contacts, including ability to propagate a value to all records in the found set.
• Can also use profiles for controlling what columns you see in advanced search; go to Settings for a Profile and select Use For > Search Results, then make sure that the individual fields in the profile are set to Public Pages or Public Pages & Listings visibility and have the “Results column?” box ticked.
• You can also invoke a search interface based on a profile by calling a profile url without “create” or anything else added to it (Fuzzy explanation, should probably look into this more)

These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

Code

• at this point, you don’t really need to touch code in CiviCRM; 80-90% of extensibility is via hooks for most platforms
• most of the codebase is in the civicrm/CRM directory
• most PHP files correspond to an equivalent TPL (template) files
• your URL -> Drupal/Joomla -> CiviCRM -> either Form, Page, or Selector (less common)
• Form - anything where you get some input from the user, collecting data - inherit from CRM_Core_Form
• Page - renders HTML, gives you links, presents data - inherit from CRM_Core_page
• each Form and Page have an associated .tpl file
• Selectors and controllers - used for things like searches where you have to display lots of things from the DB, want pagination and sorting (more advanced, we’re not going into this much right now.)
• There are cases where a form is embedded within a page or vice versa
• in past few releases, have put in hooks for all functions at the form level - you can implement a hook to modify the behavior of any forms or pages you want to change
• you can implement forms and hooks for specific profiles
• in most cases, when you implement a hook (ie change behavior), you have to also implement a custom template. When you change the PHP, you have to change the HTML
• If you View Source and search for “.tpl” you’ll see the lowest, most granular template that’s responsible for presenting that page. If you know the .tpl file, in 99% you’ll also know the corresponding .php file for rendering that page. You can also grep for the URL in the menu .xml file.
• The CiviCRM DB schema is defined in XML files which are not shipped with the production version (i.e. tarball); if installed by SVN, you get a XML directory. XML files give two types of info: SQL information and HTML information (what type of elements should be rendered, is this exportable, max length, etc). XML is processed by a script that spits out two sets of files - a .sql file and the DAO files
• When doing a new install, that .sql files (DB schema & basic CiviCRM data) are loaded into the database.
• DAO files are automatically generated; don’t mess with it if you’re hacking CiviCRM!
• each specific DAO defines all of the fields that are in a table, along with the SQL type, the HTML information - all of the operations that are done on the fields in a CiviCRM database. (Note: still cloudy on what this means; will need to do more research!)
• BAO - higher level functionality - all of the things that go into, for instance, a Contact
• Most of the work of forms and pages are done within the BAO, so that the logic can be shared amongst many things
• every table in CiviCRM has an auto-incremented field called ID - called by tablename_ID
• mixing and matching custom fields with core fields; all custom fields are pulled in via AJAX, so it’s difficult to address in the templates - not a good answer for how to inject custom fields within core fields - could use a hook (Lobo might’ve referred to a specific hook, didn’t hear - oh, I think it’s the PageRun hook) and introduce the custom fields manually
• We’re going to go deeper into hooks in later sessions!
• templates directory - files are in .tpl format - Smarty converts that to PHP and saves it in templates_c

Forms

• Every form has a five step process: preProcess, buildForm, setDefaults, validate, postProcess
• When you make a call to a form, it calls these functions to render the form: preProcess - database queries, get your data. buildForm - go add in all elements that will be rendered. setDefault - gives me all the default values for all form values. Those 3 also comprise the buildForm hook.
• When you hit submit, it calls those three functions again, then calls validate, which is also hookable in order to add in your own validations (civicrm_validate). if validate says everything is fine, postProcess is called and writes everything to the DB. postProcess is also hookable.
• define(’CIVICRM_MAIL_LOG’, ‘filename’) - sends log of mail to specified file. Specifying ‘/dev/null’ stops mail from being sent. (This doesn’t seem quite right, need to verify.)
• define(CIVICRM_DAO_DEBUG’, 1)

Page

• Page has two functions defined in CRM_Core_Page: preProcess and run().
• A lot of the work is done in preProcess; run() is very small.
• run() = get ready to display the page.
• A lot of the CiviCRM tables are very similar to each other, which is why preProcess can pull so much of the load.

DB Schema & Random

• with debug on - smartyDebug=1 added to URL (get variable) pops up another window with all of the Smarty variables and their values listed. directoryCleanup will clean up templates_c directory. sessionDebug=1 dumps contents of entire session on the screen. In General Settings when you turn on debug it explains these options.
• SmartyDebug bookmarklet from Rayogram
• civicrm_cache and civicrm_acl_cache - cache tables in the DB
• Caffeine deficiency & hunger kicking in at this point; notes are a little more scattered from here on.
• About a third of the CiviCRM tables are relatively static; anything in PseduoConstants, CiviCRM checks mem_cache.d instead of going to the database. If you change your admin stuff, you should flush your caches.
• civicrm_custom_group and civicrm_custom_field tables are meta tables - hold information about your custom groups and fields.

These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

Note: this was a little over my head, so my notes might be more muddled than usual.

• Basic File Structure
• Packages Used
  • PEAR - Quickform + DataObjects
  • Smarty - Templating
  • Jquery - AJAX Library
  • WYSIWYG Editor - FCKEditor/TinyMCE
  • PayPal and other payment processors
  • Other packages can be found in civicrm/packages
• Code Structure - PHP files and Templates
  • PHP files found in civicrm/CRM; subsequent directories are named clearly and self-evidently
  • Form directories (e.g. civicrm/templates/CRM/Contact/Form) include PHP for forms used to create and edit records, data entry; Page directories (e.g. civicrm/templates/CRM/Contact/Page) include PHP for pages used to display records
  • BAO - Business Access Object - where you define all the functions (create, add, delete, etc)
  • DAO - auto-generated by the systems - schemas defined in XML file - DAOs used for data objects
  • when you get CiviCRM from svn, no DAO files are stored in the repo, need to be generated; they are there when you get the CiviCRM tarball
• Menu Structure
  • Menus are defined in xml files (eg: Contact.xml)
  • Also an xml menu hook so you can insert your own menus/items into the CiviCRM menus

These are truly raw notes taken at the CiviCRM Developer Camp in NYC. These notes are mostly intended for and thus primarily decipherable by me, but I’m sharing them in case there’s something of use or interest for other folks.

• Usability improvements
  • Menu Redesign/Interface Changes - now a horizontal bar at top of window; fully configurable through CiviCRM administrative UI
  • Context Menus - right click on records in a search and see a list of relevant actions
  • Quick Step Actions, e.g. create a contribution and a new contact at the same time
  • Contact Summary/Edit Overhaul - more usable, streamlined, much more informative up front, less clicks!
• CiviEvent features and improvements
  • Event configuration via Tabs - no wizard! (”The wizard must die!”)
  • Event templates instead of just copying old events
  • Waitlists when event registration hits max
  • Administrator approval option - event registrants need to be approved before their registration is confirmed.
  • Event cancellation options
  • Additional registrants option (fill out one registration, add additional attendees)
• CiviReport Emergence - have done some polishing and adding reports since initial release, but the 3.0 release is the “true” debut of CiviReport
  • Alpha release of CiviReport was in v2.2.7; full release is in v3.0
  • Structure:
    • Report templates: defines general reporting area
    • Report instances: specific filters, columns, grouping applied to a selected report template
• Miscellaneous Items
  • New contribution workflow - “Create New Contact” popup when adding a new contribution, greatly streamlines the process.
  • Greetings/Addressee improvements - now can specify email greetings, postal greetings, and an addressee for mailing labels using set patterns/tokens or customized greetings for particular contacts