Keine Texte im Popup Artikel <-> Kategorie Zuordnung

Deutsches Forum
1

Hi,

ich hab das Problem, dass mir weder im Fenster “Kategorien zuordnen” bei den erweiterten Artikel Eigenschaften, noch im Fenster “Artikel zuordnen” unter Kategorien die Texte der Artikel und Kategorien in den beiden Listen angezeigt werden. Anscheinend wird irgendwas aus der DB ausgelesen, da ich eine Tabelle bekomme mit Zeilen, allerdings keine Texte darin. Diese kann ich auch selektieren. Aber nicht per Drag´n´Drop oder irgend wie anders auf die andere Seite bekommen. Allerdings die Buttons “Alle zuordnen” und “Alle Zuordnungen löschen” funktionieren. Danach sind die entsprechenden DB Einträge vorhanden bzw. weg.

Ich tippe auf so was ähnliches wie das Encoding-Problem mit den XML-Files. Vielleicht stimmt das DB-Format der Tabelle nicht oder so was. Leider sehe ich keine Fehlermeldungen. Auch die Debug-Option in OXID-Root funktioniert im Admin-Bereich nicht.

Wie kann ich vor gehen um das ganze zu debuggen?

mfg

Amok

2

Ich stelle gerade fest, wenn man über die Kategorie geht und der Kategorie einen Artikel zuweisen will, geht da nur die linke Liste auf.

Man kann also garnichts von links nach rechts ziehen.

Wenn ich über Artikel gehe und versuche dem Artikel eine Kategorie zuzuweisen erscheinen zwar im Popup 2 Listen, die jedoch auf meiner Produktivmaschine (ein SuSE Server beim Provider) leer bleiben, auf meiner lokalen Testinstalllation (auch SuSE) voll sind.

Was mir ja bereits aufgefallen ist, dass es mit XML Dokumenten Probleme gibt, wegen der ENCODING Einstellung.

Ich vermute, dass hier die Listen über dynamisch generierte XML-Dateien oder XML-Code gefüllt werden sollen, diese aber wieder das unbekannte ENCODING besitzen.

Leider komme ich weder auf Serverseite noch mit Firefox und Firebug näher an das Problem.

Ich wäre sehr Dankbar, wenn das mal jemand nachmachen könnte und seine Erfahrungen damit hier rein stellt.

mfg

Amok

3

Die Datenbank kann eigentlich ausgeschlossen werden, da ich gerade die “Live”-Datenbank ins Testsystem kopiert habe, da läuft alles. Dann wieder zurück ins Live-System, nach wie vor bleiben die Tabellen leer.

Dann habe ich in allen Dateien nach ISO-8859-15 gesucht und das durch UTF-8 ersetzt (wie bei den XML-Dateien). Brachte auch keine Besserung. Eher Probleme mit der Kodierung der Webseiten (fällt sofort bei Umlauten usw. auf). Also wieder zurück.

Ich komm nich drauf, was das sein könnte…

mfg

Amok

4

Hallo Amok,

ich kann das um’s Verrecken nicht reproduzieren. Ich gehe trotzdem davon aus, dass es sich um ein serverseitiges Problem handelt. Kannst Du mir einen Tipp geben, wie man das ggf. in einer VMware nachvollziehen kann?

Gruß

Marco Steinhäuser
Community Guide
OXID eSales AG

5

Ich installiere gerade eine frische SuSE Maschine. Die kannst du dir dann saugen.

Das es ein Server-Problem ist, schließe ich nicht aus, jedoch wäre es interessant zu wissen, was es ist, um es ggf. mit in die Systemvoraussetzungen aufnehmen zu können. Denn ich glaube es ist unnötig zu erwähnen das meine Systeme die aufgeführten Systemvoraussetzungen erfüllen…

Bei der Gelegenheit, ich habe mal gesehen, dass wenn ich einen Artikel in den Warenkorb lege, der Hintergrund ausgegraut wird und eine Meldung kommt, das etwas in den Warenkorb gelegt wurde. Das ist jetzt nicht mehr so ?!? Warum ? Prüft er vielleicht bei der Installation etwas, was man mit dem Dirty-Hack fürs ModRewrite überschreibt, damit das dann geht oder halt nicht? Denn an den Systemen hab ich nichts geändert…

mfg

Amok

6

Habe die SuSE Maschine fertig, und auch eine saubere neue VM mit Debian Lenny frisch von der NetInstallCD und beide machen das gleiche wenn ich über Kategorie rein gehe. Nämlich nach wie vor nur eine Liste…

Außerdem ist mir aufgefallen, dass wenn ich den OXID Download über Windows mache, ich ihn unter Linux nicht mehr mit unzip entpacken kann. Das Archiv ist angeblich immer defekt. Natürlich habe ich es mit mehreren Maschinen und mehreren Downloads versucht…

Sobald ich den Download mit der Linux Maschine mache, kann ich unzipp’en. Vielleicht gibt es da auch Probleme mit der “Windows-Version” wenn man die über FTP auf den Server schiebt…

Spontan will mir aber keine Möglichkeit einfallen, das ZIP auf den WEBSPACE beim Provider zu bekommen und es dort direkt zu extrahieren (kein SSH Zugriff und dergleichen)…

7

