Pattern used
if\s*\(\s*CRM_Utils_Array::value\s*\([ ]*(['"$0-9][^,]*),\s*(\$[^ )]*)\s*\)\s*(\&\&|\|\||\))
if \(!empty\($2\[$1\]\)$3

Pattern used:
=\s*CRM_Utils_Array::value\s*\([ ]*(['"$0-9][^,]*),\s*(\$[^ )]*)\s*\)\s*\?
= \!empty\($2\[$1\]\) \?

When I run tests over the MySQL RAM server, I'm usually running the MySQL RAM
server on a different port and I need this script in order to get that all
working in civicrm-project.

----------------------------------------
* CRM-13695: cli - set $_SERVER['HTTP_HOST'] from CIVICRM_UF_BASEURL
  http://issues.civicrm.org/jira/browse/CRM-13695

When expanding `email_greeting`, `postal_greeting`, and `addressee`
templates, after substituting the CiviCRM tokens, pass the result
through Smarty.

This way it becomes possible to include conditionals (or other types of
fancy processing) in greeting templates. Example:

  {capture assign=style}{contact.communication_style}{/capture}
  {capture assign=prefix}{contact.individual_prefix}{/capture}
  {if $style=="Familiar"}
    {if $prefix=="Frau"}
      Liebe
    {elseif $prefix=="Herr"}
      Lieber
    {else}
      Liebe/r
    {/if}
    {contact.first_name}
  {else}
    {if $prefix=="Frau"}
      Liebe Frau
    {elseif $prefix=="Herr"}
      Lieber Herr
    {else}
      Liebe/r Herr oder Frau
    {/if}
    {contact.formal_title} {contact.last_name}
  {/if}

The major limitation of this approach is that the `label` field -- where
the actual greeting templates are stored -- is limited to 255
characters. (So the above example wouldn't actually work without some
trickery to make it shorter...) Not sure how to address this problem.

We are wondering whether we should hide this feature behind a config
option, like it is done for Mailings? I'm not sure this is really
necessary here, as the Smarty processing shouldn't be in anyone's way
when unused. The only possible downside is that templates with syntax
errors might produce somewhat obscure warnings or errors in some cases.
However, the greeting templates are generally only set up during the
implementation phase, and never touched by mortal users -- just like
system workflow message templates, which use Smarty unconditionally as
well. Also, it feels wrong to hide such useful functionality behind some
obscure option...

To allow for proper Smarty escaping, this patch needs to introduce some
small changes to the way contact tokens are processed in the greetings.
These shouldn't affect other callers.

To avoid code duplication, a new function is introduced for the template
processing (tokens+Smarty), adding another layer of indirection. This
could be avoided, if replaceGreetingTokens() wasn't used in other
contexts too. (Which I believe is a misunderstanding: I'm pretty sure
the function was only meant for *generating* the greeting texts, by
replacing tokens in the greeting templates when saving a contact record;
and not for replacing greeting tokens in message templates -- the latter
should be handled just fine along with the other contact tokens...)

----------------------------------------
* CRM-13050: cli.class.php doesn't import/export custom fields with multi-select values
  http://issues.civicrm.org/jira/browse/CRM-13050

----------------------------------------
* CRM-12648: CiviCRM mailing (or other scheduled jobs) do not seem to fire when triggered via wget
  http://issues.civicrm.org/jira/browse/CRM-12648

----------------------------------------
* CRM-12647: Customization export/import crashes on "&"
  http://issues.civicrm.org/jira/browse/CRM-12647

 * When outputting commands, display repo name instead of relative path
 * Add --repos option
 * Add hidden "push" action
 * Add disabled "merge-forward" action. (This was previously drafted but ultimately went with tools/scripts/merge-forward.)

CRM-12119 replaced demo_processor with new dummy_processor file which creates dummy (test) type payment processors and sets sample event and contribution pages to use those. Also links dummy processors to appropriate financial account.

The hook functions are called by multiple repos, and we may want to tweak the behavior within each repo. The GIT_CANONICAL_REPO_NAME provides a value like "civicrm-packages" or "civicrm-core".