You are here

function lightning_scheduler_cron in Lightning Workflow 8.2

Same name and namespace in other branches
  1. 8.3 modules/lightning_scheduler/lightning_scheduler.module \lightning_scheduler_cron()
  2. 8 modules/lightning_scheduler/lightning_scheduler.module \lightning_scheduler_cron()

Implements hook_cron().

File

modules/lightning_scheduler/lightning_scheduler.module, line 57

Code

function lightning_scheduler_cron() {
  $field_map = Drupal::service('entity_field.manager')
    ->getFieldMap();

  /** @var \Drupal\lightning_scheduler\TransitionManager $transition_manager */
  $transition_manager = Drupal::service('lightning_scheduler.transition_manager');
  $start = new DrupalDateTime('now', DateTimeItemInterface::STORAGE_TIMEZONE);
  $now = Drupal::time()
    ->getRequestTime();
  $start
    ->setTimestamp($now);
  foreach ($field_map as $entity_type_id => $fields) {
    if (isset($fields['scheduled_transition_state'], $fields['scheduled_transition_date'])) {
      $transition_manager
        ->process($entity_type_id, $start);
    }
  }

  // At some point, core started caching state values, both statically and
  // persistently. Unfortunately, the cron service does not explicitly persist
  // the system.cron_last variable, which means that subsequent reads of
  // system.cron_last might return an outdated value, thus breaking any code
  // which is sensitive to the last cron run time (e.g., this module). This
  // should be fixed in core at some point, but for now we can work around it by
  // ensuring the state cache is cleared during cron, ensuring that all of its
  // values are persisted.
  $state = Drupal::state();
  if ($state instanceof CacheCollectorInterface) {
    $state
      ->resetCache();
  }
}