Normale Shopbetreiber bekommen weiterhin eine fertige Zip zum Hochladen, zumindest laut Marco.
Das ist mir jetzt neu, beruhigt mich aber ungemein zu hören! 
Allerdings bin ich ja Entwickler, aber da kann/muss man unterscheiden: ich will z.B. nicht unbedingt OXID weiterentwickeln, sondern “nur” Module und Themes erstellen. Warum sollte sich nun jeder Entwickler dafür seine eigene, aber letztlich identische OXID-Source composen lassen? Reicht doch, wenn ein einziger OXID-Profi das hinbekommt und andere daran teilhaben lässt, also wie gehabt, bis wohl auf die kumulativen Updates/Patches (wobei ich gerade die ziemlich genial an OXID fand). Aber dies ist immer noch irgendwie OT, hat nur jmd. schnell noch einen Tipp, ob es irgendwo schon einen Bereich “OXID v6 für Dummies” o.ä. gibt? 
PS: danke, finde ich nämlich auch! 
Und die Intention von mitmacher, mit einfachsten Mitteln PHP und damit auch OXID entwickeln zu können, ist so verkehrt nicht.
Wie sollte es so etwas geben, wenn die Software noch gar nicht in ihrere finalen Ausführung ist?
[QUOTE=vanilla thunder;189104]Wie sollte es so etwas geben, wenn die Software noch gar nicht in ihrere finalen Ausführung ist?[/QUOTE]
Das ist mir natürlich schon klar, aber ich hatte es so verstanden, dass es zukünftig nie wieder ZIPs geben wird, zumindest keine kumulativen. Außerdem kamen bisherige Betas und sonstige Vorabversion doch auch immer als ZIP, was spricht bei V6 nun konkret dagegen?
dadurch, dass es viele kleine Baustellen, Teilprojekte und externe Scripts gibt, an denen parallel gearbeitet wird, müsste man diese ZIP 10 mal am Tag neu erstellen und hochladen. Du müsstest dann theoretisch 10 mal am Tag 150mb herunterladen und erneut auf den eigenen Server hochladen, ggf Dateien vergleichen und ersetzen.
Stattdessen kann man auch einfach “composer update” in die Console eintippen und alle Updates erhalten, ohne dass jemand bei OXID 24/7 damit beschäftigt wäre, ZIPs zu packen.
Okay, grundsätzlich verstanden, aber heißt das, es wird künftig nur noch eine Art Rolling-Release geben und keine eindeutigen Versionsnummern mehr? Das wäre ja die logische Konsequenz, aber ich stelle mir das problematisch vor, wenn z.B. Kunde X sagt: ich habe einen Bug in OXID 6, aber ich kann dies nicht reproduzieren, da es mir aufgrund von 100 neuen Mini-Updates quasi unmöglich ist, genau denselben OXID-Versionsstand herzustellen. Nun denn, ich bin gespannt, wie es in der Praxis letztlich wirklich laufen wird und will da nun gar nicht weiter vorgreifen. Erstmal hier lieber auf das error_log konzentrieren, das scheint ja bereits kompliziert genug zu sein… 
[QUOTE=wolkenkrieger;189102]…
Und die Intention von mitmacher, mit einfachsten Mitteln PHP und damit auch Oxid entwickeln zu können, ist so verkehrt nicht.[/QUOTE]
Sehe ich auch so 
Nur ist das Programmieren mit PHP7 aufwändiger geworden 
[QUOTE=wolkenkrieger;189102]…
Ich arbeite auch ohne IonCube (und setze auch keine verschlüsselten Module ein …
[/QUOTE]
IonCube kann man ja auch ausschließlich zur Verifizierung des Codes verwenden. Ob man verschlüsselten Code ausliefert ist ein anderes Thema.
[QUOTE=wolkenkrieger;189102]…
sowohl mit netbeans als auch mit PHPStorm …
[/QUOTE]
zB NetBeans bieten ja auch ein Testing and Code Analysis Werkzeug.
Grundsätzlich ist meine Meinung: “machs gleich richtig”
Moin Leute,
keine “Rolling-Releases”, es gibt schon noch weiterhin richtige Versionsnummern etc. Die Versionen werden dann quasi aus unterschiedlichen Tags gezogen, z.B. https://github.com/OXID-eSales/oxideshop_ce/tree/v6.0.0-rc.2
Mit den zip-Dateien bin ich mir gar nicht mehr so sicher, ob das überhaupt klappen kann, jedenfalls habe ich mir bisher die Zähne daran ausgebrochen. Es ist aber ein Blogpost in Arbeit, der beschreiben soll, wie man den Shop z.B. auf einem Shared Hosting aufgesetzt bekommt. Das sind halt jetzt die Arbeiten, die zwischen RC2 und dem Stable-Status laufen werden: Dokumentation, Tutorials, Academy anpassen, Update-Pfade festlegen, Module nachziehen etc pp.
Gruß
keine “Rolling-Releases”, es gibt schon noch weiterhin richtige Versionsnummern etc.
Okay, sorry, war ja nur eine fixe Idee gestern, also danke für die Aufklärung! :o
Und um mal zum Anfangs des Threads und somit OXID-Design zurückzukehren: wäre es nicht bitte möglich, dieses umfangreichere ZIP hier zur Verfügung zu stellen (oder woanders, nur ohne Hürden)? Das wäre genial, denn ich bin nun schon gespannt, was da noch weiteres drin ist, von dem ich bisher nichts weiß.
Hi,
das liegt allein in Rafig’s Hand. Ich habe ihm diese Vorgehensweise mehrfach vorgeschlagen. Einfach bei GitHub einstellen, hierher verlinken, im besten Fall auch noch im OMC einstellen: https://github.com/OXIDprojects/OXID-Module-Connector/tree/recipes
Gruß
das liegt allein in Rafig’s Hand
an ebendiesen war die Frage ja auch gerichtet gewesen. Bitte Rafig, sei so nett!
Und wo wir noch beim Thema ZIP sind: hat nicht irgendwer mal bitte einen Link zu einer fertig “composeden” OXID-ce-6.0.0-rc.2 als ZIP? Auch wenn es nicht im Sinne des Erfinders ist, wäre es trotzdem ziemlich hilfreich! Ich muss jetzt nach einigen Tagen nämlich leider aufgeben, die zahlreichen (Firewall, Git, Composer, PHP, etc.)-Probleme verstehen zu wollen. Evtl. ist es das meiste sogar korrekt, nur halt ungewohnt, aber mir fehlt eine Vergleichsmöglichkeit.
Oh, habe ich was verpasst? Funktioniert mein Download-Link im Blog denn nicht?
Gruß
Rafig
wann kommt denn die nächste CE Version heraus bzw. ein Update von 4.10.x auf die Version 5 / 6?
Aktuell erhalte ich die Module für CE nur für php5.6 da ja offiziell CE4.10.x auch nur bis php5.6 läuft.
PHP 5.6 ist gleich PHP 7. Soll bedeuten, laufen die Module im Shop mit 5.6, werden die auch mit PHP 7 funktionieren.
Gruß
Rafig
Echt?
Ich habe das anders verstanden…
unverschlüsselte Module würden in 95% der Fälle ohne Änderungen laufen, die restlichen 5% kann man problemlos anpassen, weil … quelloffen eben.
Aber wenn bei Modulen eine PHP Version angegeben ist, dann handelt es sich um verschlüsselte Module, die für diese eine bestimmte PHP Version verschlüsselt wurden und daher nicht unter PHP7 (und auch nicht php5.4 oder 5.3) laufen werden.
Ich glaube nicht, dass Version 4.x irgendwann mal vom Haus aus mit php7 kompatibel sein wird, denn dann wird die nicht mehr mit php5 kompatibel sein.
OK. Vielen Dank für die Antwort!
Ob verschlüsselt oder nicht verschlüsselt, spielt wirklich keine Rolle.
PHP 5.6 Verschlüsselung <=> PHP 7.x Verschlüsselung.
Zumindest was Ioncube betrifft und bei Zend dürfte dasselbe sein. Läuft das Modul unter PHP 5.6, wird das Modul auch unter PHP 7.x einwandfrei laufen.
Gruß
Rafig
Wird es ein Update von CE 4.10.x auf die V6 geben? Oder muss V6 komplett neu aufgesetzt werden?
Wann wird CE-V6 (?) (also nicht RC) verfügbar sein?
Mit Zend Guard verschlüsselte Module werden nicht auf PHP 7 laufen, weil es ganz einfach kein Zend Guard für PHP 7 gibt.
Marco sagte mal, dass es migration scripts geben wird. Das Update läuft dann etwa so ab, wie damals von 4.6 auf 4.7: Neuinstallation und aktualisierte Datenbank verknüpfen. Bezüglich “wann”, weiß ich nix, aber Partneragenturen bauen schon Shops auf V6 auf, kann also nicht all zu lange dauern.
Wowowow… es gibt einen Migrationspfad von 4.10.6 auf V6:
http://oxid-eshop-developer-documentation.readthedocs.io/en/6.0/update/eshop_from_53_to_6/index.html
Wann wird CE-V6 (?) (also nicht RC) verfügbar sein?
Am Dienstag. RC3 (mit gefixtem Security-Issue) ist durchaus für neue Projekte benutzbar; mit bestehenden Projekten (und entsprechend vielen Modulen) würde ich noch etwas warten.
Und wo wir noch beim Thema ZIP sind: hat nicht irgendwer mal bitte einen Link zu einer fertig “composeden” OXID-ce-6.0.0-rc.2 als ZIP?
Mit Composer wird quasi ein “Artefakt” zusammenkomponiert. Ich bin aktuell am Arbeiten, dass es ab Dienstag aufwärts ein oder mehrere dieser “Artefakte” zum Download als ZIP geben wird. Die Anzahl dieser “Artefakte” hängt stark davon ab, welche Abhängigkeiten von der PHP-Version oder anderen Komponenten entstehen.
1 Like