Bitte nehmt es mir nicht übel, aber ich bin sowas von alte Schule das ich mit den neuen Sachen nicht so klar komme wie die jüngere Generation. Mit de Composer zu arbeiten ist für mich totales Neuland. Den Shop Ce 6.4 habe ich mir deshalb vom Provider installieren lassen. Ein Modul habe ich dann selber installiert. Es folgten viele, sehr viele Fragen über irgendwelche Updates und Änderungen. Da ich nicht wusste ob das so sein soll hatte ich alles bestätigt. Prompt wurden viele Dateien und Temples wieder in den Originalzustand versetzt, doppelte Arbeit.
Nun will ich PayPal Checkout 2.0 installieren und will den gleichen Fehler nicht zweimal machen. Wenn ich die Befehle für die Installation eingebe, braucht es dazu ein Daten-Paket das ich zuvor irgendwo downloade und in den Modul-Ordner schiebe? Und wie ist das generell, fragt mich der Composer immer ob er weitere Daten abgleichen soll und überschreibt dann weitere Shop-Dateien? Beim ersten/letzten mal wusste ich nicht ob diese Abfragen alle zu dem Modul gehören und auch Template überschreiben die wir gerändert hatten.
Ich hoffe ich kann mich hier ein wenig absichern bevor ich wieder was falsch verstehe … Danke
Composer ist ein ziemlich kompliziertes Werkzeug, das man auf verschiedene Arten / mit verschiedenen Befehlen benutzen kann, daher gibt es hier keine kurze Faustregel wie “immer gegen den Uhrzeigersinn drehen, um nichts kaputt zu machen”, mit der man alle Probleme vorbeugen kann.
Als Anfang könnte sich das hier anbieten:
Und der Rest hängt von der Anleitung an. Wenn man ein Datenpacket benötigt, sollte es in der Anleitung stehen. Wenn nicht, dann eher nicht.
Bei den erwähnten Abfrage schreibt composer eigentlich, was er ersetzten will, da müsste der Modulname und Pfad unterhalb von source/modules stehen.
Dies kommt leider häufiger vor als man denkt, wenn man Templates innerhalb von Modulen anpasst. Dann Nachfrage am Besten verneinen.
Um seine Anpassungen zu sichern nutzt man für seinen Shop mit seinen Änderungen am Besten eine Versionsverwaltungssoftware wie git und legt darüber ein git Repository an. Mehr Infos Git - Was ist Versionsverwaltung?
Nein, die Moduldateien werden über die Composer Befehle in Deinen Shop geladen. (aufs PayPal Checkout Modul bezogen)
Ausnahme ist, wenn es in der Modulinstallation Anleitung erforderlich ein Datenpaket auf dem eigenen Server abzulegen.
Dort leider sehr viel Wildwuchs jeder Modulanbieter hat dort seine eigene Anleitung, was es insgesamt noch erschwert.
Dies ist eine OXID spezifische Erweiterung von Composer. Die OXID spezifische Erweiterung fragt bei einem Composer Update immer nach ob die Moduldateien im source Verzeichnis aktualisiert werden sollen.
Wenn es sich um Standard Module handelt und innerhalb dieser Module keine Anpassungen stattgefunden haben, dann kannst mit y antworten.
Wenn Du Dir nicht sicher bist, dann solltest mit n antworten. Damit kannst im ersten Moment nichts falsch machen.
Danke für das tolle Feedback. Ich rechne mal damit dass PayPal Checkout auch einige Templates anpassen will, damit man dort die jeweiligen Buttons auf dem Produktseiten etc auch platzieren kann.
Da ich noch nicht mit einer Versionierung arbeite wird es wohl das einfachste sein ich ziehe mir ein komplettes Backup und passe alles dann wieder im aktuellen Layout an. Bei paypal werden wohl nur wenige Templates betroffen sein im Frontend und es wird überschaubar bleiben. Da muss ich jede Meldung abwägen. Uff …
Gibt es vielleicht irgendeine Erkennungsmerkmal an dem ich erkenne ob das Modul dass ich gerade installiere eine Änderung an Daten vornehmen möchte oder ob es sich hierbei um diesen generellen Check von OXID handelt?
Wenn in der metadata.php Datei Events drin stehen, dann ist es ein Indiz, dass an der Datenbank Änderungen erfolgen z.B. eigene Tabellen anlegen oder bestehende Tabellen um Spalten ergänzen oder ähnliches.
Ich kann gerade nicht so richtig nachvollziehen, warum das passieren sollte.
Composer arbeitet im OXID Shop doch so, dass Pakete ins vendor Verzeichnis heruntergeladen und anschließend ins source Verzeichnis kopiert werden, wenn man die Nachfrage mit ja beantwortet. Das macht OXID aktuell noch aus Kompatibilitätsgründen und wird mit OXID 7 nicht mehr nötig sein.
Jedenfalls sollte es keine negativen Auswirkungen geben, wenn man die Frage immer mit Ja beantwortet, außer man hat an einem Modul, welches über composer installiert wurde, Änderungen nur im source Verzeichnis durchgeführt. Das ist aber der Funktionsweise nach nicht das empfohlene Vorgehen, wie Änderungen von Modulen an einem Livesytem gemacht werden sollten.
Dann gibt es noch die Möglichkeit, dass Änderungen direkt an Shop eigenen Dateien gemacht wurden. Aber das war auch schon vor composer so, dass diese mit Updates verloren gehen. Daher müssen Änderungen immer über Module oder Child Themes gemacht werden. Ein Standardvorgehen in allen mir bekannten Softwaresystemen.
Im Moment fallen mir nur, aus meiner Sicht, falsch durchgeführte Shop-Anpassungen als Ursache ein. Oder gibt es dafür sonst noch eine Möglichkeit, die ich übersehe?
Die Realität sieht manchmal anders aus, weil viele Standard Module nicht so konzipiert sind, dass sie von anderen Modulen überladen werden können. Da wird man automatisch gezwungen im Standard Modul in einer Template Datei zu arbeiten.
Ja, insgesamt wird der Betrieb eines OXID eShops und anderen Softwaresystemen immer aufwendiger. Ohne technisches Know-How wird ein/e Händler*in nicht mehr auskommen. Entweder Inhouse oder Extern beauftragt.
Falsch durchgeführte Shop-Anpassungen gibt es aus meiner Sicht nicht. Was Du meinst, dass zu gunsten der Schnelligkeit, Bequemlichkeit oder fehlendes Wissen Anpassungen vorgenommen werden welche beim nächsten Update Mehraufwand erzeugen können.
Für viele Händler*innen stellt sich die Frage nach einem Systemwechsel was auf die eigene Bedürfnisse, Wissen und Budget ausgerichtet ist. Der Trend der Abwanderung oder Neustart mit Shopify scheint aktuell nicht abzunehmen sondern eher zuzunehmen.
Aber neben Shopify gibt es je nach Anwendungsfall viele Alternativen auf dem Markt.
Die Stärke von OXID eShop ist die Community Edition, für die kostenpflichtigen Editionen wurde anscheinend verpasst diese Markttauglich zu machen, indem man mit zusätzlichen Features Händler*innen von einem Wechsel der CE auf die PE oder höher überzeugen kann.
Wenn das Modul verschlüsselt gestaltet sich dies meist schwierig. Oder wenn es sich um ein gekauftes, verschlüsseltes Modul handelt was über path source eingebunden wird.
Klar ist Dein oben beschriebener Weg der Beste und anstrebenswerte. Aber manchmal ist es eine Kosten-Nutzen-Analyse und dabei kommt bei raus bewusst innerhalb eines Moduls zu arbeiten.
Für Anfänger, um mal auf den Titel des Beitrags zurückzukommen, ist es schwer, die Meldungen und Auswirkungen der Bestätigungen bzw. Nichtbestätigungen (ja/nein) einzuschätzen. Wer Zeit hat, kann das ja mal umsetzen.
Danke für die reichlliche Teilnahme, habe einiges dazu gelernt. Ich habe nun PayPal Checkout installiert und ich glaube ich habe Fehler gemacht. Das Modul wurde installiert und dann kamen die gefürchteten Abfragen nach Updating.
Es sollten z.B. alle Themen aktualisiert werden und andere Ordner. Das habe ich für die Templateordner blöderweise verneint.
habe ich das richtig verstanden das diese Update Abfragen nicht von Paypal kommen sondern ein allg. Abgleich sind, richtig? Also ist Nein richtig oder ist das Modul somit unvollständig?
Dann wollte er alle Module aktualisieren, habe ich auch verneint, es sei denn da stand was von Paypal.
Warum sollte bei der Installation von Paypal z.B. ein Modul für E-Mail-Anhäge aktualisiert werden?
Im Backend habe ich es drin und mal kurz aktiviert. Im Warenkorb wird mir jetzt aber keine neue Ansicht in der Bestellabwicklung angezeigt wie auf den Screenshots von Paypal sondern bei Zahlungsarten eine ewig große Liste was PayPal Checkout alles anbietet. Das sollte ja mit dem Checkout laut Screenshots professioneller und integraler angezeigt werden.
Ich gehe also davon aus das ich den Updates die angefragt werden allen zustimmen muss damit auch alles im Shop richtig angezeigt werden kann, richtig?
Handelt es sich bei den Update-Fragen somit nur um Paypal-Relevante Abfrage oder sind das allgemeine Abfragen die IMMER kommen?
Frage:
Wie komme ich jetzt einen Schritt zurück, d.h. das ich die fehlenden Updates aufspielen kann, insofern sie wichtig waren? Das Modul deinstallieren wäre eine Weise. Muss ich allen Updates zustimmen oder kann ich differenzieren, z.B. “Templates und Shop-Ordner JA, andere Module und Funktionen die eigentlich nichts mit Paypal zu tun haben NEIN” ?
Zum Deinstallieren habe ich diesen Befehl gefunden:
Die Fragen der Aktualisierung der Module, Themes und Standard Framework source Verzeichnis kommen bei jedem composer update bzw. Modul Installation. Dies ist für den Laien nicht zu überblicken ob dies notwendig ist ja oder nein.
Dies wäre daher ein gutes Beispiel wann man professionelle Hilfe in Anspruch nehmen sollte.
Zur Frage 1: Ja, die Update Abfragen sind Standard und kommen immer. Die PayPal Modul Installation ist nur der Auslöser. Das Modul ist losgelöst vom OXID Framework zu betrachten, es wird nur das Modul installiert und Datenbank Operationen vorgenommen. Am Theme oder anderen Module wird nichts angepasst.
Zur Frage 2: Genau richtig erfasst, die PayPal Modul Installation sollte keine Auswirkungen auf ein anderes Modul haben wie z.B. ein Modul was E-Mail Anhänge an E-Mails dranhängt. Aber ganz ausschließen, dass sich Module gegenseitig in die Quere kommen kann man nie vollständig.
Dort herrscht glaube ich ein großes Missverständnis vor. Das Screenshot was PayPal Beispielhaft auf PayPal Checkout: Die neue Komplettlösung abbildet hat mit der Realität im OXID eShop nicht so viel gemeinsam. Daher wäre Deine Annahme wie es später aussieht falsch.
@naledre dies ist ein gutes Beispiel hier. Das die Erwartungen der Theme Integration eines Zahlungsarten Moduls und der tatsächlichen Anzeige weit von einander abweichen.
Jetzt würde man als Agentur oder Freelancer anfangen, die Frontend Theme Integration ins aktuelle angepasste Shop-Theme (ggfs. Child-Theme) vornehmen. Dort stellt sich die Frage welchen Weg man geht, ob man ein eigenes Modul anlegt um die Template Dateien vom PayPal Modul zu überladen um dadurch Updatesicher zu sein, wenn die wieder die Abfragen ja/nein bei einem Composer Update kommen.
Zeitgleich kann ein Modul Update auch ein eigenes Modul an dieser Stelle unbrauchbar machen, weil sich die Template Struktur zum Beispiel stark geändert.
Ein Modul was so konzipiert ist, dass es sich einfacher von anderen Modulen überladen lässt sollte eigene Smarty Blöcke an kritischen Stellen ermöglichen. Dann lässt sich dieses besser managen in der Wartung anstatt mit der Holzhammer Methode eine komplette Template Datei über ein anderes Modul austauschen zu müssen.
Daher sollte ein PayPal Modul im Idealfall noch eine Skeleton Modul Vorlage für die Überladung beinhalten wie man ein eigenes Modul umsetzt was einem dabei hilft die Zahlungsarten des Moduls ins eigene individualisierte Shop-Theme zu integrieren. Damit man die Darstellung frei gestalten kann.
Jaein, dies bedarf Projektkenntnis und Fachkenntnis um dies abschließend einschätzen zu können. Da jeder Shop am Ende individualisiert ist auf die ein oder andere weise z.B. eigenes Theme oder andere Module im Einsatz. Von den unterschiedlichen Shop-, Theme- und Modulversionen noch abgesehen, was noch erschwerend hinzu kommt.
Wie erwähnt die Abfragen kommen immer. Die Modul Installation nur der Auslöser.
Dort am Besten Dein Full-Backup (Dateiebene + Datenbank) einspielen, weil damit z.B. sichergestellt das keine unerwünschte Überreste in der Datenbank enthalten.
Dies kann man pauschal nicht beantworten. Dies ist von Shop zu Shop unterschiedlich und muss im Einzelfall bewertet werden. Wie ganz oben geschrieben mit einem NEIN sollte man nichts verkehrt machen, weil damit sichergestellt wird das zumindest der IST-Stand erhalten bleibt. Das NEIN bezieht sich auch aufs PayPal Modul selbst.
Wie bereits erwähnt findest die Modul-ID in der metadata.php in Deinem Beispiel:
Dies wäre dann zur Deinstallation (vorab Modul im Admin deaktivieren)
Danke für die ausführliche Antwort die selbst ich verstehe
Da das Modul selbst fehlerfrei installiert wurde brauche ich es nicht löschen.
Noch läuft es nicht, aber da muss Paypal selbst helfen, denn ich komme mit den API Anforderungen nicht klar, die werden nicht akzeptiert. Das wird aber wohl weniger am Modul liegen. Mal sehen was Paypal sagt. Danke soweit erstmal, 10000 Dank!
.