Hallo,
anbei ein gratis [B]PHP7 Update-Paket[/B] für OXID eShop.
Eine Anpassung der Dateien ist nicht mehr notwendig, einfach hochladen und vorhandene Dateien ersetzen. Das ist wirklich alles.
Alle Anleitungen die man aktuell im Netzt findet sind leider unvollständig bzw. berücksichtigen nicht die PHP-Errors. Das Paket wird gerade in 8 Online-Shops erfolgreich eingesetzt ohne irgendwelcher Fehlermeldungen in Error-Logs.
[B]PHP7 Update-Paket[/B]
Grüße
Rafig
Moinsen,
danke für die Infos und das Update! Ich kann es zwar spontan nicht downloaden, da ich total “unsocial” bin, aber laut Beschreibung ist es ja derselbe Inhalt, der sich mehrfach als Anleitung im Netz findet. Das ist auch alles prima und funktioniert tadellos, nur für meinen Geschmack fast zu gut, denn:
… erfolgreich eingesetzt ohne irgendwelcher Fehlermeldungen in Error-Logs.
Und genau das ist aktuell mein Problem: nach Anpassung des oxExceptionHandler bekomme ich als Entwickler keinerlei direkte Rückmeldung mehr seitens PHP, obwohl “display_errors = On” und “error_reporting = E_ALL” sind. Selbst bei trivialen Syntax-Fehlern kommt nur der Offline-redirect und im error_log steht einfach z.b. “Class ‘oxarticle’ not found”, obwohl die Klasse da ist aber halt einen Tipp-Fehler hat o.ä. Das hilft leider nicht wirklich weiter aber kann doch eigentlich nicht sein, oder? Was verstehe ich da evtl. falsch und/oder wie kann man PHP7 für OXID so einstellen, dass Syntax-Fehler wie gewohnt (bei Bedarf) im Browser ausgegeben werden und das Script sofort beenden? Oder anders gefragt: liegt es mir/meinem Setup oder evtl. doch an einer (noch) nicht 100%-tigen PHP7-Kompatibilität, die erst mit OXID 6 kommen wird?
Danke + Gruß
Hallo Mitmacher,
ich glaube, langsam ist es wohl sinnvoller, direkt auf die V6 zu setzen: https://oxidforge.org/en/oxid-eshop-v-6-0-0-rc2-published.html
Gruß
Moin Marco,
okay, danke für den Tipp, ich habe auch gerade deine andere Meldung zu V6-RC2 gelesen. Soll das aber nun meinen Verdacht bestätigen oder habe ich immer noch einen Denkfehler? Außerdem ist es ja noch etwas hin bis zur finalen Version und ich kann und möchte kaum glauben, dass nun seit über einem Jahr niemand sonst dieses Problem hat bzw. sich einfach damit abfindet, kein brauchbares PHP-error_log mehr zu haben?
Grüße
So, nun habe ich hier endlich testhalber auch OXID 6 RC2 am Start, und was soll ich sagen: eigentlich keine Besserung in Bezug auf Syntax-Errors. Sobald z.B. ein überflüssiger Buchstabe in irgendeiner Klasse existiert, heißt es im error_log nur:
PHP Fatal error: Uncaught TypeError: Argument 1 passed to OxidEsales\EshopCommunity\Core\Exception\ExceptionHandler::handleUncaughtException() must be an instance of Exception, instance of ParseError given in D:\www\OXID\html\6.0\vendor\oxid-esales\oxideshop-ce\source\Core\Exception\ExceptionHandler.php:130, …
was einem ja nicht ansatzweise weiterhilft. Und wieso eigentlich im vendor-Dir, denn der Shop liegt doch eigentlich parallel dazu in source? Ich habe immer mehr den Verdacht, dass ich eh nur noch Bahnhof verstehe. Meine Güte, muss denn das alles auf Teufel-komm-raus derart abstrahiert, d.h. verkompliziert werden? :eek:
Hoi Mitmacher 
ich hab den lokalen Dev-Shop mit der Anleitung umgestellt: https://www.zoks.net/kompatibilitat-von-oxid-shop-ce-und-php-7-0/
Und er tut es problemfrei … MIT Meldungen und allem, was das Entwicklerherz begehrt
Er hat es sowohl als 4.10.3 getan, als auch aktuell als 4.10.5
Danke an wolkenkrieger,
aber genau nach der Anleitung bin ich auch vorgegangen. Und sorry, falls es missverständlich war: die Shops laufen damit erstmal tadellos, richtig! Es dürften auch alles dieselben Howtos sein, aus denen “OXID-Design” dann auch das Update-Paket bastelte. Soweit sind wir uns ja alle einig, denke ich. Und klar, es werden auch “Meldungen” ausgegeben, nur welche meintest du genau? Mir geht es halt um die Abwicklung von Syntax-Fehlern, und wenn man einen bestimmten Shop mal vergleicht mit PHP 5.6 und 7.0, dann sieht man doch sofort den Unterschied, oder nicht? In PHP 5.6 wird bei einem Typo z.B. klar gemeldet: Fatal Error in Datei x, Zeile y, usw. Mit PHP 7 aber nicht mehr, sondern halt die erwähnten Meldungen, die einem nichts bringen. Vor lauter verschachtelter Abstraktion bleiben leider die einfachen (aber wichtigen) Basics auf der Strecke, das kann es ja nicht sein! In anderen Projekten, die ich auf PHP7 umstellte, gibt es diese Probleme nicht, also meint OXID es an irgendeiner Stelle etwas zu gut innerhalb des Exception-handlings, fürchte ich. Ich kann mir nur weder vorstellen, dass ich nun der einzige mit diesem Problem bin, noch dass es ansonsten niemanden aufgefallen ist, was ist da nur los?
Welche logs meinst du? Die vom Shop, die vom Server oder die vom Interpreter?
Okay, nochmal sorry, ich dachte der Begriff “error_log” wäre eindeutig gewesen, nämlich das Server-Log vom Apache, bzw. die direkte Anzeige im Browser bei aktivem “display_errors” (zu Testzwecken). Das klappt natürlich auch normal, wenn man z.B. absichtlich mal einen Fehler in die bootstrap.php setzt (also ohne OOP). Aber sobald es in den “Klassen-Dschungel” geht, bleiben solche Fehlermeldungen mit PHP7 leider auf der Strecke, wie übrigens auch, wenn man die obigen Anpassungen im ExceptionHandler vornimmt, aber trotzdem PHP 5.6 einsetzt, das nur mal nebenbei. Schreib doch mal bitte jmd. einfach irgendeinen überflüssigen Buchstaben mitten in die (ox)articles.php und rufe dann das Frontend auf. Wo werden nun solche Fehler getrackt und protokolliert? Ich stehe da echt wie Ochs vorm Berg, und ich arbeite seit über 15 Jahren mit PHP und ca. 7 Jahren mit OXID, bin also zumindest kein blutiger Anfänger… 
Ok … nach einigem Probieren schließe ich mich der Frage mal an?!
Selbst das Ersetzen mit den neuen Throwables bewirkt keine Einträge im Log?!
das Problem ist, dass PHP bei Parse Errors keine Exception wirft, sondern ein ParseError Object.
Oxid will aber eine Exception haben.
Daher kommt nicht die eigentliche Fehlermeldung, sondern die Fehlermeldung, dass die eigentliche Fehlermeldung nicht verarbeitet werden konnte.
Man könnte sagen “OXID scheiterte beim Scheitern” 
das hier könnte vorerst Abhilfe schaffen:
public function handleUncaughtException($exception)
{
if(!$exception instanceof Exception) $exception = new \Exception($exception);
....
[QUOTE=Mitmacher;189081]Es dürften auch alles dieselben Howtos sein, aus denen “OXID-Design” dann auch das Update-Paket bastelte.[/QUOTE]
Nein, das ist doch nicht wahr. Schaut Ihr die Dateien nicht an die Ihr rüber kopiert? Es sind doch mindestens 5-6 Dateien mehr die ich extra angepasst habe.
Wenn ich mehr Zeit habe werde ich deine Änderung zuerst testen und mein Update-Paket dementsprechend aktualisieren.
Grüße
Rafig
meiner Meinung nach sollten ParseErrors grundsätzlich beim Schreiben des Codes vermieden werden durch Verwendung eines entsprechenden Editors.
Darüberhinaus zeigt mir zB IonCube beim codieren auch (Parse)Errors an.
Da stimme ich durchaus zu, aber gerade in der professionellen Umgebung wird der Code für ein Modul oft maschinell aus mehreren Bestandteilen zusammengestellt und dann durch automatische Tests durchgejagt.
Gerade da wäre die echte Fehlermeldung statt dem Abrakadabra doch sehr sinnvoll, um schnell die Ursache des Problems festzustellen.
[QUOTE=vanilla thunder;189091] … die echte Fehlermeldung statt dem Abrakadabra …
[/QUOTE]
… und die sehe ich in meiner Entwicklungsumgebung letztendlich im IonCube…
Hm, okay, dann bin ich halt unprofessionell, da ich nicht IonCube nutze und keine aufgeblähte Entwicklungsumgebung, aber ist das nicht meine legitime Entscheidung? Außerdem ist die OXID-Zukunft doch angeblich unverschlüsselt und es wird uns Entwicklern sogar empfohlen, diese Entscheidung mitzutragen, also bin ich der Zeit doch eigentlich quasi um Jahre voraus!? 
Und @oxid-design:
Nein, das ist doch nicht wahr. Schaut Ihr die Dateien nicht an die Ihr rüber kopiert?
Sorry, dass ich dich in einem Topf warf, aber es ist nun mal so, dass ALLE Howtos identisch sind, also lag der Verdacht schon nahe, dass du auch dazugehörst, nur halt netterweise ein ZIP-Paket geschnürt hattest. Danke dafür, keine Frage, nur wundere dich bitte nicht, dass man es nicht explizit testet, wenn man schon dutzend Mal (vermeintlich) dasselbe gelesen hat und (wie erwähnt) halt wg. der nervigen Social-Buttons es gar nicht erst downloaden darf. Und nein, ich bin da als Facebook-Verweigerer nicht hinterher, sondern wiederum der Zeit voraus, wie ich finde…
Aber egal, zurück zum Thema, prima Kommentar:
Man könnte sagen “OXID scheiterte beim Scheitern”
Und danke für die Lösungs-Idee! Es will aber trotzdem nicht, und ich verstehe die Logik so: wenn $exception NICHT instanceof Exception ist, dann mache es zu einer solchen Instanz. Damit bleibt das Problem doch bestehen, denn ein parseError ist eben nicht mehr “kompatibel”, oder wie? Sorry, leider immer noch Bahnhof…
[QUOTE=Mitmacher;189097]Hm, okay, dann bin ich halt unprofessionell, da ich nicht IonCube nutze und keine aufgeblähte Entwicklungsumgebung, aber ist das nicht meine legitime Entscheidung? Außerdem ist die OXID-Zukunft doch angeblich unverschlüsselt und es wird uns Entwicklern sogar empfohlen, diese Entscheidung mitzutragen, also bin ich der Zeit doch eigentlich quasi um Jahre voraus!?
[/QUOTE]
IonCube ist für uns nur der Gürtel zum Hosenträger.
Das wichtigste ist die Entwicklungsumgebung. Ohne irgendwas gescheites wie zB NetBean kommt man - insbesondere bei PHP7 - nicht weit
Ja gut, ich bezog mich auch nur auf die Verschlüsselung. Und ganz ohne Entwicklungsumgebung arbeite ich natürlich auch nicht, nur ist das über die Jahre sehr individuell gewachsen und der Kern bleibt “nur” ein guter Editor wie UltraEdit. Der kann sogar Syntax-Prüfung, die ich aber bisher nie brauchte, weil PHP immer sagte, wo es genau klemmt. Nun aber nicht mehr, also muss ich mich evtl. umgewöhnen, okay. Wenn es auch nur dieser eine Punkt wäre, könnte ich da wohl mit leben, aber allmählich wächst einem OXID echt über den Kopf. Es wäre interessant, ob das nur mir so geht (also als Einzelkämpfer, nicht als Agentur) aber das wäre hier zu off-topic, um es zu vertiefen. Jedenfalls hat man bis dato halt eigentlich nur einen Editor und ein OXID-ZIP gebraucht und konnte loslegen, wenn man PHP beherrschte (na ja, etwas vereinfacht). Allmählich braucht es wohl ein 10-jähriges Informatik-Studium und Spezialwissen in zig Tools, nur um einen Demo-Shop (v6) zum Laufen zu bringen! Wenn das so weitergeht, bleibt einem fast nichts anderes als aufzugeben, denn vor lauter Administration bleibt leider keine Zeit mehr, um die eigentliche Arbeit zu erledigen die auch Geld einbringt… 
Composer und die ganze andere Grütze ist nur für Entwickler und Agenturen gedacht. Normale Shopbetreiber bekommen weiterhin eine fertige Zip zum Hochladen, zumindest laut Marco.
@patchwork
Ich arbeite auch ohne IonCube (und setze auch keine verschlüsselten Module ein … aus Gründen) aber sowohl mit netbeans als auch mit PHPStorm … trotzdem hätte ich es gerne, wenn mir mein System Fehler meldet - und zwar unabhängig von der IDE.
Und die Intention von mitmacher, mit einfachsten Mitteln PHP und damit auch Oxid entwickeln zu können, ist so verkehrt nicht.
