it-swarm.com.de

Wie deaktiviere ich die Erstellung von Knotenrevisionen bei der programmatischen Knotenaktualisierung?

Ich habe ein Feld vom Typ berechnetes Feld zu vorhandenen Knoten hinzugefügt. Es ist erforderlich, die Knoten erneut zu speichern, um berechnete Feldwerte festzulegen/zu aktualisieren. Da ich den geänderten Zeitstempel nicht aktualisieren möchte, habe ich beschlossen, das View-Bulk-Update nicht zum erneuten Speichern von Inhalten zu verwenden. Der einfachste Weg wäre ein Drush-Skript. Auf diese Weise kann ich Inhalte bei Bedarf neu speichern.

Mein erstes Problem war, dass ich die geänderte Zeit beim Update nicht unverändert lassen konnte ($ node-> save ()). Aber ich fand, dass es auf einem zweiten Knoten speichern zurückgesetzt werden konnte.

Mein Problem ist, dass auf jedem Knotenspeicher eine neue Revision erstellt wird. Der Knotentyp kann überarbeitet werden und neben dem Kernmodul ist die Inhaltsmoderation aktiviert. Ich würde mich über jede Hilfe freuen, um die Erstellung von Revisionen zu verhindern.

Dies ist mein aktuelles Drush-Skript in custom_helper.drush.inc:

<?php
/**
 * @file
 * Provides drush command to update all articles.
 */

use Drupal\node\Entity\Node;

/**
 * Implements hook_drush_command().
 */
function custom_helper_drush_command() {
  $items = array();
  $items['custom-resave-content'] = array(
    'description' => dt('Resaves all article entities.'),
    'options' => [
      'types' => dt('Coma separated list of content type to be resaved.'),
      'nids' => dt('Coma separated list if node ids.'),
      'field' => dt('Machine name of computed field to be updated.')
    ],
    'aliases' => array('custom-rc'),
  );
  return $items;
}

/**
 * Moves paragraphs into one paragraph reference field.
 */
function drush_custom_helper_custom_resave_content() {
  $nids = _convert_csv_to_array(drush_get_option('nids', []));
  $types = _convert_csv_to_array(drush_get_option('types', []));

  if (!$nids || $types) {
    // Get an array of node IDs.
    $query = \Drupal::entityQuery('node');
    if ($types) {
      $query->condition('type', $types, 'IN');
    }
    if ($nids) {
      $query->condition('nid', $nids, 'IN');
    }
    $nids = $query->execute();
  }

  // Load all the nodes.
  if ($nids) {
    $field_name = drush_get_option('field', '');

    $nodes = Node::loadMultiple($nids);
    foreach ($nodes as $node) {
      $entity_type = $node->getEntityType();
      $original_changed = $node->getChangedTime();
      if ($entity_type->isRevisionable()) {
        $node->setNewRevision(FALSE);
      }

      // Force update of computed field.
      if ($field_name) {
        /** @var \Drupal\Core\Field\FieldItemListInterface $items */
        $items = $node->get($field_name);
        if (empty($items[0])) {
          $items->appendItem();
        }
        $items->preSave();
      }

      // Save the updated computed field value.
      $node->setChangedTime($original_changed);
      if ($entity_type->isRevisionable()) {
        $node->setNewRevision(FALSE);
      }
      $node->save();

      // Reset changed time to original value.
      $node->setChangedTime($original_changed);
      if ($entity_type->isRevisionable()) {
        $node->setNewRevision(FALSE);
      }
      $node->save();

      $changed_after = $node->getChangedTime();
      drush_print('node:' . $node->id() . ':' . $original_changed . ':' . $changed_after);
    }
  }

  drush_log(dt('Resave finished.'), 'ok');
}
4
LarS

Derzeit ist dies bei installierter Inhaltsmoderation nicht möglich, ohne Backflips durchzuführen, z. B. das Ersetzen des Moderationshandlers für den Knotenentitätstyp.

Daran wird jedoch gearbeitet! Hier sind einige Probleme, die für Ihr Problem relevant sind:

Der Vorschlag besteht im Wesentlichen aus zwei Teilen:

  • Beschreiben Sie den Aufrufern von SynchronizableInterface::setSyncing() besser, wenn es angebracht ist, eine Entität als "Synchronisierung" zu markieren.
  • Ermutigen Sie Implementierer von Entity Lifecycle Hooks, störende Nebenwirkungen während der Synchronisierung von Entities zu reduzieren.

Ich zitiere mich aus dem Thema:

IMO, der aktuelle Synchronisierungsstatus für Inhaltsentitäten wird zu einem Flag, um anzuzeigen, dass ein Speichern unter Bedingungen stattfindet, die außerhalb einer typischen vom Benutzer initiierten Inhaltsaktualisierung liegen, und dass so weit wie möglich Nebenwirkungen aus diesem Speichern auftreten sollten begrenzt. Beispiele könnten sein:

  • Bereitstellen eines Arbeitsbereichs.
  • Batch-Aktualisierung alter Revisionen.
  • Ausführen eines Updates aus einer Migration.

Nach der Definition einiger dieser Szenarien wird es einfacher, einige der diskutierten Nebenwirkungen (CM-Revisionsbehandlung + geänderter Zeitstempel) zu eliminieren.

In Ihrem Fall versuchen Sie, die Integrität Ihres Modells durch Massenaktualisierung vorhandener Entitäten/Revisionen aufzulösen. Dies liegt außerhalb einer standardmäßigen redaktionellen Inhaltsänderung. Meiner Meinung nach passt dies also sehr gut zu der Semantik, die für Inhaltsentitäten und diese vorgeschlagen wird Schnittstelle. Wenn einige dieser Patches angewendet werden, sieht Ihr Codebeispiel möglicherweise folgendermaßen aus:

  $entity->setSyncing(TRUE);
  $node->save();

Und dann würde der geänderte Zeitstempel nicht aktualisiert und die Inhaltsmoderation würde nicht die Erstellung einer neuen Revision erzwingen.

5
Sam152