dev/core#1460 - Implement first draft of DispatchPolicy
[civicrm-core.git] / CRM / Upgrade / DispatchPolicy.php
1 <?php
2 /*
3 +--------------------------------------------------------------------+
4 | Copyright CiviCRM LLC. All rights reserved. |
5 | |
6 | This work is published under the GNU AGPLv3 license with some |
7 | permitted exceptions and without any warranty. For full license |
8 | and copyright information, see https://civicrm.org/licensing |
9 +--------------------------------------------------------------------+
10 */
11
12 /**
13 *
14 * @package CRM
15 * @copyright CiviCRM LLC https://civicrm.org/licensing
16 */
17 class CRM_Upgrade_DispatchPolicy {
18
19 /**
20 * Determine the dispatch policy
21 *
22 * @param string $phase
23 * Ex: 'upgrade.main' or 'upgrade.finish'.
24 * @return array
25 * @see \Civi\Core\CiviEventDispatcher::setDispatchPolicy()
26 */
27 public static function get($phase) {
28
29 // Should hooks dispatch while applying CiviCRM DB upgrades? The answer is
30 // mixed: it depends on the specific hook and the specific upgrade-step.
31 //
32 // Some example considerations:
33 // - If the "log_civicrm_*" tables and triggers are to be reconciled during
34 // the upgrade, then one probably needs access to the list of tables and
35 // triggers defined by extensions. These are provided by hooks.
36 // - If a hook fires while the DB has stale schema, and if the hook's logic
37 // has a direct (SQL) or indirect (BAO/API) dependency on the schema, then
38 // the hook is prone to fail. (Ex: CiviCRM 4.x and the migration from
39 // civicrm_domain.config_backend to civicrm_setting.)
40 // - If *any* hook from an extension is called, then it may use classes
41 // from the same extension, so the classloader / include-path / hook_config
42 // should be operational.
43 // - If there is a general system flush at the end of the upgrade (to rebuild
44 // important data-structures -- routing tables, container cache, metadata
45 // cache, etc), then there's a huge number of hooks that should fire.
46 // - When hooks (or variations like "rules") are used to define business-logic,
47 // they probably are not intended to fire during DB upgrade. Then again,
48 // upgrade-logic is usually written with lower-level semantics that avoid firing hooks.
49 //
50 // Related discussions:
51 // - https://github.com/civicrm/civicrm-core/pull/13551
52 // - https://lab.civicrm.org/dev/core/issues/1449
53 // - https://lab.civicrm.org/dev/core/issues/1460
54
55 $strict = getenv('CIVICRM_UPGRADE_STRICT') || CRM_Utils_Constant::value('CIVICRM_UPGRADE_STRICT');
56 $policies = [];
57
58 // The "upgrade.main" policy applies during the planning and incremental revisions.
59 // It's more restrictive, preventing interference from unexpected callpaths.
60 $policies['upgrade.main'] = [
61 'hook_civicrm_config' => 'run',
62 '/^hook_civicrm_(pre|post)$/' => 'drop',
63 '/^hook_civicrm_/' => $strict ? 'warn-drop' : 'drop',
64 '/^civi\./' => 'run',
65 '/./' => $strict ? 'warn-drop' : 'drop',
66 ];
67
68 // The "upgrade.finish" policy applies at the end while performing the final clear/rebuild.
69 // It's more permissive, allowing more data-structures to rehydrate correctly.
70 $policies['upgrade.finish'] = [
71 '/^hook_civicrm_(pre|post)$/' => 'drop',
72 '/./' => 'run',
73 ];
74
75 // For comparison, "upgrade.old" is an estimation of the previous policy. It
76 // was applied at all times during the upgrade.
77 $policies['upgrade.old'] = [
78 'hook_civicrm_alterSettingsFolders' => 'run',
79 'hook_civicrm_alterSettingsMetaData' => 'run',
80 'hook_civicrm_triggerInfo' => 'run',
81 'hook_civicrm_alterLogTables' => 'run',
82 'hook_civicrm_container' => 'run',
83 'hook_civicrm_permission' => 'run',
84 'hook_civicrm_managed' => 'run',
85 'hook_civicrm_config' => 'run',
86 '/^hook_civicrm_(pre|post)$/' => 'drop',
87 '/^hook_civicrm_/' => 'drop',
88 '/^civi\./' => 'run',
89 '/./' => 'run',
90 ];
91
92 return $policies['upgrade.old'];
93 // return $policies[$phase];
94 }
95
96 }