Hallo Ami, hat leider nichts gebracht.
Habe das komplette upgrade nun ein drittes Mal durchgezogen und nun sind die Daten in den Grundeinstellungen vorhanden. Artikel+Bilder werden im Frontend nun korrekt angezeigt. Ich habe nichts anders gemacht, aber nunja es funzt. Einziges aber großes Manko: die Startseite ist immer noch zerhackt, siehe hier
PS: SEO Url neu berechnen lassen, aber keine Veränderung.
Da sollte was im EXCEPTION_LOG.txt stehen, schau mal nach.
Hallo
Ich habe leider das gleiche Problem wie pimpf7.
Nach der Neuinstallation von 4.7 und der Datenübernahme der alten Dateien funktioniert eigentlich alles, außer die Frontend-Darstellung.
Ich habe ein Template, was Azure erweitert. Alle geänderten Dateien habe ich auf 4.7 angepasst. Aber es scheint weder das CSS, JS noch Teile des Templating geladen zu werden.
Wie ich sehe ist pimpf7 auch noch nicht weiter gekommen…
@OXID: Da es dazu noch nichts von Euch zu hören/lesen gibt: Bitte nehmt Euch mal dieses Problemes an! Ich befürchte, da stimmt was mit der Template-Vererbung nicht oder “wir” haben was beim Kind-Template nicht drin, was obligatorisch ist…
Johannes
Doch, die Template Vererbung funktioniert bestens. Das hier ist zB. eine 4.7 mit Child-Theme, und das ebenfalls.
@pimpf7: Bei mir lag es daran, daß der Verzeichnis-Name des Kind-Templates nicht identisch war mit dem in theme.php angegebenen “title”.
Johannes
Welche produktbezogenen RDFa-Daten sind in der 4.7 implementiert? Auch Preis, Zustand und Lieferbarkeit?
[QUOTE=EnzephaloN;107878]@pimpf7: Bei mir lag es daran, daß der Verzeichnis-Name des Kind-Templates nicht identisch war mit dem in theme.php angegebenen “title”.
Johannes[/QUOTE]
Sorry - lag doch nicht daran. Hatte einige Sachen in den Templates übersehen oder falsch gepatcht.
[QUOTE=Stefan1904;107950]Auch Preis, Zustand und Lieferbarkeit?[/QUOTE]
jepp
@EnzephaloN, danke für die Tipps.
Ich bin heute nochmal alles Punkt für Punkt durchgegangen und habe den Fehler gefunden. Im tmp-Ordner hat sich ein “smarty”-Ordner eingeschlichen, welchen ich zweimal übersehen habe OMG. Ich habe keinen Plan wie mir das passieren könnte :eek:. Ich war bisher auch immer davon ausgegangen, das im tmp-Ordner nur txt, xml und php Dateien landen und keine ganzen Ordner.
Nach entfernen diesen Ordners und erneutes aufrufen der 4.7.0er Installation lief es wie geschmiert.
Falls jemad das gleiche Problem hat, dort evt. mal nachsehen.
[QUOTE=pimpf7;107992] Im tmp-Ordner hat sich ein “smarty”-Ordner eingeschlichen, welchen ich zweimal übersehen habe OMG. Ich habe keinen Plan wie mir das passieren könnte :eek:. [/QUOTE]
…der gehört sich da aber schon rein, würde ich sagen.
Hallo nickname,
habe festgestellt, wenn ich den smarty-Ordner im tmp-Verzeichnis lösche (samt Inhalt), wird er nach aufrufen des Shops wieder automatisch angelegt. Scheint wohl eine Änderung in der 4.7.0er gegenüber den Vorgängern zu sein.
Wenn man also das Tempverzeichnis leert, gilt dies auch für den Inhalt des smarty-Ordners. Ansonsten produziert es Ausgabefehler im Browser.
Ich hoffe man versteht mich, ist schon spät…
naja im smarty ordner ist halt template cache und in der oberssten eben ist php cache 
Hi zusammen,
bin auch gerade dabei, meinen Shop auf die 4.7.0 er mit dem Basic Template hochzuziehen. Nun erhalte ich beim Aufruf des Shops einen 500 er. Kein Eintrag im PHP Error Log und auch kein Eintrag im Exception Log. Sehr eigenartig, denn das hatte mir doch schon immer sehr geholfen.
Bin so vorgegangen:
Backend funktioniert bis auf die entsprechenden Module.
Muss ich meine eigenen Module eigentlich auch anpassen?
Die Struktur von denen sieht so aus:
shopverzeichnis/modules/ownbenefits
Im ownbenefits Verzeichnis liegt dann:
Irgendwelche Ideen, weshalb das nicht klappen will?
[QUOTE=coarsy;108033]Nun erhalte ich beim Aufruf des Shops einen 500 er.[/QUOTE]
Guck mal im Apache Log, da sollte was drinstehen
Apache Error Log ist auch leer… Menno!
So, bin etwas weiter gekommen. Weiß schon gar nicht mehr, an was es nun gelegen hat. Jetzt machen folgende Dinge Probleme:
$colorPosition = oxConfig::getInstance()->getShopConfVar("colorPosition", $sShopId = null );
auch erledigt, heißt nun:
$colorPosition = oxRegistry::getConfig()->getShopConfVar("colorPosition", $sShopId = null );
und komischerweise das hier:
[{oxhasrights ident="SHOWLONGDESCRIPTION"}]
[{oxeval var=$product->getArticleLongDesc()}]
[{/oxhasrights}]
Hat sich erledigt, heißt nun getLongDesc
Jetzt wenn mir noch jemand sagt, wie man wiedder über das Framework auf die Datenbank zugreifen kann, wäre ich fast schon wieder glücklich
$rows = oxDb::getDb(true)->Execute($sSelect);
Das tut irgendwie nicht mehr…
So, das tut nun auch wieder, ich musste allerdings von true auf $rows = oxDb::getDb(2)->Execute($sSelect);
umstellen… Hat hierfür jemand vielleicht eine Erklärung parat?
bei mir geht das, aber bedenke, dass da ein ResultSet Objekt zurückgeliefert wird
Ach ja, noch ein Fehler! In diversen Kategorien werden keine Artikel mehr angezeigt. Ein Blick ins Backend zeigt jedoch, dass diesen Kategorien sehr wohl Artikel zugeordnet sind. Jemand eine Idee, woran das denn nun wieder liegen könnte?
falsche Sprache im Frontend ausgewählt?