Wieso so kompliziert?

Vielleicht ist 6.0 der Anfang vom Ende der CE-Edition. Andere Shops lassen sich in wenigen Minuten ohne Spezialkentnisse installiern; OSCommerce in mal gerade 1 Minute (sofern Datenbank berreits vorhanden).
Dennoch: OXID hat große Vorteile! Bei JTL kostet das Downloadmodul extra und bei mehr als 500 Artikeln fallen sagenhafte Kosten an.

Und genau das kannst Du auch mit dem OXID eShop machen: Einfach herunter laden, auf den Webserver prügeln und dann mit Hilfe des Setups innerhalb kürzester Zeit installieren.

Vielleicht kann ich nochmal etwas zu Composer sagen: Composer ist letztlich nichts Anderes, als das das Paket, das man vorher (und auch jetzt noch) zum Download angeboten bekommt, direkt auf die Serverumgebung abgestimmt wird: Composer sorgt dafür, dass genau die Bibliotheken auf Deinem Server eingesetzt werden, die auch auch dem Server zur Verfügung stehen sollten, damit der Shop sauber und schnell flitzt.

Zusätzlich sorgt Composer dafür, dass Updates und Module (im Gegensatz zu OXID < V6 und zu OSC) versionsabhängig geladen werden können. Wie weiter oben schon erwähnt könnte ich mir vorstellen, dass es perspektivisch auch dafür Klickibunti-Tools geben könnte.

Der Composer zieht Dir quasi das Installationspaket so zusammen, wie Du es vorher als Download irgendwo von uns herunter geladen hast. Nur eben viel besser, weil dieses neue Downloadpaket kein Breitband-Antibiotikum mehr ist sondern sich gezielt um die Schmerzen auf Deinem Server kümmert.

Mal mal den Teufel nicht an die Wand, Theo :wink:
Die CE (resp. die Open-Source-Strategie) kann nicht rückgängig gemacht werden, egal, ob Du damit klarkommst oder nicht. Die von Dir beschworenen “Spezialkenntnisse” belaufen sich lediglich darauf, ob Du gewillt bist, dich auch mal mit der Konsole zu beschäftigen oder ob Du auf Klickibunti festhängst.

Wenn Du Fragen zu diesen “Spezialkenntnissen” hast, wende Dich weiter gern mit konkreten Angelegenheiten an uns. Ansonsten sehe ich diese - m.E. theatralische - Diskussion zunächst mal als abgeschlossen.

1 Like

Oder unter Umständen neuen Hoster zu suchen und bis zu 10fachen hosting Preis zu bezahlen,wenn man keine lokale Installation des Shops auf dem PC machen kann oder will.

Man kann es auch einfach richtig schreiben. :hamburger:

Was meinst du damit?

Stimmt ja nicht, siehe Post drüber von Marco.

Meine Erfahrungen mit 6.0 (Update meines Testshops von 4.10.6)

Benötigte Tools:

  • SSH
  • Composer
  • PHPmyAdmin

Benötigte Fremdsprachen:

  • 1A-English (Wg Anleitung)
  • SQL

Aufwand:

  • Parallelinstallation der Version 6
  • Übertragen und bearbeiten der alten Datenbak inkl.
  • Arbeiten am offenen Herzen der Datenbank (per PHPmySql) um
  • die Datenbak manuell anzupassen (2 Scripte)

Eingriffe in den Webserver:

  • Irgendwie php7 installieren
  • Domainumleitung

Psyche:

  • Zeitdruck, ab Sicherungskopie alte Datenbank
  • Selbstüberwindung um sql-Befehle manuell zu überwinden

Mir kam das ganze sehr Aufwendig vor.

Und jetzt müßte ich für meinen Live-Shop zusehen wie ich in einem 100-GB-Hompage-Paket irgendwie einen SSH-Zugriff hinbekomme oder Composer ans laufen kriege.

Ich bitte um Verständnis Das ist mir erstmal zuviel!

Erstaunlicher Weise gibt es für 6.0 ein Installationspaket nach alter Fasson, weitere werden jedoch nicht folgen.

Du redest gleichzeitig von Upgrade und Erstinstallation. Du kennst den Unterschied? Du kennst auch den Unterschied bei OSC oder jeder anderen Websoftware?

Ja, man braucht möglichst geeignete Werkzeuge. Wenn ich den Rasen in meinem Garten kürzen möchte, macht sich ein Rasenmäher gut. Wenn ich nur eine Nagelschere zur Verfügung habe oder mich weigere an diesen neumodischen Rasenmäher heranzutreten, dauert es eben etwas länger. Und sorry: SSH ist jetzt nichts wirklich Neues und auch keine Raketentechnik, genauso wenig wie PhpMyAdmin, SQL oder Englisch bzw. Google Translate, wenn ich vernünftig Websoftware upgraden, umziehen, analysieren etc. möchte.

Interessant, was Du alles zu wissen meinst…

Moin Marco, das steht aber tatsächlich hier: OXID Forge – Die Knowledge Base rund um den OXID eShop

Manuelle Installation
Es ist nach wie vor möglich, eine gepackte Datei herunterzuladen und
zu installieren. Jedoch ist diese Vorgehensweise weder empfohlen noch
unterstützt. Wenn Du dennoch mit dieser Datei arbeiten möchtest, findest
Du hier alle nötigen Information.

Da steht nirgends dass keine weiteren Packages folgen werden ?! …