So, … bin wieder einen Schritt weiter!

Die nicht vorhandenen Texte stammen tatsächlich (wie ich bereits vermutet habe) aus einem Konvertierungsproblem der Zeichensätze.

Genau wie in den XML-Dateien welche mit einer Kodierung von ISO-8859-15 eingestellt sind, was auf manchen Systemen zu Problemen führt und was dann durch umschreiben des ENCODING in UTF-8 gelöst werden kann, wird in der /pfad/zu/oxid/admin/oxajax.php davon ausgegangen, dass die Texte in ISO-8859-15 vorliegen und irgendwo steht dann

$aData[‘records’][$i][$aKeys[$c]] = iconv(“ISO-8859-15”, “UTF-8”, $aData[‘records’][$i][$aKeys[$c]] );wonach die Daten welche (vermeintlicher Weise) in ISO… geliefert werden nach UTF-8 konvertiert werden sollen.

Jetzt liegen aber bei mir die Daten schon in UTF-8 vor und werden durch den Algorithmus gejagt, und dabei kommt dann irgendwas heraus, …

Aufgefallen ist mir das ganze auch im Shop selber, wo ich nie ein € gesehen habe, sondern im Preis immer ein ¤ stand.

Meine Lösung zu dem Problem ist … einfach in der oxajax.php die obige Zeile auszukommentieren. Dann wird nix Konvertiert, meine € sind da, und die Tabellen in der Artikelverwaltung bzw. Kategoriezuordnung sind wieder voll.

Alles in allem liegt also in allen Punkten die ich bisher gefunden habe ein und die selbe Problematik vor. Es wird nicht geprüft, welcher Zeichensatz verwendet wird, sondern einfach von ISO-8859-15 ausgegangen, jedoch sind diverse Linux-Distris auf UTF-8 geeicht…

Und zu der anderen Tabelle welche man über die Kategorien erreicht um die Artikel zuzuordnen, … da könnt ihr mir erzählen was ihr wollt, das ist ein Bug. Da kommt keine 2. Tabelle!

mfg

Amok

8

Ich habe noch etwas herausgefunden.

Manche PHP-Installationen verfügen nicht über die ICONV, bzw dort wird ICONV gegen eine libiconv gelinkt, welche aber nicht wie ICONV funktioniert.

Das ist wahrscheinlich bei meinem Provider der Fall, und da hilft dann auch nicht die Zeile mit dem ICONV auszukommentieren, denn die Strings müssen ja konvertiert werden. Also muss man die ICONV Funktion ersetzen, was bei mir so funktioniert hat:

// $aData[‘records’][$i][$aKeys[$c]] = iconv(“ISO-8859-15”, “UTF-8”, $aData[‘records’][$i][$aKeys[$c]] ); $aData[‘records’][$i][$aKeys[$c]] = preg_replace("/([\x80-\xFF])/e", “chr(0xC0|ord(’\1’)>>6).chr(0x80|ord(’\1’)&0x3F)”,$aData[‘records’][$i][$aKeys[$c]] );

mfg

Amok

9

Hallo Amok,

der Shop unterstützt momentan eigentlich nur latin1; UTF-8 kommt am 8. April und iconv gehört zu den Systemvoraussetzungen…

Gruß

Marco Steinhäuser
Community Guide
OXID eSales AG

10

Nun ja, … aber AJAX kann ausschließlich UTF8. Darum benötigt ihr ja anscheinend das ICONV.

Und das Problem ist halt, dass mein Provider sagt, ICONV ist da, PHP(info) gibt aus ICONV ist da, die OXID-Installationsroutine geht davon aus ICONV ist da, nur funktioniert das dann auf den Systemen wo ICONV umgelinkt ist trotz des anscheinend positiven Prüfungsergebnisses nicht richtig.

Daher mein Workaround (der im übrigen genau das selbe macht, wie ICONV), weil halt nicht davon ausgegangen werden kann, dass ICONF funktionieren muss auch wenns da is.

Und außerdem hat mein System kein Problem mit Latin1 (ISO-8859-1), sondern mit ISO-8859-15, von dem man nicht mal weis, ob es nun Latin0 oder Latin9 genannt wird. Auch wird nirgendwo erwähnt, dass das System für OXID diese Normen Unterstützen muss.

mfg

Amok

11

Hallo,

ich habe ebenfalls o.g. Probleme (da sind Datenbankeinträge, die sind auch farblich hervorgehoben, aber der Text fehlt) in allen Popups (Artikel, Crossselling, Zubehör, Benutzer, Benutzergruppen).

Ich nutze die Version 4.1.1 unter OpenSuSE 11.0. Systemvoraussetzungen sind soweit alle perfekt. Allerdings habe ich nicht auf UTF-8 umgestellt. Muss ich das jetzt noch nachholen, oder gibt es immernoch ein tiefgreifendes Problem. Mit der oxajax.php ist soweit ich sehen konnte nichts mehr zu machen. Die sieht nach dem Update doch etwas anders aus.

Gruß Uwe

12

Hallo,

die oxajax.php war in meinem Fall (Version 4.1.1, OpenSuSE 11.0, DB nicht auf UTF-8 umgestellt) nach besagtem Schema die Lösung.

Dank, noch mal an Amok

Gruß Uwe