Groupletter

[steri]

achso das hab ich nicht gesehen. hab nur mal schnell das newsletter addon installiert und durchgesehen. wie gesagt bis jetzt nie in verwendung.
nach meinen bisherigen tests läuft der groupletter unter rex4.2 einwandfrei.
dennoch sind anpassungsbugs natürlich noch möglich.

[Gort]

Einwandfrei???

Könntest mir jemand evt. etwas zu den (vor ein paar Posts) beschriebenen Bugs etwas sagen?
Insbesondere der fehlerhafte Import ist ein KO-Kriterium.

[steri]

dem angepassten addon liegt ein csv zum test-import bei. sollte funktionieren.
schon mal installiert und ausprobiert?
http://www.redaxo.de/180-0-addon-detail ... don_id=701

[Gort]

Yep... die meine ich.

Inhalt ist:

Code: Alles auswählen

!Grp!;testgruppe;;;;;;;
!Adr!;email@gmx.de;Herr;Dr.;Max;Mustermann;deutsch;1;testgruppe

testgruppe wird angelegt, aber nicht der Benutzer.

[Gort]

Okay... kann nun teilweise aufloesen, weswegen es bei MIR nicht geklappt hat:

Meine eigene CSV-Datei aus dem alten Groupletter besitzt keine Spalte für "Titel". Ergo - Importfehler.

Die Test-CSV konnte wohl nicht importiert werden, weil ich (Hirni) die Anredefelder schon auf mein Format gebracht hatte und "Herr" als Anrede nicht vorhanden/vorgesehen war. Ergo - Importfehler.

