Wenn ich mir diesen letzten Absatz durchlese
werde ich “unglücklich”.
Falls Composer zum “must have” wird, sehe ich mein EOL mit dem Oxid eShop aufkommen 
Ich glaube, das wurde es bereits. Ohne Composer kann man keine Module für V6 installieren.
Dann wird nach 4.10.x eine andere Shop-Application zur Anwendung kommen.
Haben somit Pech gehabt - weil auf’s “falsche Pferd” gesetzt.
Sowas nennt sich dann auch: “$hit happens”.
Ich denke, über kurz oder lang werden wohl alle Projekte umsteigen. Ich hab mich bereits mit den Contao-Leuten wie auch mit den Typo3-Jungs unterhalten, wo schon lange nix anderes mehr läuft. Composer wird mehr und mehr zum de facto Standard, die Hosting Provider ziehen nach und nach nach. Wenn Du Fragen dazu hast @sieg01, wäre ich glücklich, Dich auf diesem Weg “mitnehmen” zu können.
Ich hatte heute mit unserem Hoster gesprochen.
Er hat nicht vor etwas an den aktuellen Settings zu ändern. Ehrlich gesagt sind wir seit 18 Jahren mit ihm und den Settings gut gefahren - und ich habe keine Motivation den Hoster zu wechseln.
Eine Alternative wäre ein “Dedicated Server” mit ihm… und da spielen wir wieder in einer ganz anderen Liga.
Doch nun kommt erst mal der Weihnachtsstress und danach sieht man weiter.
Hallo Sieg01, willkommen im Club…
@Marco: Ein Standard fällt aber nicht vom Himmel und ist auch keinem Naturgesetz entsprungen, sondern wird als solcher beschlossen und/oder durch allgemeine Praxis dazu gemacht. Von allgemeiner Praxis kann aber keine Rede sein, sonst würden nicht hier und andernorts entsprechende Fragen gestellt werden. Bleibt also die andere Variante, nämlich dass das aktiv gepusht wird. Von wem und warum? Was ist für wen der Vorteil, was sind die Konsequenzen, welches die Bedingungen?
Bei uns z.B. läuft es darauf hinaus, dass wir unseren w7-Rechner, auf dem unser Testsystem läuft, nun ziemlich schnell in ein Dual-Boot-System mit einer Linux-Distribution auf einer eigenen Partition umkonfigurieren müssen, weil wir den Composer nicht unter w7 lauffähig bekommen haben. Wir werden das vermutlich schaffen, andere nicht.
Auch VIrtual Machines werden häufig in diesem Kontext genannt. Ich bekenne, dass ich einen Heidenrespekt davor habe und mir diesen Schritt gerne ersparen würde, wenn es machbar ist.
Leofonic hatte neulich recht freimütig geschrieben:
Nee, ich denke, das ist einiges suboptimal gelaufen, und irgendwann wird man wissen, ob das für OXID der große Sprung oder der große Bauchklatscher gewesen ist (wenn die EntscheidungträgerInnen nämlich u.U. die Community technologisch überfordert haben werden).
Und die Aussage, ‘xyz wird jetzt halt Standard, a und b machen das auch schon, und bald machen es alle’ erklärt leider gar nichts zum Wohin und Woher, sondern sagt auf freundliche Weise: Zieh mit oder lass es bleiben.
Gruß,
Steffen
Hallo Steffen,
schau Dich mal mit offenen Augen um. In der PHP-Welt hat Composer schon vor ca. 2 1/2 Jahren Einzug gehalten, spätestens als es Symfony eingezogen hat. Und man muss wirklich keine Angst davor haben, denn es ist gar nicht so schwer. Man muss sich tatsächlich mal drei Tage damit beschäftigen und wird danach feststellen, dass man es gar nicht mehr missen möchte. Wenn Du dazu Fragen hast, komm gern hier im Forum wieder ran damit: Wenn wir in irgendeiner Form helfen können, machen wir das sehr gern.
Schönen Gruß übrigens von den Teilnehmern des Hackathon, bei dem wir übrigens grad zusammenhocken, verschiedene Module OXID6-kompatibel bauen und voneinander lernen.
Gruß
Marco
Hallo Marco,
danke für’s Angebot, ich bin unverfroren genug und werde zu gegebener Zeit darauf zurück kommen 
.
‘Schwer’ - nun, das ist eine Sache der Perspektive. Klaus Fischer (kennt den heute überhaupt noch jemand?) fand Fallrückzieher auch nicht schwer, und andere würden sich das Genick dabei brechen.
Schönes Wochenende,
Steffen
Ob es nun leicht oder schwer zu lernen ist, ändert leider auch nichts daran, dass man es erst in Hosting Tarifen mit SSH Zugang nutzen kann, und das haben, meiner Einschätzung nach, nur die mittleren und großen Shopbetreiber.
Hmmm.
Ich habe Deine Antwort in einer bestimmten Weise verstanden und hatte eine ziemlich polemische Antwort schon fertig…
Aber im Moment halte ich es noch für sinnvoller, den Sachverhalt erst mittels Verständnisfragen besser zu klären, denn es ist denkbar, dass es sich um ein Mißverständnis handelt.
Tut mir leid, das ist ein bisschen unpräzise formuliert. Was meinst Du mit ‘es’? Soll das bedeuten, dass der OXID-Shop incl. der Community Version ab v6.0.0 nur noch mit SSH betrieben werden kann?
Falls ja:
-
Warum ist das jetzt so?
-
Was wäre die Alternative gewesen?
-
SSH-Zugänge werden von Hostern zwar angeboten, aber das ist technisch / organisatorisch / finanziell so anspruchsvoll, dass sich das nur mittlere und große Shopbetreiber leisten können - habe ich das richtig verstanden?
Falls nein:
- Was hast Du anstatt dessen gemeint?
Gruß,
Steffen
Mit “es” war composer gemeint. Es ist im Endeffekt ein Programm, das auf dem Server installiert und ausgeführt werden muss. Der übliche, falls nicht der einzige, Weg dies zu tun benötigt einen Zugriff auf die SSH Console.
Du hast es richtig verstanden, dem Kunden einen SSH Zugang zu geben erfordert eine aufwändigere Konfiguration, also ist es technisch / organisatorisch komplizierter. Und weil der Kunde dadurch auch mehr machen kann, kostet es natürlich auch mehr Geld.
Und ein Shopbetreiber, der nicht gerade weiß, was SSH ist, neigt dazu nicht den doppelten Preis fürs Hosting mit SSH auszugeben, wobei wir jetzt nüchtern betrachtet von relativ wenig Geld sprechen. Brauchbares Hosting mit SSH kostet pi mal Daumen ab 20 Euro pro Monat ohne SSH 10€. Bei Billigsthostern auch weniger, aber ich würde keine Shops bei netcup oder godaddy hosten. Außerdem ist composer sehr RAM hungrig, ich musste meinen Server von 2 GB auf 4 aufrüsten, um oxid zu installieren.
Ob der Shop ohne Composer betrieben werden kann, weiß ich nicht. Eigentlich kann man auf dem eigenen PC alles installieren und den fertigen Shop nur noch hochladen. Ich selbst habe composer nur oberflächlich benutzt, aber Marco schreibt irgendwo, dass Composer die richtigen PHP Komponenten und Versionen für das jeweilige System (wo es ausgeführt wird) herunterlädt und kombiniert, daher weiß ich nicht, ob es was nützt, lokal composer zu installieren, wenn auf dem Server hinterher andere Komponenten und Versionen benötigt werden, als auf dem eigenen PC.
Das wäre aber schon wieder ein gutes Stück mehr Aufwand für den Shopbetreiber, der eigentlich sein Geschäft führen bzw. Ware verkaufen möchte anstatt sich immer mehr mit dem Shop beschäftigen zu müssen.
@nulldrei, Ich bin übrigens nicht von Oxid sondern auch nur Anwender. So schwer ist das auch alles nicht. Man braucht ja keinen composer auf dem Live-Server, warum das so empfohlen wird kann ich nicht ganz nachvollziehen: Man kann doch einfach den Shop auf einem lokalen Server entwickeln und dann komplett per FTP hochladen. Hätte auch den Vorteil dass man sich nicht mit einem kleinen Kommando den Shop zerschießen kann.
Wenn man sich das Beispiel Contao anschaut, dann haben die Installation mit zip, Updates per copy/paste, Plattformunabhängikeit und Installation und Deinstallation von Erweiterungen per Knopfdruck im Backend. Alles Sachen die es bei Oxid nicht mehr gibt. Apropos Modulinstallation/Deinstallation, das ist ein gutes Beispiel. Ich hätte mir einen standardisierten Modul-Installer gewünscht, bei dem der Modulhersteller spezifizieren kann welche Tabellen und Spalten er hinzufügen will, und diese bei einer Deinstallation (per Knopfdruck) wieder entfernt werden, mitsamt der Modul-Dateien. Bei Oxid musste man schon immer das Modul deaktivieren, dann per FTP löschen, nochmal im Backend die Löschung von Resten bestätigen, und am Ende waren immer noch Modul-Reste in der DB. Daran hat sich nichts geändert, nur jetzt muss man zusätzlich noch composer remove aufrufen, damit wird das Modul zwar auch nicht entfernt, aber unbrauchbar gemacht. Man möge mich erleuchten wenn ich hier was nicht kapiert haben sollte.
Man kann das alles so oder so sehen, Oxid war schon immer sowohl ein Shop-Framework mit dem man tolle Dinge anstellen kann und gleichzeitig eine Standardsoftware die Out-of-the-box funktioniert und sich mit wenig Aufwand modular erweitern lässt. Das Out-of-the-box ist nun etwas zurückgedrängt zugunsten der continuous-*-Fraktion, was m.E. schade ist denn Oxid hat eine super einfache Setup-Routine, ohne Gemecker weil die DB noch nicht existiert etc.
Dennoch würde ich die Wahl des Shopsystems nicht von Composer abhängig machen, die 2-3 Kommandos hat man schnell raus, und Composer auf dem Produktionsserver ist nicht notwendig, es gibt sogar eine offizielle Anleitung dazu: https://docs.oxid-esales.com/developer/en/6.0/getting_started/installation/eshop_installation_without_composer.html
@ nulldrei: Ja es geht um openSSH.
Das wird der Showstopper - wie ich hier schon geschrieben habe: Supportzeitraum 4.10.x
@ marco
Composer hin, Composer her: es geht bei mir nicht um Motivation, technische Skills oder Verweigerung des Mitgehens. Es geht gegenwärtig einzig und allein um den SSH Zugang.
Bezüglich Geld und Hosting:
Für meinen Fall will ich aus diversen Gründen unseren HostingAnbieter nicht wechseln.
Um bei ihm bleiben zu können habe ich 2 Optionen:
- ohne openSSH beim Shared Hosting bleiben
- einen Managed Server zu verlangen
Meinem Eindruck nach (und hoffentlich liege ich nicht richtig) steht Oxid mit 6.x vor dem gleichen Schnitt wie TYPO3 mit der 6.x. (- Welch eine "Namensgleichheit - ob das Zufall ist? )
Einige der “Alten Hasen” werden von Bord gehen und das Vakuum wird evtl. von Newcomern gefüllt. Doch die alte Dynamik und Community wird sich nicht mehr bilden.
Wie du weiter unterschreibst gibts ja noch die continuous-*-Fraktion 
und diesem Umfeld nutz man nicht wirklich seine lokale Machine.
Das ist ja bei OXID schon ein längeres Thema. Auf dem diesjährigen Partnertag wurde dies aber in großer Runde angesprochen und die “Schmerzen” bzw. Verbesserungsvorschläge anfänglich besprochen - das erste mal in den ganzen Jahren. Von dem her bin ich da guter Dinge …
Die Logik mit dem composer oxid-module plugin ist imho auch ein schwieriger Punkt. Bei der Installation kopiert dieses die Dateien aus dem vendor in das source Verzeichnis. Bei darauf folgenden composer Updates muss man explizit bestätigen ob diese überschrieben werden sollen. Was ja eigentlich auch Sinn machen, weil es könnte ja im source/modules-Verzeichnis Änderungen vorgenommen werden. Hier fehlts einfach noch an Best-Practice wie man das am Besten macht. Daher auch die Frage ob das aktuell überhaupt so Sinn macht.
Aber Modulinstallation ist wirklich ein Riesenthema. Die nterschiedlichen Möglichkeiten habe ich in nem Blogpost auch zusammen gefasst. Allein über zwei Stunden haben wir gestern am Hackathon über das Thema Modulinstallation, auch im Zusammenhang mit dem OXID Modulconnector, diskutiert.
Vor Allem das Letztere
Hängt vielleicht auch damit zusammen dass OXID eher “Enterprise” Shops möchte?! Und ohne diese Fraktion geht da halt mal nix …
+1
Prinzipiell könnte man (auch wenn man es nicht will) composer über exec () o. Ä. aufrufen, sofern der Hoster das unterstützt.
Sehe ich nicht wirklich so, ist doch bei Open-Source-Projekten normal, oder nicht!?
Na ja, OXID hat leider sowieso nicht wirklich die beste Community 
Es wäre mal interessant, wieviel Shop-Betreiber ihren Shop auch selber maintainen.
Sehe ich auch nicht so …
Oki, es ging ja um einiges weiter in der Diskussion und eine Menge an Hintergrundinformation ist inzwischen eingeflossen, danke dafür.
Mich wundert jedoch, dass selbst Leute, die offenbar recht dicht am Geschehen sind, sich im Detail widersprechen.
So meint vanilla_thunder, die Nutzung von Composer auf dem Server sei essentiell und kaum zu umgehen, leofonic schreibt hingegen, dass das nicht sein muss, wenn man lokal mit dem Composer sauber arbeitet.
Insgesamt wirkt das ein Stück weit auf mich so, dass aus mir nicht klaren Gründen eine bestimmte Entwicklung forciert und jetzt mit Ecken und Kanten released wurde. Ich lebe immerhin so sehr in dieser Welt, um zu wissen, dass grad in der professionellen Softwareindustrie mitunter Tools halbgar das Licht der Welt erblicken müssen, um vorgeblich Timelines, tatsächlich aber Budgets einzuhalten. Die Qualität des Produkts hat da mit etwas Pech dann nicht unbedingt den Stellenwert, der ihr eigentlich zukommen müsste - aber dafür hat man ja schön preiswert produziert 
.
Jetzt könnte man sagen, stop, wir reden doch über die Community Version, da sollte doch gar kein ökonomischer Druck dahinter stehen. Aber die CV ist ja nicht unabhängig von den kommerziellen Oxid-Versionen, und wie die miteinander verzahnt sind, weiß ich nicht. Möglicherweise wird im wilden Leben der Community vorab getestet, was geht und was nicht bzw. wie einiges zu optimieren ist, so dass dann die kommerziellen Kunden ein konsolidiertes Produkt bekommen.
Der Deal wäre dann: Ihr bekommt’s für lau, aber dafür müsst Ihr mit Problemchen leben, die Ihr dann ggf. löst, was anderswo dann wieder wohlwollend registriert wird.
Anyway: Als Zwischenfazit halte ich für mich fest, dass es Sinn machen könnte, auf einem lokalen Linux mit allen notwendigen Tools (wobei ich diesen Status bislang nur bei Composer sehe, Git wäre hilfreich und ggf. ratsam, aber kein Muss) zu arbeiten. Die lokale Entwicklungsumgebung sollte bzgl. der Serverkonfiguration so dicht wie möglich an den Bedingungen des Produktionsservers dran sein, optimalerweise identisch. Dies vorausgesetzt scheint es möglich zu sein, dass man beim Hoster kein Composer bzw. SSH einsetzen muss, sondern via sFTP den Austausch zwischen lokalem und Online-Server bewerkstelligen kann.
Habe ich etwas übersehen?
Danke und Gruß,
Steffen
Es ist ein Unterschied zwischen Möglich und könnte man …
Ansichtssache:
- composer auf Server JA (jedoch nicht im Live-System, macht aber auch die * Fraktion nicht)
- composer mit php exec () möchte man genauso wenig wie NUR lokal zu nutzen
Danke.
Wenn’s mir nicht zu blöd wäre, würde ich jetzt ne ad hoc-Abstimmung unter den Lesenden machen, wer das in Gänze verstanden hat und wer nicht…
Ich bin gewiss kein DAU, aber seit einiger Zeit habe ich massiv den Eindruck, dass das Gesamt-Handling verkompliziert werden soll.
Na, macht mal.
Wenn von 20 Leuten zehn ihren Oxid-Shop in die Ecke werfen und zehn zwangsweise neue Aufträge vergeben müssen und somit Umsatz generieren, dann hat die Operation ja ihren Zweck erfüllt.
Und wenn die ersten zehn das nicht gestemmt bekommen, selbst schuld, denn es ist ja so was von einfach, wie man ja schon mehrfach im Kontext lesen konnte.
Nabend,
Letztendlich gibt es ein paar geringe Aspekte zu bedenken:
- Ein Shop sollte performant sein.
- Ein Shop sollte schlank sein, auch eine Voraussetzung für 1.
- Damit zumindest bei der CE Version, wobei PE quasi identisch ist, und EE auch nicht sooo wahnsinnig anders, eine relativ einfache Möglichkeit zur Erweiterung bestehen.
OXID macht hier meines Erachtens nach einen Fehler. Im Moment werden immer nur minimal Bugs gefixt, andere sind seid Ewigkeiten offen.
Und klar hat die V6 eine andere Performance, allerdings sehe ich dort mehr PHP7 statt OXID als verantwortliches Instrument.
OXID fördert desweiteren alle möglichen Erleichterungen für professionelle Entwickler, der normale Anwender, dem auch die meisten Installationen zu verdanken sind, wird hier mit Füssen getreten.
Und da ist der Kasus Knacktus. Die, die die CE Version einsetzten und zur Bekannheit von OXID beitragen, haben nicht das Geld für die Agenturen und auch keine Sachkenntnis für eigene Root Server.
Und sich - wie erwähnt - mal 3 Tage mit dem Kram auseinandersetzen können viele auch nicht. Wobei die 3 Tage vielleicht fürs Nutzen der Mechanismen reicht, aber bestimmt nicht fürs wirkliche Verstehen.
So, nun bashed mich
Gruss Marcel
2 Likes
Das ist leider in der neuesten Version Contao 4 auch aus dem Backend geflogen. Vorallem Installation und Deinstallation von Erweiterungen per Knopfdruck im Backend, wurde ausgelagert in den Contao-Manager. Der wegen Speicherhunger auf Shared-Hostingpaketen nicht läuft.
Allerdings ist Contao über die Konsolle per SSH sehr schnell installiert und Updates gehen wie von selbst.
Das Problem, egal ob Contao oder auch OXID 6, sind die Erweiterungen. Man muss sich gut überlegen, ob alle Erweiterungen die neue Version unterstützen. Bei Contao ist 3.5.31 noch bis Mitte 2018 LTS. Wie ist der Releaseplan eigentlich bei OXID?
https://oxidforge.org/en/release-plan
Bringt einen aber aktuell auch nicht weiter ;-/
1 Like