Trennzeichen für Gruppenimport

[mirko]

Ich habe für MySQL 4.05 die Doku hier auf meinem Rechner, damit ich keine Funktionen verwende, die es im alten MySQL noch nicht gab, kann die Funktion auch nicht drin sein. Aber 1024 kann halt nicht genug sein, man weiss das nicht vorher, außer man macht vorher wieder ne Abfrage nach allen Gruppennamen, hängt die zusammen, bekommt die Länge, setzt den Wert und macht dann die Abfrage. Das spart aber wahrscheinlich am Ende nichts.

Ich denke, MySQL 4.05 ist nicht mehr zeitgemäß. Ein Export mit Gruppeninfo ist aber auch keine Funktion, die so essentiell ist, wie das Versenden des Newsletters. Es wäre daher kein Problem, wenn es diese Funktion nur gibt, wenn man mindestens SQL 4.1 (eigentlich auch nicht mehr zeitgemäß) einsetzt.
Du kannst group_concat_max_len doch von Haus aus auf max_allowed_packet setzen. Dann sparst du dir die Abfage. Die Länge der Gruppennamen lässt sich außerdem mit einem einfach Sub-Select-SQL-Befehl ermitteln (Ich habe jetzt nicht die genaue MySQL-Syntax nachgesehen, aber ich denke es wird klar, was ich meine).

Die 4.05er Doku nehme ich nur zum Anschauen, ob es die Funktion schon gab und dann bei Google suchen ab wann es diese gab, danach schätze ich "frei" ein, ob ich diese verwenden kann oder nicht. Es gibt auch einige Stellen, die 2 verschiedene SQL-Anweisungen ausführen, je nach dem wie alt die MySQL-Version ist. Sub-Selects gibt es auch noch nicht so lange. Das ist halt der Mist, dass es nicht auf einen Server angepasst ist, sondern auf möglichst vielen laufen muss.

Code: Alles auswählen

SELECT sum(GroupnameLength) from (SELECT Len(Groupname) as GroupnameLength FROM Newelsttergroups ) as tmp ) 

Aber ist ja trotzdem eine SQL-Anweisung mehr, nur um die Länge zu bestimmen. Wenn ich es bei 1024 belasse, dann kommt bestimmt bald einer und meckert weil ein Stück fehlt.

Ich verwende es zumindest nicht, die Gruppennamen getrennt mit Komma, Semikolon, der nächste vielleicht mit Bindestrich und der übernächste mit <li> davor, wird es im Newslettertext nicht geben, weil es halt wieder das Trennzeichen-Problem ist, jeder will es gern anders haben.

Genau, das ist es ja! Jeder möchte es anders haben und braucht es aus einem bestimmten Grund vielleicht auch. Statt künstlich viele Einschränkungen zu machen, wäre eine saubere Trennung der Displayschicht von der Adminschicht die richtige Lösung. Dann kann jeder machen, was er will und es müssen keine Posts geschrieben werden . Satt die Displayschicht in der Gruppendefinition festzulegen, wäre es evtl. sogar noch sinnvoller diese bei der Anzeige (Form, Newsletter) definieren zu können. Dann könnte man verschieden Ausgaben (HTML, Newsetter HTML, Newsletter Text) definieren, also so 'ne Art Mediaquery, wie bei CSS. (man darf ja wohl spinnen und träumen dürfen )

Na klar, noch mehr Aufwand nur weil 2, 3 Mann die Gruppen ausgiebigst verwenden. Das ist doch krank. Im Formular kannst die sichtbaren Gruppennamen anpassen, in dem du halt im HTML-Code zur Integration in die Webseite direkt deine Änderungen einbaust und im Newsletter werden diese nicht angezeigt, weil halt auch das Problem mit den Trennzeichen besteht, der Komma, der nächste Semikolon, <li> usw...

Ja aber es versteht nicht jeder. Der unbedarfte Nutzer in der Marketing-Abteilung hat keine Ahnung wovon ich da rede, der will sich damit auch gar nicht beschäftigen, das ist nicht seine Aufgabe, der will einfach nur das es funktioniert.

Das ist absolut richtig! Der unbedarfte Nutzer aus der Marketing-Abteilung hat wirklich keine Ahnung, wenn er sich nicht ausgiebig damit beschäftigt. Das eigentliche Problem ist, dass ein Server-Newsletter-System mit verschiedenen nicht-standardisierten Clients, sich ständig ändernden gesetzlichen Bestimmungen, etc. nicht einfach ist. Der grundlegende Fehler ist es, jemanden das als einfach zu verkaufen. Ich weiß, dass wird bei allen Computerprogrammen gemacht. Die Sachen sind aber i.d.R. (noch) nicht so einfach, dass sie jeder einfach so kann. Alleine einen HTML-Newsletter zu erzeugen, der auch auf den wichtigsten Clients angezeigt werden kann ist eine Wissenschaft für sich. Das hat mich als versierten Computler zwei Wochen Zeit gekostet. Wie soll das ein Marketing-Angestellter machen, wenn er kein HTML versteht? SWM ist ein Wekrzeut, dessen Umgang man lernen muss.

