it-swarm.com.de

Modulposition verschieben

Ich habe ein Testmodul unter site/all/modules/custom. Zuerst habe ich das Modul deinstalliert und den Cache geleert. Dann habe ich das Testmodul in den Ordner modules/custom verschoben, der ein neuer Speicherort für das Modul Drupal 8) ist.

Danach habe ich das Testmodul aktiviert und dann Alle Caches löschen. Jetzt sagt Drupal 8 hält sagt, dass das Testmodul nicht unter dem alten Speicherort gefunden werden kann (site/all/modules/custom).

Ich dachte Drupal 8 hat wahrscheinlich den Pfad in einer DB-Tabelle gespeichert, aber ich kann die Tabelle nicht finden. Kann jemand eine Lösung darüber finden, wie das obige Problem behoben werden kann?

7
anru

Sie können dies tun, ohne es zu deinstallieren, aber es erfordert einige Fummelei:

  1. Verschieben Sie das Modul in das Dateisystem
  2. rufe drush ev "drupal_flush_all_caches();" auf
  3. rufe drush cr auf

Die entscheidende Einstellung ist der Eintrag system.module.files In der Datenbanktabelle key_value. Wenn Sie die Module verschieben und versuchen, drush cr Direkt auszuführen, schlägt dies möglicherweise fehl, da drush versucht, ein vollständiges bootstrap] auszuführen und die erforderlichen Dateien nicht zu finden.

drush ev Führt eine fehlerfreie bootstrap mit drush_bootstrap_max () aus, und drupal_flush_all_caches Erstellt die system.module.files - Konfiguration neu, ohne zu versuchen (und fehlzuschlagen), die zu laden Verschobene Dateien. Während drush cr einen Bootstrap für die gesamte Site ausführt, wird Drush bei Fehlern angehalten.

12
aaronbauman

Sie müssen nicht erneut installieren. Ein nach dem Verschieben eines Moduls gelöschter Cache sollte ausreichen. Wenn nicht, haben Sie die Caches möglicherweise nicht geleert?

8
Berdir

Ich hatte das gleiche Problem beim Heraufstufen eines Moduls von custom auf contrib. Der Schlüssel für mich war das Löschen des (APC) Autoloader-Cache in Kombination mit dem Drupal Cache).

Ich glaube, ich habe das Modul drush cr Deinstalliert und dann eine Autoloader-Cache-Ungültigmachung erzwungen (indem ich diese Datei in die Webroot gesteckt und den Browser darauf gerichtet habe):

<?php apc_clear_cache();

gefolgt von einem weiteren drush cr für eine gute Maßnahme und anschließender erneuter Aktivierung des Moduls.

Hier einige Hintergrundinformationen aus dem Pantheon zum APC: https://pantheon.io/docs/alternative-php-cache/

7
ahebrank

dies hat zu local.settings.php hinzugefügt und den Trick für mich gemacht:

   /**
 * Class Loader.
 *
 * If the APC extension is detected, the Symfony APC class loader is used for
 * performance reasons. Detection can be prevented by setting
 * class_loader_auto_detect to false, as in the example below.
 */
$settings['class_loader_auto_detect'] = FALSE;

ich denke, ein Neustart des Servers oder ein leerer APC-Cache hätte den Trick auch getan

4
Matoeil

Versuchte das oben genannte und nichts schien für mich zu funktionieren. Am Ende ging ich in die Datenbank für meine D8-Site und schnitt alle Tabellen ab, die mit 'cache_' beginnen, und das hat den Trick getan - vielleicht hilft dies jemand anderem.

1
Joe Keene

Pfade sind eher eine Frage der Registrierung als des Caches. In Betriebssystemen und anderen Systemen ist die Registrierung (wie die Windows-Registrierung) die Pfadregistrierung, die einer "Zivilregistrierung" einer bestimmten Stadt oder eines bestimmten Landes ähnelt.

Daher würde ich empfehlen, die Registrierung mit dem Modul Devel oder mit Drush neu zu erstellen.

In Drupal 7) habe ich die Registrierungstabellen in der Datenbank der Site in phpmyadmin abgeschnitten, als ich aus technischen Gründen momentan keine Entwicklung oder Drush ausführen konnte.

1
JohnDoea

die Antwort von ahebrank, eine PHP-Datei im Stammverzeichnis Ihrer Drupal-Instanz zum Löschen des APC-Cache zu erstellen, ist die am wenigsten invasive Methode, die ich gefunden habe, um dies zu erreichen, da sie nur das betrifft Drupal Instanz.

Eine andere Möglichkeit besteht darin, Apache neu zu starten, gefolgt von drush cr, was das gleiche Ergebnis hat, sich aber offensichtlich auf alle anderen Sites auf demselben Server auswirkt.

In meinem Fall musste ich alle Contrib-Module in meiner Drupal -Instanz von modules/in modules/contrib/verschieben. Dies führte zu einem 500-Fehler auf meiner Site. Ich weiß es nicht Welches Modul den 500-Fehler verursacht hat, aber es war nicht praktisch, alle meine Module zu deinstallieren und neu zu installieren.

1
millionleaves

Sie können zu Ihrer settings.local.php hinzufügen

$settings['deployment_identifier'] = 'ANY CUSTOM STRING';

dies wird von Acquia/BLT verwendet, um den Container-Cache zu leeren. Gemäß der blt-Dokumentation im Code:

/**
 * Deployment identifier.
 *
 * Drupal's dependency injection container will be automatically invalidated and
 * rebuilt when the Drupal core version changes. When updating contributed or
 * custom code that changes the container, changing this identifier will also
 * allow the container to be invalidated as soon as code is deployed.
 */
0
Akalam

Ich würde versuchen, das Modul zu deinstallieren, bevor ich es verschiebe.

Setzen Sie das Modul einfach wieder an seinen ursprünglichen Speicherort und deinstallieren Sie es mit "drush pm-uninstall" oder über die Registerkarte "Deinstallieren" auf der Seite "Erweitern" in der Administrator-Benutzeroberfläche. Sie sollten können es nach diesen Schritten verschieben.

  • Option 2:

Zu faul, um es auf der Workstation nachzuschlagen. Wenn D8 wie D7 ist, haben Sie eine Systemtabelle in der Datenbank mit einem Eintrag für Ihr Modul. Sie können einfach den Eintrag mit name = "yourModuleName" löschen und Ihr Modul neu installieren.

0
stefgosselin