double-opt-in / src / Providers / HealthServiceProvider.php

HealthServiceProvider.php in Double Opt-In for Contact Form 7 – Secure, GDPR-Compliant Email Verification 5.8.0, at src/Providers/HealthServiceProvider.php

117 lines 3.4 KB

Raw Download Zip

1	<?php
2	/**
3	* Health Service Provider
4	*
5	* @package Forge12\DoubleOptIn\Providers
6	* @since 5.3.0
7	*/
8
9	namespace Forge12\DoubleOptIn\Providers;
10
11	use Forge12\DoubleOptIn\Container\BootableProviderInterface;
12	use Forge12\DoubleOptIn\Container\Container;
13	use Forge12\DoubleOptIn\Health\DatabaseTableHealthCheck;
14	use Forge12\DoubleOptIn\Health\HealthCheckRegistry;
15	use Forge12\DoubleOptIn\Health\HealthRepairController;
16	use Forge12\DoubleOptIn\Health\LegacyMonolithCheck;
17	use Forge12\DoubleOptIn\Health\SiteHealthIntegration;
18	use Forge12\DoubleOptIn\Health\StaleConsentFieldCheck;
19	use Forge12\DoubleOptIn\Health\StaleProMarkersCheck;
20	use Forge12\DoubleOptIn\Health\AddonCompatibilityCheck;
21
22	if ( ! defined( 'ABSPATH' ) ) {
23	exit;
24	}
25
26	/**
27	* Class HealthServiceProvider
28	*
29	* Wires the health-check registry and its Site Health surfaces.
30	*
31	* Registration of addon checks happens through the
32	* `f12_doi_health_checks` filter, which the registry applies lazily on
33	* first read — so this provider does not need to run after addon boot,
34	* and addons do not need a Core new enough to know about this API.
35	*
36	* Only the Core's own tables are registered here. They are the three
37	* that `OnActivation.php` creates; if one of them is missing the plugin
38	* is broken in a way that has, historically, only shown up as a silent
39	* failure much later.
40	*/
41	class HealthServiceProvider implements BootableProviderInterface {
42
43	/**
44	* {@inheritdoc}
45	*/
46	public function register( Container $container ): void {
47	$container->singleton(
48	HealthCheckRegistry::class,
49	function () {
50	return new HealthCheckRegistry();
51	}
52	);
53	}
54
55	/**
56	* {@inheritdoc}
57	*/
58	public function boot( Container $container ): void {
59	$registry = $container->get( HealthCheckRegistry::class );
60
61	$optInsUrl = admin_url( 'admin.php?page=f12-doi-admin' );
62
63	$registry->register(
64	new DatabaseTableHealthCheck(
65	'f12_doi_table_optin',
66	'core',
67	'f12_cf7_doubleoptin',
68	__( 'Opt-in records', 'double-opt-in' ),
69	__( 'Open Double Opt-In', 'double-opt-in' ),
70	$optInsUrl
71	)
72	);
73
74	$registry->register(
75	new DatabaseTableHealthCheck(
76	'f12_doi_table_categories',
77	'core',
78	'f12_cf7_doubleoptin_categories',
79	__( 'Opt-in categories', 'double-opt-in' ),
80	__( 'Open Double Opt-In', 'double-opt-in' ),
81	$optInsUrl
82	)
83	);
84
85	$registry->register(
86	new DatabaseTableHealthCheck(
87	'f12_doi_table_audit_log',
88	'core',
89	'f12_cf7_doubleoptin_audit_log',
90	__( 'Consent audit log', 'double-opt-in' ),
91	__( 'Open Double Opt-In', 'double-opt-in' ),
92	$optInsUrl
93	)
94	);
95
96	// Not a table check: this one asks whether the forms' consent
97	// settings still match the forms. A stale acceptance field does
98	// not break anything visibly — it quietly turns every opt-in of
99	// that form into consent evidence nobody ever confirmed.
100	$registry->register( new StaleConsentFieldCheck() );
101
102	// The two checks around the Pro 3.x -> 4.x upgrade. They live in
103	// free Core on purpose: both describe a site where Pro is broken
104	// or absent, so a check shipped inside bundle-pro would be the one
105	// thing not loaded when it is needed.
106	$registry->register( new LegacyMonolithCheck() );
107	$registry->register( new StaleProMarkersCheck() );
108
109	// Add-ons that predate the 5.8 move of editing code out of Core.
110	$registry->register( new AddonCompatibilityCheck() );
111
112	( new HealthRepairController() )->register();
113
114	( new SiteHealthIntegration( $registry ) )->register();
115	}
116	}
117