nachdem ich im alten Forum leider keine Antwort erhielt und der OXID-Support trotz Wartungsvertrag nicht einmal in der Lage ist innerhalb der ‘garantierten’ Antwortzeiten auch nur zu reagieren geschweige denn zu antworten, versuche ich es mal hier erneut.
Ich habe mich gerade mal an einem Upgrade von PE3.0.4.1 auf PE4.0.0.0 versucht.
Leider erhalte ich beim Aufruf des Shops nach dem Update diese Fehlermeldung:
Fatal error: require() [function.require]: Failed opening required ‘’ (include_path=’.:/usr/share/php:/usr/share/pear’) in /var/www/shop/core/smarty/plugins/modifier.oxmultilangassign.php on line 45
Rootserver:
Apache 2
MySQL 5.0.51a
PHP 5.2.6
Hat jemand ne Idee wo ich noch suchen kann? Ich habe die Upgrade-Prozedur jetzt 6 mal durch und habe mich peinlichst genau an die Anleitung gehalten.
Die 3.0.4.1 läuft auf dem Server problemlos.
Warte noch auf Info vom Oxid-Support. Nun bin ich an der gleichen Stelle angelangt. Neuinstallationen funktionieren, nur das Update geht nicht. Systemvoraussetzungen sind alle gegeben. Hast Du schon eine Lösung gefunden oder bekommen?
ist es vielleicht möglich, dass ein nachträglich eingebautes Smarty-Plugin nicht kompatibel zu einer neueren Version ist?
/smarty/plugins/modifier.oxmultilangassign.php
Gruß
Marco Steinhäuser
Community Operator
OXID eSales AG
Das Shop update besteht ja aus org. Quellen von PE4 und der DB aus unserem Prod-Shop (PE3.x) das per updatescript upgedatet wurde und den Unterschied das die config.inc.php per Hand editiert wurde anstatt das Setup auszuführen.
Es gibt hier nichts nachträgliches, da der Quellcode org. PE4 ist.
Wenn er mir mit SQL Errors kommen würde, könnte ich das ja noch verstehen, aber so?
Wenn es einen Unterschied gibt, dann kann der doch nur aus der Setup Routine kommen. Macht diese Setup Routine noch etwas anderes als die config.inc.php zu befüllen. Habe die config.inc.php verglichen, sind so gut wie identisch, bis auf Pfade, iss klar.
Wundert mich nur, sind wir Vorreiter oder hatte wirklich noch niemand dieses Problem.
Ja klar, während der Setup-Routine werden z.B. auch Rechte auf verschiedene Dateien vergeben (so etwas könnte es hier schon sein).
Du hast geschrieben, Du hättest eine “Upgrade-Prozedur” durchgeführt, statt dessen hast Du ja nur die sql-files in die Datenbank gespielt und einen jungfräulichen 4er Shop davorgesetzt. Das ist ein Unterschied.
Gruß
Marco Steinhäuser
Community Operator
OXID eSales AG
also das mit den Rechten glaube ich nicht so recht, bzw. habe schon rekursiv alle Rechte Variantionen durchprobiert (0775 oder auch mal 0777).
Ansonsten denke ich, habe ich alles richtig gemacht. Genauso ist es ja auch in der Update Anleitung beschrieben.
[ol]
[li] Backup[/li]
[li] Alle Module deaktivieren.[/li]
[li] Datenbank update.[/li]
[li] Jungfreuliches PE4 drauf kopieren.[/li]
[li] Setup Ordner löschen.[/li]
[li] Config von Hand anpassen.[/li]
[li] Willy go![/ol][/li]Ergebniss: Fatal error: require() [function.require]: Failed opening required ‘’ (include_path=’.:/usr/share/php:/usr/share/pear’) in /var/www/xxxx_pe4/core/smarty/plugins/modifier.oxmultilangassign.php on line 45
Ich möchte nochmal betonen, das alle Servervorraussetzungen gegeben sind. Die jungfreuliche Installation von PE4 funktioniert auf Anhieb.
Jemand ne Idee ?
Oder hat hier mal jemand das Update schon erfolgreich durchlaufen?
ich habe das Update auch durchgeführt aber die Bestellung funktioniert nicht. Nachdem “Bestellung absenden” wird nur die Seite neu geladen, man kann nicht die Bestellung absenden.
Könnte jemand mir helfen? (Die Servervoraussetzungen stimmen.)
für mich riecht das noch immer ganz stark danach, als ob jemand mit der upgedateten 4er Version versucht, ein 3er Modul zu laden. Könnt Ihr das bitte mal prüfen?
Gruß
Marco Steinhäuser
Community Operator
OXID eSales AG
Auch ich komme leider nicht weiter. Systemvoraussetzungen sind gegeben. Module 3er aus der DB gelöscht. Die neuen BASIC-Templates sollen genutzt werden.
Ziel ist es lediglich im Step 1 die alten Kunden und Artikel weiterverwenden zu können. Die Anpassung der alten Module folgt dann.
es wird start.tpl mit redirected=1 aufgerufen. Wo führt das hin und wieso ist da nichts.
Desweiteren ist die config.inc.php unten abgeschnitten. Was fehlt da noch alles? das “?>” am Ende ist ja klar, aber dazwischen?
weisse Seite <- nix gut. Hier sollte zumindest ein Fehler auftauchen. Bitte prüf mal, was in Deinem Error log steht. Wenn die config.inc.php abgeschnitten ist, ist sie kaputt und sollte nochmal hochgeladen werden. Manuell darin rumwurschteln bringt gar nix. Wenn eine Datei kaputt ist, liegt die Vermutung nahe, dass es auch andere sind. Mein Vorschlag: Alles nochmal von vorn und schön auf Fehlermeldungen (auch FTP) achten.
Gruß
Marco Steinhäuser
Community Operator
OXID eSales AG
Naja das ja das Problem! Keine Fehler im Log. Und die Datei habe ich mehrmals vom Oxid-Server geladen (sowohl auf dem Mac als auch auf dem PC), in allen Versionen ist die config.inc.php fehlerhaft (auch wenns nur ein fehlendes Endtag ist).
Es geht hier um die PE_4.0.0.0_13934 die im entsprechenden PE_3 Patch zu finden ist.
Alternativ wäre auch ein Updatescript das die Bestellungen/Kunden/Artikel/Kategorien von einer Datenbank in die andere kopiert sehr hilfreich.
keine Fehler und weiße Seite?
Das klingt für mich rätselhaft. Welches Betriebssystem läuft bei welchem Provider mit welcher ZendOptimizer-Version? Hast Du vielleicht zusätzlich den Server gewechselt?
Ich hab mir die config.inc.php und die Upgrade-Scripts grad nochmal angeschaut. Für mich scheint es - trotz fehlendem End-Tag ok.
Gruß
Marco Steinhäuser
Community Operator
OXID eSales AG
Das fehlende End-Tag ist kein Bug, sondern ein Feature und sogar so gewollt. Baut nämlich noch jemand nach dem schließenden Tag eine Leerzeile ein und irgendwann kommt eine header-Anweisung, beschwert diese sich, daß sie nicht gesetzt werden kann, weil schon eine Ausgabe erfolgt ist. Die Leerzeile wurde dann als HTML-Inhalt interpretiert.
Hab da bei eigenen Modulen schon einige Zeit verbracht, um solche Leerzeilen in verschlüsselten Modulen “unschädlich” zu machen. Daher die bessere Lösung: End-Tag weglassen. Da kann das nicht passieren und ist überhaupt nicht falsch. Es tut auch gar nicht weh.
Daniel Seifert
D³ Data Development - Thomas Dartsch
OXID Premium Solution- & Technologiepartnerhttp://www.shopmodule.com
Danke für die Aufklärung Daniel, wusste ich biher nicht.
Allerdings macht es die Sache für mich nicht rund und das Tag weglassen ist m.E. keine bzw eine schlechte Lösung. In diesem Fall geht es nur um eine config-Datei. Aber wenn Entwickler unterwegs sind, dann ist es immer sinnvoll zu signalisieren: “Hallo hier ist mein Ende”
Wenn das ein Feature ist, dann sollten die PHP-Entwickler, das auch so verkaufen. Ich lasse ja auch keine </li> oder sonstige HTML-Tag weg, nur um Daten zu sparen. Grundsätzlich sollte der Interpreter alles erkennen, dann brauch man auch keine Tags mehr, sodern nur mehr Rechenpower (und die kommt ja).
Aber ich entschuldige mich gleich für meinen Aussagen, mir hilft der Beitrag nur nicht weiter.
Falls das Problem noch bestehen sollte: Das Problem hatte ich auch und bin bald verzweifelt. Ein kleiner Vergleich der Daten in den Configs (Testinstallation PE 4 und alte Version) brachte mich aber auf die Idee, evtl. auch noch zu sagen, welche Templates er rendern soll. Ohne das funktioniert alles super, nur halt ohne Template wirst Du nix sehen.
Die Zauberoption heißt: $this->sTheme und sollte den Namen des Verzeichnisses in Deinem Template-Verzeichnis tragen. Standard wäre hier ‘base’ oder ‘former’, wenn Dich an die Anleitung gehalten hast und die alten Templates entsprechend im Filesystem abgelegt hast