Der Marketing-A muss sein Layout in verschiedenen E-Mail-Programmen selbst testen oder lässt von einer Agentur das Layout machen und die müssen das testen, nur das machen nur die großen Firmen, denn das kostet richtig Geld.

Ich finde, jeder Schritt, der ein Programm einfacher in der Bedienung macht ist ein guter und wichtiger Schritt. Es spart Zeit, mindert Frust und hilft die Arbeit rechtzeitig fertig zu bekommen. Aber, dass man ein Newsletter-System und einen Newsletter einfach mal so machen kann, ist definitv nicht richtig. Dazu ist dasthema generell zu komplex.

Ja so sehe ich das auch, sage ich auch jedem der hier bei mir anruft, mal schnell jetzt bestellen, Newsletter irgendwie erstellen und 30 Minuten versenden, geht einfach nicht. Das muss man schon in Ruhe machen, das Layout testen, den Versand testen, die Abmeldung testen und dann kann man vielleicht die E-Mails wirklich versenden. Beim nächsten Mal gibt es sicherlich wieder ne Menge zu verbessern ABER die Zeit ist natürlich da, weil das Tagesgeschäft ein ganz anderes ist.

Eine Funktion, wie ein Export mit Gruppenzugehörigkeiten oder die Möglichkeit, Gruppeninfos in einem Newsletter anzuzeigen, würde nicht nur dem NL-Administrator das Leben leichter machen (alleine das einfache Backup aller Daten ist schon viel wert), sondern auch dem Endkunden würde es den Umgang mit dem Newsletter (An-/Abmedlung, etc.) leichter machen. Ich bin überzeugt, dass die Remove-Rate nach einem Newsletterversand geringer ausfallen würde, wenn der Kunde seine Gruppen sehen würde und sich damit gegebenenfalls von einzelnen Gruppen abmelden könnte, statt sich gleich generell abmeldet. Anzeigmöglichkeiten von Gruppen sind daher eine wichtige Sache, um den Grundzweck eines NL-Systems zu verbessern.

Den Export der Gruppenzugehörigkeit gibt es aber der nächsten Version, muss man natürlich aktivieren, Standard ist deaktiviert. Im NL-Text kommt es aber nicht. Wenn man nur an bestimmte Gruppen die E-Mails versendet, dann kann sich derjenige sowieso nur von der jeweiligen Gruppe abmelden und nicht von allen auf einmal. Ist er natürlich dann keiner Gruppe mehr zugeordnet, dann wird er komplett gelöscht.

[MarcusK]

Ich habe für MySQL 4.05 die Doku hier auf meinem Rechner, damit ich keine Funktionen verwende, die es im alten MySQL noch nicht gab, kann die Funktion auch nicht drin sein. Aber 1024 kann halt nicht genug sein, man weiss das nicht vorher, außer man macht vorher wieder ne Abfrage nach allen Gruppennamen, hängt die zusammen, bekommt die Länge, setzt den Wert und macht dann die Abfrage. Das spart aber wahrscheinlich am Ende nichts.

Ich denke, MySQL 4.05 ist nicht mehr zeitgemäß. Ein Export mit Gruppeninfo ist aber auch keine Funktion, die so essentiell ist, wie das Versenden des Newsletters. Es wäre daher kein Problem, wenn es diese Funktion nur gibt, wenn man mindestens SQL 4.1 (eigentlich auch nicht mehr zeitgemäß) einsetzt.
Du kannst group_concat_max_len doch von Haus aus auf max_allowed_packet setzen. Dann sparst du dir die Abfage. Die Länge der Gruppennamen lässt sich außerdem mit einem einfach Sub-Select-SQL-Befehl ermitteln (Ich habe jetzt nicht die genaue MySQL-Syntax nachgesehen, aber ich denke es wird klar, was ich meine).

Code: Alles auswählen

SELECT sum(GroupnameLength) from (SELECT Len(Groupname) as GroupnameLength FROM Newelsttergroups ) as tmp ) 

Ich verwende es zumindest nicht, die Gruppennamen getrennt mit Komma, Semikolon, der nächste vielleicht mit Bindestrich und der übernächste mit <li> davor, wird es im Newslettertext nicht geben, weil es halt wieder das Trennzeichen-Problem ist, jeder will es gern anders haben.

