SSH falsches Verzeichnis - Installation kaputt?

In einer Shop Installation habe ich zuerst im Base Directory

composer require oxid-projects/pdf-invoice-module

ausgeführt und gleich im Anschluss (in geistiger Umnachtung) versehentlich

git clone https://github.com/OXIDprojects/pdf-invoice-module.git invoicepdf

Dadurch wurde im Base Directory ein Ordner für das Modul angelegt (wo es natürlich ja nicht hingehört). Das sollte ja nach meinem Verständnis kein Problem sein wenn da unnütze Ordner rumliegen. Allerdings funktioniert diese Shopinstallation seither nicht mehr. Auch das Löschen des falschen Modulordners hat nichts gebracht.

Lässt sich der Shop nach so einem Fehler (meinerseits) nicht mehr reparieren?

Zur Verdeutlichung meiner Frage, ich habe bisher keine Erfahrung mit SSH und lerne gerade damit umzugehen.
Meine Frage ist, ob mit dem Befehl neben dem reinen Kopiervorgang noch die composer file oder andere Dateien beschrieben werden, so dass einfaches Löschen nicht mehr möglich ist.

Das hat normalerweise nichts miteinander zutun, denn damit hast ja nur ein locales repository angelegt. Was steht denn im Log des Shops?

Kein Eintrag im Error-Log und sowohl Shop als auch Admin URL zeigen nur noch weiße Seite ohne Quellcode.

Also zu meinem Verständnis, mit git clone wird nur ein Ordner kopiert und nichts an anderen Dateien manipuliert?
Und wenn ich etwas mit composer require installiere, kann ich dann den betreffenden Ordner auch einfach wieder rauslöschen ohne weiteres?

Wie ist das mit Updates? Zukünftige Oxid Updates werden dann ja auch mit SSH gemacht. Kann es passieren, dass die Routine fehlschlägt und man deshalb hinterher ein unreparierbares System daliegen hat?

Was genau meinst mit Base Directory? Innerhalb des source Verzeichnisses?

your shop base directory (where the shop’s composer.json file resides).

Ich habe das Wording von GitHub - OXIDprojects/pdf-invoice-module verwendet.

Du kannst mit
composer remove oxid-projects/pdf-invoice-module

alles wieder entfernen. Bei “nur” einfachem Löschen bleiben Verweise zurück.

1 Like

In der Anleitung heißt es:

Variante 1 zur Installation: Module installation via composer

In order to install the module via composer, run the following commands in commandline of your shop base directory (where the shop’s composer.json file resides).

composer require oxid-projects/pdf-invoice-module

Variante 2 zur Installation: Module installation via repository cloning

Clone the module to your OXID eShop modules/oe/ directory:

git clone https://github.com/OXIDprojects/pdf-invoice-module.git invoicepdf

Now you have to install the module with the oe-console, via command-prompt respectively ssh, in order to get it listet in the backend under modules:

vendor/bin/oe-console oe:module:install-configuration source/modules/oe/invoicepdf

Frage

@raspberry hast Du den auch den zweiten Befehl

vendor/bin/oe-console oe:module:install-configuration source/modules/oe/invoicepdf

abgesetzt?

Nein, denn da hatte ich gemerkt dass das Unsinn ist, da ich ja bereits Variante 1 abgeschlossen hatte.

Aber der zweite Befehl dürfte ja auch eigentlich gar nicht funktionieren, wenn der Ordner im falschen Verzeichnis liegt, oder?

Korrekt.

Deswegen wurde der Modulordner ja auch im Root angelegt. Sonst hättest es im root (Ordner /source/) so schreiben und installieren müssen:

git clone https://github.com/OXIDprojects/pdf-invoice-module.git modules/oe/invoicepdf

Ohne Installation kann das mit dem weißen Bildschirm eigentlch :wink: nichts zutun haben.

Tipp: Quelltext des weißen Bildschirms ausgeben lassen. Hin und wieder findet man da Hinweise.

Okay danke.

Warum nicht? Wenn Du bereits das Modul über composer installierst hast existiert das Verzeichnis doch.

Allerdings funktioniert diese Shopinstallation seither nicht mehr.

Glaube Dein Problem ist ein Anderes. Normalerweise würde ich immer zuerst den Shop installieren und Installationsschritte im Browser durchlaufen.

Erst im zweiten Schritt würde ich anfangen Module zu installieren.

