Auflösung von Abhängigkeiten bei verschiedenen Installationsarten - composer vs ftp
Eingetragen von katasun (281)am 02.11.2020 - 19:26 Uhr in
Drupal 8.9.7 habe ich auf meinem lokalem Linux-Rechner einmal per composer ( composer create-project drupal/recommended-project:8.9.2 my_site_name_dir ) und einmal per Dateiverwaltung aus dem Drupal Download zip installiert. Zur Kontrolle die Dateiberechtigungen und den richtigen Benutzer gewählt. Aus beiden Installationen ergab sich ein lauffähiges Drupal 8.9.7, wie gewünscht. Also ohne Fehlermeldungen in den Reports, etc.
Zum Test des Moduls endroid_qr_code-8.x-2.0.zip habe ichh das Modul in beide Versionen installiert. Zur Vorbereitung der Installation des Moduls sollen Bibliotheken über Composer installiert werden. Auf meinem lokalen Rechner habe ich composer installiert. Die Bibliotheken sollen mit dem Befehl:
Requirements: Install endroid/qr-code package from packagist.org using:
-- composer require endroid/qr-code-bundle
installiert werden.
Das habe ich für beide Installationsvarianten durchgeführt. Auch diesmal ohne Fehlermeldungen. Aber nur bei der Drupalinstallation die vollständig über composer installiert wurde, ist das Modul lauffähig.
Fehlermeldung:
Location http://localhost/d-8-9-7-classic/image-qr-generate-with-url?path=basic
Referrer http://localhost/d-8-9-7-classic/admin/reports/dblog/event/80
Message Error: Class 'Endroid\QrCodeBundle\Response\QrCodeResponse' not found in Drupal\endroid_qr_code\Response\QRImageResponse->generateQrCode() (line 116 of /var/www/html/d-8-9-7-classic/modules/endroid_qr_code/src/Response/QRImageResponse.php)
#0 /var/www/html/d-8-9-7-classic/modules/endroid_qr_code/src/Response/QRImageResponse.php(84): Drupal\endroid_qr_code\Response\QRImageResponse->generateQrCode()
#1 /var/www/html/d-8-9-7-classic/vendor/symfony/http-foundation/Response.php(374): Drupal\endroid_qr_code\Response\QRImageResponse->sendContent()
#2 /var/www/html/d-8-9-7-classic/index.php(20): Symfony\Component\HttpFoundation\Response->send()
#3 {main}
.
Severity Error
Hostname 127.0.0.1Die Stelle im Code habe ich mir angesehen, diese bietet aber keinen Hinweis auf die Quelle des Problems.
Die Installationen unterscheiden sich in den installierten Bibliotheken, die Composerversion hat mehr Bibliotheken und auch ein Install-Verzeichnis installiert. Nun war meine Idee, ich kopiere die Bibliotheken von der lauffähigen Version rüber in die per FTP installierten Version. Das funktioniert aber nicht.
Mein Ziel: Auf meinem Server möchte ich Drupal per FTP installieren und die nötigen Bibliotheken von meiner lokalen Installation übertragen. Meine Fragen an welchen Stellen kann ich die fehlenden Bibliotheken identifizieren und nachinstallieren. Geht das überhaupt so einfach und bin ich generell gezwungen composer auf dem Server zu installieren. Wenn es um Server geht versuche ich immer mit dem Minimum ans Ziel zu kommen.
Das wird sicher noch mehr Drupal Nutzer geben, die gerne eine schlanke Produktionsumgebung haben. Was mache ich falsch, ich freue mich über alle Tipps.
- Anmelden oder Registrieren um Kommentare zu schreiben
Bei manchen Modulen geht
am 02.11.2020 - 19:47 Uhr
Bei manchen Modulen geht heute ohne composer die Installation nichts mehr. Auch ich habe beim Provider nicht genügend PHP-Memory um dort mit composer zu arbeiten. Also installiere ich lokal mit composer. Danach packe ich die zu Drupal gehörenden Teile (vendor und web/core sowie eine Reihe von Dateien) in einen Tar-File (ein Zip-File geht auch) und schaffe die Datei komprimiert auf den Server. Dort packe ich über eine SSH-Verbindung den Tar-file an der richtigen Stelle aus, nachdem ich vorher vendor und web/core beim Provider gelöscht habe. update,php im Browser aufrufen oder in der Shell mit drush updb den Update erledigen. Dieses Vorgehen hat gegenüber FTP einen gewaltigen Vorteil. Ich habe es schon häufiger erlebt, daß der FTP sich an der Menge der zu übertragenden Dateien verschluckt. Dann fehlt hinterher eine Datei oder sogar ein Verzeichnis. Eine Fehlermeldung gibt es nicht oder sie geht unter. Der Fehler kommt erst im Nachhinein zum Vorschein durch Drupal Fehlermeldungen. Beim tar-File wird nur eine Datei übertragen und das geht immer oder es gibt einen sofort erkennbaren Fehler.
Den Update von Modulen mache ich auch zunächst lokal mit composer. da kopiere ich die Modulverzeichnisse per FTP zum Provider. Sind es viele Module, habe ich die auch schon mal eingepackt und als tar-File transferiert.
Insgesamt ist die Übertragungszeit auf diese Weise deutlich kürzer als bei einer reinen FTP-basierten Installation.
Bei manchen Modulen geht
am 02.11.2020 - 20:22 Uhr
Vielen Dank für die Antwort,
in den kommenden Tagen werden ich das mit der lokalen Erstellung per composer und dem Übertragen auf den Server mal ausprobieren. Das sollte schon klappen, aber was ich wissen wollte wo das Modul die Bibliotheken sucht. Mit einem Verzeichnisvergleichs Programm habe ich die Module endroid-qr-code verglichen, die sind völlig identisch. Ich such noch die Pfade zu den Bibliotheken und werde das noch weiter verfolgen.
Danke.
Ursache gefunden
am 02.11.2020 - 21:13 Uhr
Jetzt habe ich die Ursache gefunden. Die Installation durch den Einsatz von Composer ist nicht identisch mit der Installation per FTP. Bei mir ergeben sich die Unterschiede durch die Dateien composer.json. Hier werden verschiedene Einstellungen verwendet und damit auch verschiedene Bibliotheken geladen. Nachdem ich die composer.json meiner FTP Installation angepasst habe und die composer.lock gelöscht habe, hat alles geklappt. Es wurden dann alle Bibliotheken nachgeladen und der QR Code wurde dargestellt.
Hi katasun, Deine Beobachtung
am 03.11.2020 - 07:57 Uhr
Hi katasun,
Deine Beobachtung von unterschiedlichen composer.json Dateien ist ja wohl logisch.
Auch wenn es teilweise noch möglich ist, ohne zu intallieren, so geht meine Beobachtung auch dahin, dass man rundum sorgloser mit sauberer Composer-Installation von Anfang an ist.
Übrigens eine gute Nachricht:
Bei All-Inkl komme ihc jetzt mit Composer 2 gut zu rande, weil der viel weniger PHP Memory auf der Konsole benötigt.
Allerdings muss der Aufruf dann
php73 -d memory_limit=-1 /www/htdocs/w017fcfa/bin/composer.phar composerbefehl
lauten.
Da muss ich noch den Alias anpassen, damit ich wieder einfach composer aufrufen kann.
Und man muss beachten, dass nicht alle Module kompatibel snd zu composer 2. Bei mir war die Drupal console nicht kompatibel. Nicht so schlimm, verwende ich eben weiter drush. Ich wollte die nur mal testen.
Wenn es nicht klappt, kann man einfach
composer self-update
mit
composer self-update --rollback
rückggäng machen.
Installationsversionen
am 03.11.2020 - 09:25 Uhr
Vielen Dank, aber es ist für mich nicht logisch, das wenn ich Drupal 8 in der neuesten Version aus einem Download oder über composer installiere, unterschiedliche Bibliotheken benutzt werden. Da muss man mindestens in die composer.json schauen. Ein Hinweis beim Download oder bei den Composer Docs hätte mich auch gewarnt.
Composer erstellt aber auch Dateien oberhalb des Web Verzeichnisses. Oft habe ich zum Test einige Installationen in einem Unterverzeichnis abgelegt. Wie lößt man den sowas mit Composer? Ich nenne dann das Verzeichnis test-1, aber mit Composer gibt es wieder tiefere Verschachtelungen /test-1/web/index.php. Dann müßte ich eine Umleitung anlegen oder ähnliches.
Danke für den Tipp - "Und man muss beachten, dass nicht alle Module kompatibel sind zu composer 2. Bei mir war die Drupal console nicht kompatibel. Nicht so schlimm, verwende ich eben weiter drush. Ich wollte die nur mal testen." Also mehr Fehlerquellen und für eine Produktionsumgebung ist dann ein Test in einer Staging-Umgebung der einzig sichere Weg.
Gruss Katasun