Genau, das ist es ja! Jeder möchte es anders haben und braucht es aus einem bestimmten Grund vielleicht auch. Statt künstlich viele Einschränkungen zu machen, wäre eine saubere Trennung der Displayschicht von der Adminschicht die richtige Lösung. Dann kann jeder machen, was er will und es müssen keine Posts geschrieben werden . Satt die Displayschicht in der Gruppendefinition festzulegen, wäre es evtl. sogar noch sinnvoller diese bei der Anzeige (Form, Newsletter) definieren zu können. Dann könnte man verschieden Ausgaben (HTML, Newsetter HTML, Newsletter Text) definieren, also so 'ne Art Mediaquery, wie bei CSS. (man darf ja wohl spinnen und träumen dürfen )

Ja aber es versteht nicht jeder. Der unbedarfte Nutzer in der Marketing-Abteilung hat keine Ahnung wovon ich da rede, der will sich damit auch gar nicht beschäftigen, das ist nicht seine Aufgabe, der will einfach nur das es funktioniert.

Das ist absolut richtig! Der unbedarfte Nutzer aus der Marketing-Abteilung hat wirklich keine Ahnung, wenn er sich nicht ausgiebig damit beschäftigt. Das eigentliche Problem ist, dass ein Server-Newsletter-System mit verschiedenen nicht-standardisierten Clients, sich ständig ändernden gesetzlichen Bestimmungen, etc. nicht einfach ist. Der grundlegende Fehler ist es, jemanden das als einfach zu verkaufen. Ich weiß, dass wird bei allen Computerprogrammen gemacht. Die Sachen sind aber i.d.R. (noch) nicht so einfach, dass sie jeder einfach so kann. Alleine einen HTML-Newsletter zu erzeugen, der auch auf den wichtigsten Clients angezeigt werden kann ist eine Wissenschaft für sich. Das hat mich als versierten Computler zwei Wochen Zeit gekostet. Wie soll das ein Marketing-Angestellter machen, wenn er kein HTML versteht? SWM ist ein Wekrzeut, dessen Umgang man lernen muss.

Ich finde, jeder Schritt, der ein Programm einfacher in der Bedienung macht ist ein guter und wichtiger Schritt. Es spart Zeit, mindert Frust und hilft die Arbeit rechtzeitig fertig zu bekommen. Aber, dass man ein Newsletter-System und einen Newsletter einfach mal so machen kann, ist definitv nicht richtig. Dazu ist dasthema generell zu komplex.

Eine Funktion, wie ein Export mit Gruppenzugehörigkeiten oder die Möglichkeit, Gruppeninfos in einem Newsletter anzuzeigen, würde nicht nur dem NL-Administrator das Leben leichter machen (alleine das einfache Backup aller Daten ist schon viel wert), sondern auch dem Endkunden würde es den Umgang mit dem Newsletter (An-/Abmedlung, etc.) leichter machen. Ich bin überzeugt, dass die Remove-Rate nach einem Newsletterversand geringer ausfallen würde, wenn der Kunde seine Gruppen sehen würde und sich damit gegebenenfalls von einzelnen Gruppen abmelden könnte, statt sich gleich generell abmeldet. Anzeigmöglichkeiten von Gruppen sind daher eine wichtige Sache, um den Grundzweck eines NL-Systems zu verbessern.

Also Mirko, höre nicht auf SWM zu verbessern! Ich bin schon auf das nächste Update gespannt.

Liebe Grüße aus München
Marcus

Würde denn mein Trick die Kommas als &#44; zu schreiben funktionieren (Trennzeichen zwischen Spalten muss dann natürlich ein Tabulator sein)?

Ja.

Gut, dann habe ich wenigstens einen Workaround.

[mirko]

Hallo Mirko,

Group_concat gibt es in MYSQL ab Version 4.1(.6). 1024 ist nur die Default-Größe:

The result is truncated to the maximum length that is given by the group_concat_max_len system variable, which has a default value of 1024. The value can be set higher, although the effective maximum length of the return value is constrained by the value of max_allowed_packet.

Ich habe für MySQL 4.05 die Doku hier auf meinem Rechner, damit ich keine Funktionen verwende, die es im alten MySQL noch nicht gab, kann die Funktion auch nicht drin sein. Aber 1024 kann halt nicht genug sein, man weiss das nicht vorher, außer man macht vorher wieder ne Abfrage nach allen Gruppennamen, hängt die zusammen, bekommt die Länge, setzt den Wert und macht dann die Abfrage. Das spart aber wahrscheinlich am Ende nichts.

Ich nutze selbst i.d.R MS SQL Server. Der hat leider keiner Group_Concat Funktion, aber ich habe eine entsprechende User Defined Function erstellt, mit der ich das gleiche Ergebnis bekomme. Codebeispiele gibt es viele im Internet. Man kann also auch ohne Group_Concat eine kommegetrennte Liste erzeugen. Mit Group_Concat ist es nur viel einfacher und auch etwas schneller.