Was steht den in Deiner composer.json?

Ok Root ist bei Oxid 6 also der Source Ordner?

Quelltext habe ich gecheckt, der ist wie schon geschrieben komplett leer.

Ja, wenn Du das Document-Root meinst.

Die Composer Befehle werden aber eins höher abgesetzt im base directory (where the shop’s composer.json file resides).

Ich versuche mich schon so genau wie nur möglich an die Installationsanweisungen zu halten. Jahrelanger Betrieb von Oxid 4 haben mir das quasi eingeprügelt :wink: Immer alles der Reihe nach installieren.

Ja ich habe die Installationsroutine durchlaufen und hatte sogar schon css und Template Dateien editiert sowie Artikel, Kategorien, Auswahllisten etc angelegt. Danach erst versucht, das Modul zu installieren.
Ich vermute, dass ich da selber einen Fehler mit Dateien gemacht habe. Es ist imho etwas chaotisch, dadurch dass das Theme über 2 Ordner verteilt ist (views und out).

Nun habe ich Sorge, wenn ich den Shop im produktiven Einsatz habe, und mir das passiert, dann wäre das nicht so schön.
Ich möchte halt wissen, worauf ich achten muss, und wie mir dieses SSH gefährlich werden kann, bzw. wie ich diese SSH Befehle im Notfall rückgängig machen kann, da das gerade für mich eher einem Blindflug gleicht.

Wie sieht es denn mit Backups aus? Kann ich einfach so wie früher ein Backup per FTP ziehen, oder funktionert das dann nicht? Oder gibt es da wenigstens einen schlaueren Weg mit SSH?

Ist alles komplexer geworden, auch der Betrieb eines OXID eShops.

Eine gute Softwareinfrastruktur - quasi ein solides Fundament - umso wichtiger geworden um der Geschwindigkeit wie sich Dinge ändern Schritt halten zu können.

Selber arbeite ich mit den Tools PHPStorm, Git, Composer, DDEV, Deployer und GitLab um den OXID eShop zu betreuen. Das Zusammenspiel dieser Tools stellt die Basis dar - die Softwareinfrastruktur. Um über eine GitLab CI/CD Konfiguration den OXID eShop auszuspielen.

Das Thema einmal ein wenig in meinem Blog unter Digitalisierung Leitfaden für Online-Shop Händler*innen | Professionelle Modulentwicklung angerissen, in nächsten Wochen kommen dort noch mehr Infos inkl. IT-Dienstleistungsprodukte die beim Aufbau einer Softwareinfrastruktur unterstützen.

Über eine CI/CD Konfiguration kann man einen Fallback schaffen um zur vorherigen Version zurück springen zu können. Eine Softwareinfrastruktur nimmt einem die Angst bei der Entwicklung/Anpassung am Shop etwas nachhaltig kaputt zu machen.

Da man zuerst in einer lokalen Testumgebung seine Anpassungen testen kann. Wenn diese soweit okay, kann man diese einpflegen und über GitLab auf eine Staging Testumgebung vom Server einspielen dort nochmals testen wegen möglichst gleichen Umgebungsvariablen wie Produktivumgebung.

Erst im letzten Schritt eigene Anpassung auf Produktivumgebung ausspielen.

Gefährlich ist hier, wenn man über Halbwissen verfügt. Weil wenn Du einmal einen Konsolen Befehl abgesetzt, welcher zu einem Fehler führt und Du nicht weißt was Du gerade getan - dann kann auch der Profi nur noch schwer helfen bzw. ist mit immensen Zeitaufwand verbunden das zu reparieren.

Ein Backup von Dateien macht man z.B. über ein Git Repository wobei man das vendor Verzeichnis nicht mitaufnehmen muss, weil die exakte Bauanleitung steckt in der composer.lock Datei um das vendor Verzeichnis 1 zu 1 wieder herstellen zu können.

Für ein Backup der Datenbank legt man sich am Besten selber einen Prozess an, welcher regelmäßig einen Datenbank Dump erstellt.

Zumindest schneller: Ein Kunde von uns will immer ne Sicherung auf dem Server haben, die er im Falle des Falles nur umbenennen muss. Alles andere ist ihm zu komplziert. Das macht er mit:

SSH: cp -R shopfolder shopfolderbak

So kann er shopfolderbak einfach umbenennen.

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/ [email protected] 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