prod_check.module in Production check & Production monitor 8
Same filename and directory in other branches
Module file for the prod check module
File
prod_check.moduleView source
<?php
/**
* @file
* Module file for the prod check module
*/
use Drupal\Core\Routing\RouteMatchInterface;
use Drupal\prod_check\ProdCheck;
/**
* Implements hook_theme().
*/
function prod_check_theme() {
return [
'prod_check_status_report' => [
'variables' => [
'requirements' => NULL,
'categories' => NULL,
],
],
];
}
/**
* Prepares variables for status report template.
*
* Default template: status-report.html.twig.
*
* This theme function is dependent on install.inc being loaded, because
* that's where the constants are defined.
*
* @param $variables
* An associative array containing:
* - requirements: An associative array of requirements/status items per
* category. Each requirement is an associative array containing the
* following elements:
* - title: The name of the requirement.
* - value: (optional) The current value (version, time, level, etc).
* - description: (optional) The description of the requirement.
* - severity: (optional) The requirement's result/severity level, one of:
* - ProdCheck::REQUIREMENT_INFO: Status information.
* - ProdCheck::REQUIREMENT_OK: The requirement is satisfied.
* - ProdCheck::REQUIREMENT_WARNING: The requirement failed with a warning.
* - ProdCheck::REQUIREMENT_ERROR: The requirement failed with an error.
*/
function template_preprocess_prod_check_status_report(&$variables) {
$severities = [
ProdCheck::REQUIREMENT_INFO => [
'title' => t('Info'),
'status' => 'info',
],
ProdCheck::REQUIREMENT_OK => [
'title' => t('OK'),
'status' => 'ok',
],
ProdCheck::REQUIREMENT_WARNING => [
'title' => t('Warning'),
'status' => 'warning',
],
ProdCheck::REQUIREMENT_ERROR => [
'title' => t('Error'),
'status' => 'error',
],
];
foreach ($variables['requirements'] as $category => $requirements_per_category) {
foreach ($requirements_per_category as $i => $requirement) {
// Always use the explicit requirement severity, if defined. Otherwise,
// default to REQUIREMENT_OK in the installer to visually confirm that
// installation requirements are met. And default to REQUIREMENT_INFO to
// denote neutral information without special visualization.
if (isset($requirement['severity'])) {
$severity = $severities[(int) $requirement['severity']];
}
elseif (defined('MAINTENANCE_MODE') && MAINTENANCE_MODE == 'install') {
$severity = $severities[ProdCheck::REQUIREMENT_OK];
}
else {
$severity = $severities[ProdCheck::REQUIREMENT_INFO];
}
$variables['requirements'][$category][$i]['severity_title'] = $severity['title'];
$variables['requirements'][$category][$i]['severity_status'] = $severity['status'];
}
}
}
/**
* Implementation of hook_help().
*/
function prod_check_help($route_name, RouteMatchInterface $route_match) {
$output = '';
switch ($route_name) {
case 'prod_check.report':
$output = '<p>' . t("This is an overview of all checks performed by the <em>Production check</em> module and their status. You can click the links inside the report to jump to the module's settings page, or to go to the project page of a module, in case you need to download it for installation.") . '</p>';
break;
}
return $output;
}
/**
* Implements hook_cache_flush().
*/
function prod_check_cache_flush() {
prod_check_synchronize_prod_checks();
prod_check_synchronize_prod_check_processors();
}
/**
* Helper function to synchronize prod check plugins and entities
*/
function prod_check_synchronize_prod_checks() {
// This isn't a nice way but at the moment it's the only way I can think of to keep the one on one relation between
// prod check entities and plugins intact. As the amount of checks will stay limited this isn't a performance issue.
$query = \Drupal::entityQuery('prod_check')
->condition('status', 1);
$existing_checks = $query
->execute();
$checkManager = \Drupal::service('plugin.manager.prod_check');
$checks = $checkManager
->getDefinitions();
foreach ($checks as $plugin_id => $check) {
$plugin = $checkManager
->createInstance($plugin_id, $check);
$id = !empty($plugin
->getDerivativeId()) ? $plugin
->getBaseId() . '_' . $plugin
->getDerivativeId() : $plugin_id;
if (!isset($existing_checks[$id])) {
$values = [
'id' => $id,
'label' => (string) $plugin
->title(),
];
/** @var ProdCheckEntity $new_check */
$new_check = \Drupal::entityTypeManager()
->getStorage('prod_check')
->create($values);
$new_check
->setPlugin($plugin_id);
$new_check
->save();
}
}
}
/**
* Helper function to synchronize prod check processor plugins and entities
*/
function prod_check_synchronize_prod_check_processors() {
// This isn't a nice way but at the moment it's the only way I can think of to keep the one on one relation between
// prod check entities and plugins intact. As the amount of checks will stay limited this isn't a performance issue.
$query = \Drupal::entityQuery('prod_check_processor')
->condition('status', 1);
$existing_processor = $query
->execute();
$processors = \Drupal::service('plugin.manager.prod_check_processor')
->getDefinitions();
foreach ($processors as $processor) {
if (!isset($existing_processor[$processor['id']])) {
$values = [
'id' => $processor['id'],
'label' => (string) $processor['title'],
];
/** @var ProdCheckEntity $new_check */
$new_check = \Drupal::entityTypeManager()
->getStorage('prod_check_processor')
->create($values);
$new_check
->setPlugin($processor['id']);
$new_check
->save();
}
}
}
Functions
Name | Description |
---|---|
prod_check_cache_flush | Implements hook_cache_flush(). |
prod_check_help | Implementation of hook_help(). |
prod_check_synchronize_prod_checks | Helper function to synchronize prod check plugins and entities |
prod_check_synchronize_prod_check_processors | Helper function to synchronize prod check processor plugins and entities |
prod_check_theme | Implements hook_theme(). |
template_preprocess_prod_check_status_report | Prepares variables for status report template. |