GitLab

(NFC) Update CRM/Cxn CRM/Dashlet CRM/Export CRM/Extension and CRM/Financial files to new coder style

Load hooks during upgrade mode

For unknown, svn, reasons extension hooks are not loaded during upgrade
(this doesn't apply to drupal modules) - this causes some fairly serious problems
1) settings are re-loaded & cached with settings from extensions being lost
2) trigger alter hooks are lost this means
 - the summary fields triggers are frequently lost on upgrade
 - hooks that unset various tables to prevent them from being logged can fail, resulting in those log tables being created
 - hooks that specify the table should be innodb can fail to run, resulting in archive format.

I can't think WHY we do this? Presumably there was some problem that would have been better solved another
way but which was solved this way?

Fix "Load hooks during upgrade mode" (45312e1e64dd6af0281fe5fb7f96dbd8be39e524)

In my testing, the commit doesn't do what it says because the symbols are wrong.

[NFC] Short array syntax - auto convert settings dir

financial#2 Update new payment_processor.title field to be localisable

Improve test coverage for CRM_Utils_Color::getRgb()

Improve flushing after creating a processor so it can be used for a recurring in the same run

(REF) CRM_Core_Resources - Move hook declaration from addCoreResources() to Container.php

Include lower level data when throwing an exception on payment processor.pay

Menu config screen improvements

Mostly affects tests....

Add unit testing for activity creation when cancelling a recurring, related cleanup

Re-order upgrade to fix upgrade process and ensure there is the runSql step

tldr: It's easier to declare `hook_civicrm_buildAsset` listeners at a high-level.

Asset building can use two modes -- production mode writes a static file to
disk when it's being reference.  Debug mode just generates a URL for a
web-service (which in turn dynamically renders the content in a separate
page-view).

If the only mode were production mode, then the code would be on pretty
solid ground.  We could even simplify things a lot by changing the
AssetBuilder contract to replace the hooks with callbacks, as in:

```php
Civi::service('asset_builder')->getUrl('crm-menu.css', function() {
  return '...the css code...';
});
```

Why have a hook?  Because hooks are generally context-free and
always-available.  If we use debug-mode (or if we add a feature to warm-up
the caches during deployment), then we'll want to fire that hook from a
different context (e.g.  web-service or CLI), and the hook-listener needs to
be available in those other contexts.

It would be nice if we could declare hooks generally without needing to edit
the `Container.php` mega-file (e.g.  maybe some kind of annotation).  But,
for the moment, I think this is the best spot that we have in `civicrm-core`
for ensuring that hook listeners are fully/consistently registered.

Configurable menubar color

Ex: If an admin uses an API call (CLI/REST) to change the menubar color,
then they don't need to follow-up with a cache-clear.  The new setting just
goes live.

Ex: If a customization (via `civicrm.settings.php` or via extension) decides
on the color scheme programmatically (e.g.  per-domain or per-role or
per-user-preference), then they don't need to clear cache.  Multiple color
schemes can coexist.

Fix 4.7.31 Upgrade in multilingual mode

PHP warnings on Case Dashboard and Find Cases

Add unit test for api ContributionRecur.cancel, add support for cancel_reason

(NFC) Update CRM/Member CRM/Note CRM/Logging CRM/Import and CRM/Price…

#855 Fix guzzle noisiness

(NFC) Update CRM/Activity CRM/Admin and CRM/Batch folders to be the f…

(NFC) Update CRM/Member CRM/Note CRM/Logging CRM/Import and CRM/Price folders to be a future coder standard

There is no reason to echo the failure here

(NFC) Update coding style in PCP, Pledge, Profile, Queue, Report folders

(NFC) Update CRM/SMS/ CRM/UF/ CRM/Upgrade/ CRM/Tag/ to be up to speed…