Bleibt noch die Unschönheit, dass haendisch eingepflegte User ein falsches Updatedate bekommen (bei Import korrektes Datum) - aber das ist ja nun auch nicht so wild... also weiter im Text.
Ach ja das Modul wird nicht (wie beschrieben) mitinstalliert, aber ist wohl im Addon Ordner aufzutreiben.
Desweiteren UTF8-Darstellungsfehler en mass und immer noch die Frage, wie denn das Feld heissen soll, dass man nicht erkennen kann [transla

Aber funktioniert bis hierhin schon einmal gut genug, um "am Ball" zu bleiben. Würde mir den Tag verschönern, wenn ich die gesammelten Adressen meines Groupletter aus 3.2 doch weiter nutzen könnte.

[steri]

stimmt - bei utf8 hauts nicht hin mit den umlauten. habs nur unter iso getestet.
welches feld meinst du was nicht sichtbar ist?

[Gort]

In der Benutzertabelle -> die Spalte nach Status.

Bei Spaltenheader war etwas zu lesen von [translate:online] - Die Felder der Spalte selber zeigen nur noch [transla an (8 Zeichen).

Was ist das für eine Spalte und was soll im Feld translated werden?

[steri]

folgendes gehört in die lang:
online = Webseite

das Feld Webseite gibt infos ob sich der benutzer über die webseite angemledet hat oder über csv importiert wurde. ausgabe feld gibt "ja" oder "nein" aus

[Gort]

Okay... scheint da generell noch ein paar Probleme beim direkten Einfügen von Usern über das Backend zu geben.
Sowohl das Datum stimmt dann nicht (1999) und auch das "Webseite-Feld" gibt nur ein "Nein" aus bei den importierten Sachen. Bei den über das Backend eingefügten Usern steht bei mir Z.Zt. nur [transla

[steri]

@ xong:
hab im forum gesehen, dass du dich schon des öfteren mit der problematik utf-8 und iso-8859-1 beschäftigt hast.
ich hätte dazu ein paar fragen - vielleicht kannst du mir weiter helfen.
also bis jetzt hab ich den groupletter nur unter iso-8859-1 verwendet und möchte ihn utf-8 fit machen.
wenn ich von der demo redaxo installation ausgehe, welche ich als iso installiert habe, würde ich ersmal unter System auf utf-8 umstellen. dann im template bei den meta charset auch auf utf-8 umstellen.
Vermutlich muss man dann bei allen inhalte die umlaute usw. neu eingeben bzw. ausbessern, oder?

Was muss ich dann beim grouplette machen?
Die ganze DB ist zwar UTF-8 aber z.b. bei der Benutzerspalte steht beim Namen Kollation "latin1_swedish_ci" - muss man hier auch auf utf-8 umstellen oder kann man dies lassen?

Was muss ich noch beim addon anpassen?
muss ich hier ggf. mit utf8_encode und utf8_decode arbeiten?
Hab kurz getest: wenn ich ich einen neuen user rein schreibe, werden die umlaute auch in der DB schon mit komischen zeichen eingetragen.

danke für die tipps!

[Xong]

Es gibt mehrere Dinge zu beachten. Ich versuche einfach mal alles zusammenzutragen, was da mit reinspielt.

Erstmal allgemein zu Redaxo:

• Wie die Datenbank kodiert ist relativ egal. Du bekommst die Daten so raus, wie du sie reingesteckt hast. Dennoch kann es Probleme geben, wenn ein Entwickler direkt mit denen Daten z. B. über PhpMyAdmin arbeiten möchte. Deshalb solltest du den Bug beim Aufbau der Datenbankverbindung mit UTF-8-Kodierung zumindest für dich beheben.
  In der neuen Version wird er auch nicht mehr vorhanden sein: class.rex_sql.inc.php (Zeile 53-56)
• Die Kollation, die bei MySQL per Standard auf latin1_swedish_ci gestellt ist, hat nicht direkt mit der Kodierung zu tun, sondern arbeitet nur mit ihr Zusammen. Sie bestimmt z. B. wie Textspalten bei Verwendung des "ORDER BY"-Statements sortiert werden oder Vergleiche von Strings ausfallen. Aber das erklärt das MySQL-Handbuch viel besser. =)
• Wenn du deine Ausgabe auf UTF-8 umstellst, verändert das ja noch nicht die Texte, die ISO-8859-1-kodiert waren. Deshalb musst du wirklich alle Texte neu einspielen. Wenn ich eine (Redaxo-)Webseite auf UTF-8 umstellen müsste, würde ich einfach die Datenbank exportieren, löschen, auf UTF-8 umstellen und neu importieren.

Nun zur Addon-Entwicklung:

• Um Addons von der Kodierung unabhängig zu machen, musst (eigentlich kannst, aber du machst dir nur das Leben schwer) du mit Sprachdateien arbeiten.
  Ich habe das auch bei XSearch so umgesetzt. Dort wird in der config.inc.php über folgenden Code die richtige Sprachdatei eingebunden: $I18N->appendFile($REX['ADDON']['dir'][$mypage].'/lang/');
  Das schön ist, dass man sich hier vollkommen auf Redaxo verlassen kann.
• Alle Ausgaben innerhalb des Addons musst du jetzt in diese Sprachdateien, die natürlich auch den richtigen Kodierungen entsprechen müssen, packen. Das geht so: Du wählst einen Bezeichner für den Text, den du ausgeben möchtest, z. B. a123_myaddon_title, und weist diesem mit einem = den gewünschten Text zu: a123_myaddon_title = Titel meines Addons.
  123 ist dabei die ID deines Addons.
• Innerhalb deines Addons kannst du auf diesen Text nun so zugreifen: $I18N->Msg('a123_myaddon_title')
  Dabei kannst du die Ausgabe auch parametrisieren. Bsp.:
  In der lang-Datei steht a123_newsletter_sent = Am {0}.{1}.{2} wurden {3} Newsletter versendet.
  Und die Ausgabe: $I18N->Msg('a123_newsletter_sent', date('d'), date('m'), date('Y'), $sent_count)
  Die Ausgabe sähe dann vielleicht so aus: Am 15.03.2010 wurden 24 Newsletter versendet.
• Vorteil der Arbeit mit Sprachdateien ist nun, dass du dich überhaupt nicht mehr um Kodierung und Sprache kümmern musst. Du benötigst auch kein utf8_encode.
  Diese Freiheit bezahlst du nur mit der Pflicht von Anfang darauf zu achten, konsequent mit diesem System zu arbeiten. Und natürlich mit dem Konvertierungsaufwand, den du jetzt für den Groupletter hast. Aber den hast du ja nur einmal.

Ich hoffe, ich habe jetzt nichts vergessen. Wenn du noch Fragen hast, dann frag ruhig.

Viel Erfolg!

[steri]

danke für die ausführliche antwort!
das mit den sprachdateien ist mit soweit klar.

ich glaub aber das folgende betrifft nicht unbedingt die sprachedateien:

wenn ich einen neuen nutzer eintrage hat dieser keine korrekte umlaute.

ich hab dazu diesen code beim rexkalender gesehen:

Code: Alles auswählen

if ($this->charset == "UTF-8") {
  $monthsArray[$i]=utf8_encode(strftime("%B",$timestamp));
  } else {
  $monthsArray[$i]=strftime("%B",$timestamp);
}

hab das utf8_decode beim groupletter ausprobiert und dies scheint zu
funktionieren (ohne if schleife):

Code: Alles auswählen

if ($this->charset == "UTF-8") { 
$aa->setValue($this->value_tbl[$i],utf8_decode($_REQUEST['eingabe'.$i]));
}
else 
{
$aa->setValue($this->value_tbl[$i],$_REQUEST['eingabe'.$i]);
}

nun weiß ich nur nicht wie ich die charset auslesen kann.
wenn ich $this->charset ausgebe bleibt es leer.

[Xong]

Am Rexkalender solltest du dich nicht orientieren.

Wenn du innerhalb eines Addons für das Backend eine Eingabe definierst, dann sollte diese mit der Kodierung, die in Redaxo eingestellt ist, an dein Addon übergeben werden.
Der Fehler liegt sicher nicht bei der Ausgabe des Addons, sondern viel eher beim Speichern in oder Lesen aus der Datenbank.

Zum Rexkalender: Der Code

Code: Alles auswählen

if ($this->charset == "UTF-8") {
  $monthsArray[$i]=utf8_encode(strftime("%B",$timestamp));
  } else {
  $monthsArray[$i]=strftime("%B",$timestamp);
}

ist ein Sonderfall. Hier werden Ausgaben direkt aus dem Code herausgemacht und müssen deshalb auf die jeweilige Kodierung achten. Das ist genau das, was du vermeiden solltest.

Zu deinem Code:

Code: Alles auswählen

if ($this->charset == "UTF-8") {
$aa->setValue($this->value_tbl[$i],utf8_decode($_REQUEST['eingabe'.$i]));
}
else
{
$aa->setValue($this->value_tbl[$i],$_REQUEST['eingabe'.$i]);
}

Wenn du das an die Datenbank abschickst, dann landen die Daten garantiert nicht UTF-8-kodiert darin. Das ist also genau das, was du vermeiden wolltest.

Um übrigens zu überprüfen, ob UTF-8 verwendet wird, kannst du die Funktion rex_lang_is_utf8() verwenden.

[Gort]

Hallo @ Steri thx 4 the next (utf8) update.

Hier noch eine kleine (optische) Korrektur von mir:
Wenn man in der Datei pages/user.inc.php in Zeile (ca.) 140 aus dem <td> ein </td> (schliessen) macht, sieht die Benutzertabelle im Backend eine Spur besser aus (die erste Spalte mit den ueberfluessigen Bullets verschwindet).

[Gort]

Okay.... erst einmal auf die schnelle: Den vorherigen Post getrost ingnorieren. Das muss man anders machen.

Aber SEHR viel wichtiger.

Welche Funktionen genau sind denn nun erst einmal "auskommentiert"? Kann es wirklich sein, dass du das Double-Opt Verfahren deaktiviert hast? Sorry, aber ohne ist das Teil schlichtweg nicht einsetzbar in Germany (weil nicht erlaubt)!

[meugel]

ich habe eine frage zum datei-import. ich habe eine zweisprachige seite, und dem entsprechend auch beiträge in deutsch und englisch. wenn ich eine tabelle mit adressen habe und schon die jeweilige sprache angebe, werden nur die mit der angabe "english" übernommen, ohne für mich ersichtlichen grund.

meine csv-datei folgt dabei folgender logik:

!Grp!;english;;;;;;
!Grp!;deutsch;;;;;;
!Adr!;email-adresse;[Herr, Frau];Titel;Vorname;Nachname;[english, deutsch];1

bin für jeden tip dankbar!

[meugel]

das problem mit der csv-datei habe ich gelöst, die tabelle zum hochladen hat folgende struktur:

!Grp!;english;;;;;;
!Grp!;deutsch;;;;;;
!Adr!;email-adresse;[Herr, Frau, friend];Titel;Vorname;Nachname;[english, deutsch];1;[english, deutsch]

da ich aber nach wie vor mit anderen problemen des groupletters kämpfe, poste ich erst jetzt. sorry

lg meugel

[meugel]

problem mit email-adressen im groupletter:

wenn eine email-adresse der datenbank fehlerhaft ist (tippfehler o.ä.) oder die email-adresse nicht mehr existiert, dann bricht das script ab und gibt die übliche fehlermeldung "Database down etc." aus.
gibt es da eine möglichkeit, die fehlerhafte email-adresse auszulesen und anzuzeigen?
ich bin leider kein profi in sachen php und mysql und wäre für jeden hinweis dankbar.

lg meugel