Ich verwende es zumindest nicht, die Gruppennamen getrennt mit Komma, Semikolon, der nächste vielleicht mit Bindestrich und der übernächste mit <li> davor, wird es im Newslettertext nicht geben, weil es halt wieder das Trennzeichen-Problem ist, jeder will es gern anders haben.

Die ? sind sehr gut. Das ist ja auch eine Dokumentation. Solange der User über die Seiteneffekte und vor allem das Warum aufgeklärt wird, kann er auch was Vernünftiges und dann auch mit hoher Wahrscheinlichkeit das Gewollte anstellen.

Ja aber es versteht nicht jeder. Der unbedarfte Nutzer in der Marketing-Abteilung hat keine Ahnung wovon ich da rede, der will sich damit auch gar nicht beschäftigen, das ist nicht seine Aufgabe, der will einfach nur das es funktioniert.

Bei SWM hat der Gruppenname zwei Funktionen. Er ist der Displayname und zugleich der Name, um die Gruppe im Admintool anzusprechen (Empfängerauswahl, Import). Die drei Layer (DB, Businesslogik und Display) werden hier zu zwei verbunden und der Businesslogikname hat auch die Funktion des Displaynamens. Deshalb gibt es auch die Kommaprobleme. Intern im DB-Layer werden ja IDs verwendet werden. Es wäre einfacher und problemloser, wenn man in der Adminschicht ein Gruppennamenkürzel hätte. Dann könnte man im Admintool und damit auch beim Importieren kurze Namen ohne Komma oder Sonderzeichen verwenden und für das Display auf der Website einen Displaynamen definieren, der auch Kommas, Zeilenumbrüche etc. enthalten kann (die Displayschicht hat andere Einschränkungen und Codes als die Adminschicht): Z.B. Admin-Gruppenname: MBSW, Displayname: Müncher „Balboa“, „Bal-Swing“ und „Shag“ Wochenende.

Nee nee lass mal, wir wollen es mit den Gruppen nicht noch komplizierter machen. Es bleibt bei dem Gruppennamen und der ID dazu. Der Gruppename darf nicht mit einer Ziffer beginnen und auch keine Kommas enthalten.

Würde denn mein Trick die Kommas als &#44; zu schreiben funktionieren (Trennzeichen zwischen Spalten muss dann natürlich ein Tabulator sein)?

Ja.

[MarcusK]

Hallo Mirko,

Group_concat gibt es in MYSQL ab Version 4.1(.6). 1024 ist nur die Default-Größe:

The result is truncated to the maximum length that is given by the group_concat_max_len system variable, which has a default value of 1024. The value can be set higher, although the effective maximum length of the return value is constrained by the value of max_allowed_packet.

Ich nutze selbst i.d.R MS SQL Server. Der hat leider keiner Group_Concat Funktion, aber ich habe eine entsprechende User Defined Function erstellt, mit der ich das gleiche Ergebnis bekomme. Codebeispiele gibt es viele im Internet. Man kann also auch ohne Group_Concat eine kommegetrennte Liste erzeugen. Mit Group_Concat ist es nur viel einfacher und auch etwas schneller.

Die ? sind sehr gut. Das ist ja auch eine Dokumentation. Solange der User über die Seiteneffekte und vor allem das Warum aufgeklärt wird, kann er auch was Vernünftiges und dann auch mit hoher Wahrscheinlichkeit das Gewollte anstellen.

Bei SWM hat der Gruppenname zwei Funktionen. Er ist der Displayname und zugleich der Name, um die Gruppe im Admintool anzusprechen (Empfängerauswahl, Import). Die drei Layer (DB, Businesslogik und Display) werden hier zu zwei verbunden und der Businesslogikname hat auch die Funktion des Displaynamens. Deshalb gibt es auch die Kommaprobleme. Intern im DB-Layer werden ja IDs verwendet werden. Es wäre einfacher und problemloser, wenn man in der Adminschicht ein Gruppennamenkürzel hätte. Dann könnte man im Admintool und damit auch beim Importieren kurze Namen ohne Komma oder Sonderzeichen verwenden und für das Display auf der Website einen Displaynamen definieren, der auch Kommas, Zeilenumbrüche etc. enthalten kann (die Displayschicht hat andere Einschränkungen und Codes als die Adminschicht): Z.B. Admin-Gruppenname: MBSW, Displayname: Müncher „Balboa“, „Bal-Swing“ und „Shag“ Wochenende.

Würde denn mein Trick die Kommas als &#44; zu schreiben funktionieren (Trennzeichen zwischen Spalten muss dann natürlich ein Tabulator sein)?

Marcus

[mirko]

dein GROUP_CONCAT habe ich mir gerade nochmals genauer angeschaut aber ist nicht verwendbar, da ich nicht weiss wie lang alle Gruppennamen insgesamt mal werden. GROUP_CONCAT ist auf 1024 Zeichen beschränkt, alle andere wird dann abgeschnitten.

