SSH falsches Verzeichnis - Installation kaputt?

Deployer arbeitet mit Release Verzeichnisse, dort müsste Dein Kunde nur den Symlink zurück ändern.

Im Zusammenspiel über eine GitLab CI/CD Konfiguration wäre dies nur ein Knopfdruck für Dein Kunde.

NJaaa. Wie @raspberry ist er es so gewohnt und will es nicht anders. Der Kunde ist König. Und die Frage war, ob man es FTP-ähnlich mit SSH machen kann.

Ich habe natürlich nichts dagegen wenn etwas einfach und bequem per Knopfdruck funktioniert. Nur wenn der Knopf mal nicht so funktioniert, wie er soll, dann muss ich ja irgendwie den Fehler bereinigen können, ohne auf die Tools angewiesen zu sein.

hallo, meine kenntnisse ist vielllll niedrige als die Menschen hier posten…ich denke wie indianer3c, man braucht kenntnisse habe und einiger sache machen… um Stress zu Sparen…

Datenbank

Hier in forum sprecht wie du eine backup mit terminal kannst, es sollte MySQLDumpe benutz,.

Wenn du PhpMyadmin oder Adminer hast, kannst deine Oxid Datenbank exportiert mit,

Oxid Ordner hinaufbringen

Wenn du möchtest von deinem Rechner nach deinem Sever der Oxid Ordner hinaufbringen mit SSH.

Aber Erste sollst du in Admin Fenster in Grundeinstellung, Aktiv Taste, ausschalten machen

ich benutze rsync die in alle Linux schon installiert ist, sie benutze auch SSH…

1- Auf deine Server /var/www/html, in deiner Recher du hast deine Oxid Shop, und sie heißt auch oxid

2- Verbinden mit deinem Terminal deine Rechner mit deine server, der kommand der ich benutze ist,

 rsync -avz /home/ich/oxid/ deine_Benutzername@Adresse für FTP/SSH:/home//public_html/oxid/  

Mit rsync -avz, was man rsync sagt, This would recursively transfer all files from the directory src/bar onthe machine foo into the /data/tmp/bar directory on the local machine.

Aber wenn deine server benutze andere Port als stander von SSH Port 22, du solltest schreibe -p mit den Port Nummer… Beispiel -p 23454

Du solltest mache der Ordner in deine server, wo du oxid installiert möchtest VOR die diese Kommand du benutz…meine ist oxid

1 Like

Sicher.

ja. So sehen das viele, denn sie haben überhaupt keine Zeit für neue Systeme. Wegen composer sind einige kleinere von OXID abgesprungen und auch Hoster.

Veraltet. Wenn, dann müsste man schon den Nachfolger erwähnen. Das soll hier keine Diskussion geben. Wir sollten zurück zum Topic.

und wie heißt seine nachfolger ?

z.B. MyOosDumper

Um zum Topic SSH falsches Verzeichnis - Installation kaputt? zurück zu kehren, die Ausgangsfrage kann man verneinen meiner Meinung nach.

Aus meiner Sicht ist es einfachsten in diesem Fall wenn ich alle Infos von der Ausgangsfrage nun korrekt verstanden habe, dass man sich

  1. eine neue Shopinstanz installiert
  2. die Schritt für Schritt Installation im Browser durchläuft
  3. und erst dann das PDF Invoice Modul installiert (dabei nur eine der drei möglichen Installationsoptionen befolgt)

Da ich es so verstanden habe, dass @raspberry sich eine neue Shopinstanz installiert hat ohne die Schritt für Schritt Installation im Browser zu durchlaufen und vorab bereits über die SSH Konsole sich das PDF Invoice Modul installieren wollte und erst anschließend die Schritt für Schritt Installation im Browser durchlaufen wollte.

Korrigiert mich falls ich daneben liege.

Nööö. Korrekt. Das steht ja beireits oben.

Die Anfangsfrage lässt sich nicht so leicht beantworten, da es schwer nachzukonstruieren ist. Deshalb kam die Frage auf, wie ich so was verhindern kann bzw. wie ich für Backups sorgen kann.

Wie ich es jetzt verstanden habe kann ich ganz einfach wie früher per FTP und SQLDump Backups ziehen, auf einen anderen Server verschieben, und die laufen dann problemlos weiter, und man kann dann auch weiter SSH Befehle auf dem Backup Shop anwenden.

Okay also war der Shop bereits installiert vor Modulinstallation. Zur Erklärung das Installationsverzeichnis löscht sich nach der Schritt für Schritt Installation von selbst. Daher ist es normal, dass sich die Shop Installation nicht erneut durchlaufen lässt.