Langsam geht mir diese Kindergartendiskussion hier echt auf den Senkel … Geht halt zu OScommerce & Co gehen, da gibts diese ganzen Probleme bestimmt nicht … oder mietet euch nen Strato Shop …

Da steht dass man spätestens beim nächsten Update composer benötigt.

Jain …

Bitte denke daran, dass Du irgendwann sowieso mit Composer arbeiten musst (zumindest auf der lokalen Entwicklungsumgebung), spätestens beim nächsten Software-Update oder wenn Du Module installieren möchtest, die für OXID eShop > 6 geschrieben wurden.

Die ZIP-Packages wie sie Marco zur Verfügung gestellt hat wird es (zwangsweise) auch weiter von der OXID Community geben.

Wenn man ein OXID 6 Modul installieren möchte, was Namespaces benötigt, dann reicht das Package allein nicht aus, dann muss mit dem Modul zusammen eine composer Update gemacht werden.

Und Updates wird es per Zip wahrscheinlich auch nicht geben. In der jetzigen Form ist das DL-Paket daher m.E. kein gangbarer Weg, die Diskussion hatten wir schon mal an anderer Stelle.

Wortklauberei ein
Naja, da steht halt “Jedoch ist diese Vorgehensweise weder empfohlen noch unterstützt.”. Daraus kann man schon verstehen, dass es nix weiteres geben wird, vergleicht man es mit alten Windows-Versionen :joy:. Auf der nächsten Seite (Link) steht dann “noch wird es offiziell unterstützt”, was man wieder anders verstehen kann.
Wortklauberei aus
Ihr habt alle zuviel Zeit: Wieso so kompliziert? - #52 by rubbercut

Einfach mal lesen und darüber nachdenken, warum diese “Diskussion” überhaupt notwendig ist.

Für mich bedeutet der Umstieg auf die V6 zwangsweise, meine gewohnte lokale WAMP-Umgebung gegen eine XAMP auszutauschen und mehr oder weniger einen Spiegel meines Live-Servers herzustellen, weil:

ich auf meinem Live-Server keine Software installiert wissen will, die eine Sicherheitslücke darstellen könnte und die für den Geschäftsbetrieb eigentlich nicht notwendig ist.

Ein Entwickeln auf dem Live-Server (Subdomain, etc.pp.) kommt nicht in Frage.

Luxusproblem, ich weis. Und für die Mehrheit hier sicherlich nicht nachvollziehbar (da sowieso auf Linux unterwegs) aber trotzdem ein Problem. Und wenn ich mir das Gros der Beiträge durchdenke, die hier im Forum als Hilferufe zu lesen sind, erscheint es mir, als dass ich damit nicht unbedingt zur Minderheit der Nutzer gehören dürfte.

Wir hatten im Sommer einen erfolgreichen Angriff auf dem Server, der durch eine Sicherheitslücke möglich wurde, die eine Extension von phpBB gerissen hat (und die Extension selbst nicht mal, sondern Bibliotheken, die als abhängig mitinstalliert wurden, soweit wir das bis dato nachvollziehen konnten) … der damit verbundene Stress hat mir als mahnendes Beispiel mehr als gereicht.

Also ich halte die Entscheidung von OXID bezüglich Composer und Verwendung von Symphony-Modulen etc. für richtig. Das ist state-of-the-art-Technologie.

Allerdings für nichttechnische User möglicherweise zu kompliziert.

Aber: Es spricht doch nichts dagegen, trotzdem ein Installationsfrontend (“Wizard”) zu bauen, das alle Aufgaben im Hintergrund erledigt.

Andere machen das so. Auf die Schnelle fällt mir z.B. das OctoberCMS ein. Es basiert auf Laravel, das wiederum Symphony-Module verwendet, kann auf der Commandline mit Composer installiert werden und es gibt ein schönes Frontend zur Installation ohne Commandline.

Das müsste doch OXID auch fertigbringen.

Abgesehen davon, daß du mit dieser Einstellung keinen Server betreiben kannst (es gibt keine Software, die keine Sicherheitslücke darstellen könnte), spricht genau das für den Einsatz von Composer, weil man damit auf Knopfdruck bzw. durch Tippen von “composer update” sämtliche Teile des Systems auf den neuesten Stand aktualisieren kann.

1 Like

oder genau so auf eine frühere Version downgraden, falls in der neusten Version ein Bug gefunden wurde o.ä.

Darauf kommt es explizit an. Dass der Server grundsätzlich ein latentes Risiko in sich birgt, ist mir durchaus klar. Und solange es notwendige Software betrifft, die unumgänglich ist, muss man dieses Risiko auch tragen. Ein composer ist aber in meiner Denke ein Sicherheitsrisiko, das vermeidbar, weil eigentlich nicht notwendig ist.

Ich will die Vorzüge gar nicht in Abrede stellen. Mein Server-Spezi schwärmt in den höchsten Tönen von composer - auf seiner lokalen Umgebung. In der Live-Umgebung ist das für ihn ein NoGo.

Vielleicht ist es auch nur eine Frage der Kommunikation seitens OXID. Vielleicht sollte darauf hingewiesen werden, dass mit der V6 eben auch eine Mindeststandard-Umgebung für die Wartung und den Betrieb notwendig geworden ist … oder man mit einem zusätzlichen Sicherheitsrisiko leben muss, wenn man diese Umgebung nicht schaffen kann oder will.

Schwierig …