[mirko]

Seit wann sind den keine Kommas mehr im Gruppennamen erlaubt? Was meinst du mit "Man kann nämlich die Gruppen mit RG=gruppename1,gruppename2 dem Script nl.php übergeben"? Ich habe das nicht wirklich verstanden. Ich vermute, dass es bedeutet, dass mehrere unserer Newsletter überhaupt nicht zugestellt wurden, weil die ausgewählten Gruppen nicht erkannt wurden? Die Kommas sind bei uns schon in den Gruppennamen seitdem ich die Mailingliste vor über einem Jahr angelegt hatte.

Die Newsletter werden zugestellt, denn da wird mit IDs gearbeitet und nicht mit den Gruppennamen. Man kann aber bei direkten Aufruf des Scripts nl.php mehrere Gruppen mit Komma getrennt übergeben, derjenige wird dann zu den jeweiligen Gruppen angemeldet oder aus den Gruppen entfernt. Wenn jetzt deine Gruppennamen Kommas enthalten, erkennt er natürlich die Gruppen nicht mehr. Ich schätze mal du verwendest das sowieso nicht, damit spielt das keine Rolle. Ab der nächsten Version sind Kommas auf jeden Fall verboten.

Generell kann ich deiner Aussage, dass SWM schon zu viele Einstellungsmöglichkeiten hat und deshalb keiner mehr hinzugefügt werden sollen nicht zustimmen. Eien Software soll das können, was man damit machen muss. Es ist für mich immer im wesentlichen eine Frage der Strukturierung der Optionen und vor allem der Dokumentation. Bei einer guten Dokumentation kann man sich auch als unbedarfter Anwender zurecht finden, weil man dann weiß wofür man eine Einstellung benötigt. Eine Eingabe des Trennzeichens für die Gruppennamen hätte sicher niemanden abgehalten, SWM einzusetzen. Man kann das Feld ja auch erst dann sichtbar machen, wenn man die Gruppenoption wählt. Hier wurde ein tolles Feature nur nicht konsequent implementiert.

Problem die Dokumentation liest keiner und weil ich das weiß, sind bereits überall diese kleinen ? mit Schnellhinweisen hinterlegt.

Nachdem du aber kein Feld hinzufügen willst und die Gruppennamen nun wirklich beknackt aussehen, könntest du dich erwärmen, für die Gruppennamen eine Displayoption hinzuzufügen? Also z.B. Gruppenname: MBSW, Displayname: "Müncher Balboa, Bal-Swing und Shag Wochenende". Dann kann man bequem intern und zum Importieren mit kurzen Namen arbeiten und für die Ausgabe in den Formularen beliebige Sonderzeichen und vor allem auch Kommas verwenden.

nein. Die Gruppennamen haben doch einen "Displaynamen", das ist der Gruppenname selbst. Nur Kommas darfst du nicht verwenden, kannst auch Semikolon ; verwenden, nur wenn du einen Import willst an die Regel denken, wenn Trennzeichen Komma, dann ist Gruppentrennzeichen Semikolon und umgekehrt wenn Trennzeichen Semikolon, dann ist Gruppentrennzeichen Komma. Die Alternative wäre halt ein anderes Trennzeichen z.B. Tabulator verwenden, dann kann es nicht mehr kollidieren.

In dem Footer kannst vergessen, da leiten alle unter Performance-Problemen, nur weil du so eine Funktion willst. Er muss nämlich dann pro Empfänger bei der E-Mail-Erstellung noch eine zusätzliche SQL-Anweisung mit diversen JOINS an den Server senden, um die Gruppenzugehörigkeiten und Namen der Gruppen zu bestimmen. Beim Export ist es genauso, er muss wieder eine zusätzliche SQL-Anweisung verwenden, um Gruppenzugehörigkeiten und Namen zu bestimmen.

Das verstehe ich nicht. Für was brauchst du diverse JOINS? Die Backengine ist doch MySQL, da kannst du doch in einer SQL-Anweisung mit GROUP_CONCAT
für alle Empfänger die Liste ihrer Gruppen erzeugen:

SELECT m.id, GROUP_CONCAT(g.groupname) AS group_list
FROM mailinglist m
INNER JOIN groups g ON(m.id = g.id)
GROUP BY g.id;

Ist da kein JOIN drin? GROUP_CONCAT gibt es erst ab MySQL 5, ich kann es zumindest nicht in der MySQL 4.x Doku finden, ich muss schon noch MySQL 4 kompatibel bleiben, das haben Webspace-Anbieter noch installiert.

Hier wird für jeden Eintrag die mit Komma getrennte Liste der Gruppen erzeugt. Ein Statement für alle Empfänger. Das wird performant auf dem SQL Server abgearbeitet. Mit Admin-Zugriff und grundlegenden SQL-Kenntnissen auf die DB kann man das ja sogar selber abschicken. Schöner wäre das aber schon aus der SWM-Admin Page heraus. Generell sind gut geschriebene SQL statements mit passenden Indizes selten das Bottleneck bei der Performance.