Ein FTP Backup der Dateien und ein Backup der Datenbank Daten über SQLDump besitzen weiterhin Gültigkeit.

Aber es muss dann auch zwingend beides eingespielt werden um den alten Stand wiederherzustellen.

Über DDEV ließe sich einfach ein sogenannter snapshot auf der lokalen Testumgebung von der Datenbank anlegen und man könnte diesen über DDEV auch einfach wieder einspielen.

Über ein Git Repository ließe sich über ein sogenanntes Rollback der alte Dateienbestand wiederherstellen (wenn Änderungen noch nicht committed).

@raspberry vielleicht wäre für den Anfang auch folgende allgemeine Anleitung etwas für Dich Backup einer Website erstellen | cyon-Support

Ich kann leider nirgends sehen, wo ich geschrieben haben soll, dass ich das versucht hätte. Evtl. handelt es sich um ein Missverständnis.

Der Shop war installiert, die Installationsroutine war abgeschlossen, ich habe bereits damit gearbeitet und die ersten Testbestellungen waren durch.

Dann wollte ich nur dieses Modul installieren.

Dann habe ich Deinen Satz

Allerdings funktioniert diese Shopinstallation seither nicht mehr.

falsch interpretiert. Dieser Satz bezieht sich anscheinend auf Deinen Anfangssatz

In einer Shop Installation

Alles klar.

Die möglichen logischen Erklärungen für mich sind

  1. das installierte PDF-Invoice Modul kaputt
  2. das installierte PDF-Invocie Modul nicht kompatibel mit Deiner Shop-Version
  3. das installierte PDF-Invocie Modul nicht kompatibel mit Deiner PHP-Version
  4. Du hast doch unbewusst noch den zweiten Konsolen Befehl aus GitHub - OXIDprojects/pdf-invoice-module ausgeführt und damit einen Fehler in der Modulkonfigurationsdatei 1.yaml ausgelöst oder Deine 1.yaml Datei war bereits vor Modulinstallation “kaputt” aber erst durch Verwendung des Befehls wurde diese fehlerhafte Modulkonfiguration in Deine Datenbank geladen

Ach, jetzt sehe ich wo das Missverständnis herkommt. Danke.

Zwischenzeitig arbeite ich in einem weiteren fertig installierten Shop und achte genauer darauf, wo Fehler passieren.

Interessant ist, dass im neuen Shop (gleiche Version CE 6.3.0) andere Dateien vorkommen. Z. B. im Base Directory (wo die composer.json liegt) finde ich folgende Dateien, die im ersten Shop nicht vorkamen:

.ide-helper.php
test_config.yml

sowie den Ordner
.phpstorm.meta.php

Vielleicht hängt das ja miteinander zusammen.

Es wurde wie auch beim ersten mal nur der Oxid Shop mit Composer installiert, und später dann das Wave Childtheme von ecomstyle, sowie eben dieses InvoicePDF Modul. Alles über composer.

1 Like

Diese Dateien werden geladen, wenn bei Composer der --no-dev Parameter weggelassen wird. Dort muss man auch bei Modulinstallation aufpassen, daher splitte ich persönlich die Installation von Modulen über Composer gerne in zwei Befehl. Beispiel PDF Invoice Modul:

composer require --no-update oxid-projects/pdf-invoice-module
composer update --no-dev

Der erste Befehl sorgt dafür das PDF Invoice Modul in composer.json aufgenommen.

Der zweite Befehl aktualisiert die Dateien bzw. lädt das PDF Invoice Modul.

Ist das php 7 oder 8?

Sind die Dateien nun also gut oder schlecht?

In der Anleitung des Plugins steht davon leider nichts. Dann muß ich also bei jeder Composer Installation diese no dev Anweisung dazuschreiben. Das wundert mich, dass das nicht in der Anleitung steht.

@rubbercut es ist bei beiden Shops php 7.4. Im ersten Versuch habe ich gleich mit php 7.4 gestartet, im aktuellen Shop war es zuerst php 8, und nachdem das PDF Modul nach der Installation nicht funktioniert hatte, habe ich auf 7.4 umgeschaltet.

Weder noch. Die Dateien haben in der Produktivumgebung eines Online-Shops nichts zu suchen, weil das Entwicklungsdateien sind.

Dies erfordert Hintergrundwissen über Composer.

Ach stimmt. Das war der Fall. Dafür gibt’s ja mittlerweile nen (noch unbearbeiteten) Pull Request. Damit geht’s.

Musst Du nicht. Man kann später alle unnötigen Dinge entfernen. Ist der Produktivmoduls aktiv? Wenn ja, kannst den in der Datenbank (Tab: oxconfig) ausschalten. Vielleicht kommt dann ne Fehlermeldung.