Habe eine grosse Überraschung bei meinem 4.9.2 CE Oxid. Während im Frontend alles so wie es soll und eingegeben wurde dargestellt wird, haben sich im Backend auf einmal viele Datensätze von den Inhalten geändert. Bei Text, Titel, Kurzbeschreibung und Suchbegriffen erscheinen auf einmal andere Inhalte (von anderen Artikeln) im Backend wie im Frontend.
Kurioserweise wird im Backend in der Artikelliste z.B der Titel richtig dargestellt (wie im Frontend), im Tab unter “Stamm” aber ein anderer Titel. Bei manchen Artikeln ist es noch richtig bei anderen nicht mehr.
Es scheint so als wären in der Datenbank z.B. in der Tabelle oxartextends zu jedem Artikel nun zwei unterschiedliche Felder vorhanden wo unterschiedliche Produktbeschreibungen hinterlegt sind, die in älteren Backups der Datenbank noch nicht so waren.
An der Datenbank oder an Files die diese Inhalte auslesen wurde vorher nichts geschraubt.
Hat jemand eine Idee oder sowas schonmal gehabt?
Hallo Soulrider,
ein interessanter Effekt. Was hast Du denn gemacht, dass alles so dargestellt wird?
Gruß
Ich habe den eShop theme switch und damit das mobile Theme aktiviert. Interessanterweise gibt es wahrscheinlich deswegen jetzt auch eine dritte Sprache, siehe:
Oder gibt es die immer?
Wenn ich mir in dieser neuen Sprache die Artikeldaten anzeigen lasse sind die ähnlich falsch wie bei der “richtigen” Sprache Deutsch, aber er zeigt mir in der Artikelliste keinen Titel für den Artikel an, siehe:
Kann es sein, dass bei der Aktivierung des mobile Themes eine zusätzliche Sprache angelegt wird, damit man andere (z.B. kürzere) Artikelbeschreibungen für das mobile Template hinterlegen kann und erstmal default die Daten aus dem ursprünglichen (Desktop) Artikeldatensatz da rein kopiert werden? Vielleicht war die Ausführung des Skripts bei mir irgendwie fehlerhaft und er hat da irgendwas reinkopiert. Was allerdings dann nicht erklärt warum er im Backend dann auch den (Desktop) Artikeldatensatz anders wie im Frontend und fehlerhaft anzeigt. Im Frontend Desktop und Mobile stehen übrigens die gleichen, richtigen Texte.
Nein, Standard ist das nicht.
Unabhängig davon wie jetzt die dritte Sprachversion entstanden ist. Es gibt ja nun drei Spachen bei mir:
[B]Sprachkürzel | Sprache | Sprach-ID[/B]
de | Deutsch | 0 (aktiv)
en | English | 1 (nicht aktiv)
DE | Deutsch | 2 (nicht aktiv)
Kann jemand bestätigen, dass Oxid im Frontend die Artikeldaten anhand der Sprach-ID ausliest und im Backend bei dem Stamm Tab nach dem Sprachkürzel oder der Sprache und wenn hier zwei vorhanden sind halt zufällig eben aus der bei mir Falschen (wo die Inhalte interessanterweise alle aus den Artikeldaten generiert wurden die der Artikel früher mal hatte, bevor er durch “Art. kopieren” dupliziert und die Datenfelder geändert wurden)?
[B]Und natürlich die Königsfrage: [/B]wird wieder alles gut, wenn man einfach die überflüssige Sprachversion löscht?
[QUOTE=Soulrider;158646]
Kann jemand bestätigen, dass Oxid im Frontend die Artikeldaten anhand der Sprach-ID ausliest und im Backend bei dem Stamm Tab nach dem Sprachkürzel oder der Sprache und wenn hier zwei vorhanden sind halt zufällig eben aus der bei mir Falschen (wo die Inhalte interessanterweise alle aus den Artikeldaten generiert wurden die der Artikel früher mal hatte, bevor er durch “Art. kopieren” dupliziert und die Datenfelder geändert wurden)?
[/QUOTE]
Nein, dass kann ich so nicht bestätigen, denn nach meinem Verständnis funktioniert das für Adminbereich und “Frontend” auf dieselbe Art und Weise: Normalerweise werden die sog. Views in der Datenbank verwendet, z.B. oxv_oxarticles_de für die Artikel in deutscher Sprache. Zur Bestimmung des verwendeten Sprachkürzels wird allerdings zuvor die numerische Sprach-ID herangezogen, welche in der Tabelle oxconfig gespeichert wurde.
Die lokalisierten Artikeltexte stehen übrigens in den Feldern mit der ID der jeweiligen Sprache, für die mit der ID 2 also z.B. in oxarticles.oxtitle_2. Vielleicht hilft dir diese Info ja beim Beheben des Problems: http://wiki.oxidforge.org/Downloads/4.5.0#Improvements_in_handling_multiple_languages
Oder schau dir mal mit phpMyAdmin o.Ä. an, was oxv_oxarticles_* so “enthält”.