Wir hatten uns schon mal über die Performance unterhalten. Generell denke ich, wäre es besser, wenn du die E-Mails parsen würdest und nur die Felder von der DB abfrägst, die auch wirklich benötigt werden, als immer die gesamte Tabelle abzufragen. Das kann im Extremfall bei vielen gefüllten Feldern und eienr sehr großen Mailingliste einen erheblichen Unterschied in der Performance ausmachen.

Das ist auch richtig aber eben nicht so einfach, wenn noch Funktionen oder Textbausteine eingebaut sind, die Feldinhalte vergleichen und anhand des Vergleichsergebnisses wieder andere Felder ausgeben oder nicht ausgeben, weil der Vergleich unwahr ist.

[MarcusK]

das musst du 2x gepostet haben, ich hatte 2 E-Mails bekommen, bei der einen kam Beitrag nicht gefunden, da habe ich dann den 2. Eintrag auch nicht beachtet.

Ich hatte erst eine zweite E-Mail geschrieben, dann aber die Info in den ersten Post integriert. Damit ist also alles paletti.

Die Sache mit dem Komma oder Semikolon im Gruppennamen ist ein Kompromiss für Profis gewesen, ich kann nicht überall noch mehr Eingabefelder einbauen, der Normalnutzer sieht einfach nicht mehr durch wofür das alles so gedacht ist. Und Kommas im Gruppennamen dürfen nicht vorkommen, das muss ich ändern, eindeutig ein Bug, habe ich nicht abgefangen. Man kann nämlich die Gruppen mit RG=gruppename1,gruppename2 dem Script nl.php übergeben, damit werden deine Gruppennamen mit Komma überhaupt nicht erkannt, das geht voll schief.

Seit wann sind den keine Kommas mehr im Gruppennamen erlaubt? Was meinst du mit "Man kann nämlich die Gruppen mit RG=gruppename1,gruppename2 dem Script nl.php übergeben"? Ich habe das nicht wirklich verstanden. Ich vermute, dass es bedeutet, dass mehrere unserer Newsletter überhaupt nicht zugestellt wurden, weil die ausgewählten Gruppen nicht erkannt wurden? Die Kommas sind bei uns schon in den Gruppennamen seitdem ich die Mailingliste vor über einem Jahr angelegt hatte.

Ich habe jetzt die Kommas über Admin-Zugriff auf die SQL-Tabellen aus den Gruppennamen entfernt. Mit Schräg- oder Bindestrichen schaut das jetzt aber bescheiden aus!

Generell kann ich deiner Aussage, dass SWM schon zu viele Einstellungsmöglichkeiten hat und deshalb keiner mehr hinzugefügt werden sollen nicht zustimmen. Eien Software soll das können, was man damit machen muss. Es ist für mich immer im wesentlichen eine Frage der Strukturierung der Optionen und vor allem der Dokumentation. Bei einer guten Dokumentation kann man sich auch als unbedarfter Anwender zurecht finden, weil man dann weiß wofür man eine Einstellung benötigt. Eine Eingabe des Trennzeichens für die Gruppennamen hätte sicher niemanden abgehalten, SWM einzusetzen. Man kann das Feld ja auch erst dann sichtbar machen, wenn man die Gruppenoption wählt. Hier wurde ein tolles Feature nur nicht konsequent implementiert.

Nachdem du aber kein Feld hinzufügen willst und die Gruppennamen nun wirklich beknackt aussehen, könntest du dich erwärmen, für die Gruppennamen eine Displayoption hinzuzufügen? Also z.B. Gruppenname: MBSW, Displayname: "Müncher Balboa, Bal-Swing und Shag Wochenende". Dann kann man bequem intern und zum Importieren mit kurzen Namen arbeiten und für die Ausgabe in den Formularen beliebige Sonderzeichen und vor allem auch Kommas verwenden.

In dem Footer kannst vergessen, da leiten alle unter Performance-Problemen, nur weil du so eine Funktion willst. Er muss nämlich dann pro Empfänger bei der E-Mail-Erstellung noch eine zusätzliche SQL-Anweisung mit diversen JOINS an den Server senden, um die Gruppenzugehörigkeiten und Namen der Gruppen zu bestimmen. Beim Export ist es genauso, er muss wieder eine zusätzliche SQL-Anweisung verwenden, um Gruppenzugehörigkeiten und Namen zu bestimmen.

Das verstehe ich nicht. Für was brauchst du diverse JOINS? Die Backengine ist doch MySQL, da kannst du doch in einer SQL-Anweisung mit GROUP_CONCAT für alle Empfänger die Liste ihrer Gruppen erzeugen:

