Raw Notes: CiviCRM Developer Camp - CiviCRM Internals (presented by Donald Lobo)

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.