SELECT m.id, GROUP_CONCAT(g.groupname) AS group_list
FROM mailinglist m
INNER JOIN groups g ON(m.id = g.id)
GROUP BY g.id;

Hier wird für jeden Eintrag die mit Komma getrennte Liste der Gruppen erzeugt. Ein Statement für alle Empfänger. Das wird performant auf dem SQL Server abgearbeitet. Mit Admin-Zugriff und grundlegenden SQL-Kenntnissen auf die DB kann man das ja sogar selber abschicken. Schöner wäre das aber schon aus der SWM-Admin Page heraus. Generell sind gut geschriebene SQL statements mit passenden Indizes selten das Bottleneck bei der Performance.

Wir hatten uns schon mal über die Performance unterhalten. Generell denke ich, wäre es besser, wenn du die E-Mails parsen würdest und nur die Felder von der DB abfrägst, die auch wirklich benötigt werden, als immer die gesamte Tabelle abzufragen. Das kann im Extremfall bei vielen gefüllten Feldern und eienr sehr großen Mailingliste einen erheblichen Unterschied in der Performance ausmachen.

Marcus

[mirko]

jetzt muss ich das hier nochmals zitieren, weil du zu viel in einen Beitrag geschrieben hast. Die 1.- Antwort hast ja schon

Gibt es in der Zwschenzeit - bis du *hoffentlich* diese Erweiterung implementieren wirst - einen Workaround? Kann man das Komma im Gruppennamen beim Import irgendwie escapen? Ich habe auch versucht, die Gruppennamen in Anführungszeichen zu schreiben, das funktioniert aber auch nicht.

Escapen kann man diese nicht. Da sieht man nämlich auch, wenn man einem Vorschlag nachgibt, was dann später bei rauskommt, irgendwer bekommt dann wieder Probleme.

Ich hatte auch die Idee im Gruppennamen statt den Kommas &#44; zu schreiben. Diese würden zwar in SWM komisch aussehen, aber in allen Web-Formularen müssten sie richtig angezeigt werden. Allerdings kann ich den Gruppennamen nicht ändern nur löschen und neu hinzufügen, was aber die Gruppenzugehörigkeit ebenfalls löscht. Da man ja die Gruppeninfos nicht exportieren kann, kann ich sie auch nicht wieder herstellen. Arggg!

Die Namen kann man nur per phpMyAdmin ändern, die Mailingliste (ab der nächsten Version Empfängerliste) ändern, auf der Registerkarte Allgemein unten steht der Tabellen-Name mit den Empfängern, anstatt das _members am Ende _groups dran hängen, dann kannst direkt die Gruppen ändern und bitte die Kommas entfernen, die dürfen nicht enthalten sein.

Im Moment sehe ich daher nur noch die Möglichkeit, wieder auf die alte umständliche und zeitraubende Weise für unsere 7 Gruppen sieben einzelne Importlisten zu generieren und diese einzeln einzufügen. Ahhhhh! Ich nutze aber inzwischen die Double-Opt-In Option beim Import. Deshalb meine Frage: Ist es richtig, dass der importierte Empfänger nur beim erstemaligen Eintrag in die Liste eine Bestätigungs-E-Mail erhält? Wird in einem zusätzlichen Importschritt eine weitere Gruppe hinzugefügt, bekommt der Empfänger keine weitere Bestätigung, oder?

Wenn er bereits in der Mailingliste (Empfängerliste) ist, bekommt er keine E-Mail mehr.

Ein Forumteilnehmer hatte sich den Export von Gruppeninformationen gewünscht - genaus so wie den Import. Dies würde ich auch unterstützen!
Außerdem wünsche ich mir auch eine Möglichkeit auf die Gruppeninformationen in den E-Mails zuzugreifen. Ich möchte gern, dass ich im Footer meiner Newsletter für jeden Teilnehmer anzeigen kann, welchen Gruppe er ausgewählt hat. Ebenso wäre diese Information im Bestätigungs-E-Mail an den Kunden bzw. an den Admin gewünscht.

In dem Footer kannst vergessen, da leiten alle unter Performance-Problemen, nur weil du so eine Funktion willst. Er muss nämlich dann pro Empfänger bei der E-Mail-Erstellung noch eine zusätzliche SQL-Anweisung mit diversen JOINS an den Server senden, um die Gruppenzugehörigkeiten und Namen der Gruppen zu bestimmen.

Beim Export ist es genauso, er muss wieder eine zusätzliche SQL-Anweisung verwenden, um Gruppenzugehörigkeiten und Namen zu bestimmen.

[mirko]

das musst du 2x gepostet haben, ich hatte 2 E-Mails bekommen, bei der einen kam Beitrag nicht gefunden, da habe ich dann den 2. Eintrag auch nicht beachtet.

Die Sache mit dem Komma oder Semikolon im Gruppennamen ist ein Kompromiss für Profis gewesen, ich kann nicht überall noch mehr Eingabefelder einbauen, der Normalnutzer sieht einfach nicht mehr durch wofür das alles so gedacht ist. Und Kommas im Gruppennamen dürfen nicht vorkommen, das muss ich ändern, eindeutig ein Bug, habe ich nicht abgefangen. Man kann nämlich die Gruppen mit RG=gruppename1,gruppename2 dem Script nl.php übergeben, damit werden deine Gruppennamen mit Komma überhaupt nicht erkannt, das geht voll schief.

[MarcusK]

Hallo Mirko,

du hast meine anderen heutigen Posts bereits beantwortet. Am drigendsten warte ich aber auf eine Antwort zu diesem Post, da wir unsere Newsletter nicht verschicken können. Gibt es hier einen geeigneten Workaround oder vielleicht sogar eine Lösun?.

Marcus

[MarcusK]

Hallo Mirko,

vor einem Jahr hatte ich vorgeschlagen beim Import die Gruppennamen mit einem Trennzeichen trennen zu können. Durch Zufall habe ich mitbekommen, dass das nun geht und war darüber sehr erfreut!!!

Allerdings hielt die Freude nur kurz an. Unsere Gruppennamen enthalten Kommas. Im Forum habe ich gelesen, dass wenn ein Komma als generelles Trennzeichen gewählt wird, der Strichpunkt als Gruppentrennzeichnen verwendet wird. Na ja das funktioniert dann aber auch nicht. Das Problem der Gruppennamen ensteht eigentlich erst dadurch, dass nicht zwischen internen Gruppennamen (kurzer DB-Schlüssel ohne Sonderzeichen) und externem Displaynamen unterschieden wird. In meinen eigenen Formularen kann ich den Text ja ändern, aber die automatischen internen Formulare von SWM nutzen immer den Gruppennamen. Deshalb sah ich mich gezwungen lange Gruppennamen zu verwenden, die Kommas enthalten, wie z.B. "Workshops, Partys, Veranstaltungen (München)". Würde man hier einen internen Kurznamen für den Zugriff auf die Gruppen, wie z.B. beim Import, verwenden, und dann einen Displaynamen für die Anzeige in Formularen etc. (evtl. sogar mit Zeilenumbruch) wäre das eine einfache Lösung für das Problem.

Die zweite naheligenste Lösung wäre, neben die Option "Gruppenname übernehmen aus Feld" auch eine Option "mit Trenzeichen" hinzuzufügen. Dort kann man dann in eine Textbox das gewünschte Trennzeichen eingeben. Es ist doch naheliegend und sinvoll auch hier das Trennzeichen wählen zu können. Die Box kann ja mit einem Komma vorbelegt sein.

Gibt es in der Zwschenzeit - bis du *hoffentlich* diese Erweiterung implementieren wirst - einen Workaround? Kann man das Komma im Gruppennamen beim Import irgendwie escapen? Ich habe auch versucht, die Gruppennamen in Anführungszeichen zu schreiben, das funktioniert aber auch nicht.

Ich hatte auch die Idee im Gruppennamen statt den Kommas &#44; zu schreiben. Diese würden zwar in SWM komisch aussehen, aber in allen Web-Formularen müssten sie richtig angezeigt werden. Allerdings kann ich den Gruppennamen nicht ändern nur löschen und neu hinzufügen, was aber die Gruppenzugehörigkeit ebenfalls löscht. Da man ja die Gruppeninfos nicht exportieren kann, kann ich sie auch nicht wieder herstellen. Arggg!

Im Moment sehe ich daher nur noch die Möglichkeit, wieder auf die alte umständliche und zeitraubende Weise für unsere 7 Gruppen sieben einzelne Importlisten zu generieren und diese einzeln einzufügen. Ahhhhh! Ich nutze aber inzwischen die Double-Opt-In Option beim Import. Deshalb meine Frage: Ist es richtig, dass der importierte Empfänger nur beim erstemaligen Eintrag in die Liste eine Bestätigungs-E-Mail erhält? Wird in einem zusätzlichen Importschritt eine weitere Gruppe hinzugefügt, bekommt der Empfänger keine weitere Bestätigung, oder?

Marcus
P.S:
Ein Forumteilnehmer hatte sich den Export von Gruppeninformationen gewünscht - genaus so wie den Import. Dies würde ich auch unterstützen!
Außerdem wünsche ich mir auch eine Möglichkeit auf die Gruppeninformationen in den E-Mails zuzugreifen. Ich möchte gern, dass ich im Footer meiner Newsletter für jeden Teilnehmer anzeigen kann, welchen Gruppe er ausgewählt hat. Ebenso wäre diese Information im Bestätigungs-E-Mail an den Kunden bzw. an den Admin gewünscht.