CMS Made Simple Forums

Da das Projekt FEU Mass Mail bisher leider noch keine Version veröffentlicht hat, ich diese Funktion aber dringend brauche, mir aber bei Newsletter Made Simple mit Kanonen auf Spatzen geschossen wird und mein derzeitiger Kunde damit noch weniger klarkommt als ich, habe ich kurzerhand beschlossen mein eigenes Modul zu schreiben.

Herausgekommen ist ein kleines aber feines Mailer Modul mit dem man sehr einfach eine E-Mail an alle User (bzw. an User aus bestimmten Gruppen) des FrontendUser Moduls senden kann:

-> FrontendUser Mailer <-

Eine Art einfaches Kontaktformular mit Speicherfunktion.

Die Doku ist momentan leider nur englisch.
Die deutsche Übersetzung reiche ich noch nach.

Im Text der Nachricht kann der Smarty-Syntax verwendet werden.
Mit dem Smarty-Syntax kann man somit auch auf die Daten der User zugreifen.

Um einen Timeout von Seiten des Servers zu vermeiden (was ja bei 1000 Usern vorkommen kann) verwendet das Modul einen einfachen AJAX Request. Allerdings habe ich bewusst auf den Einsatz von AJAX Made Simple verzichtet, da ich das Modul nicht von zu vielen anderen Modulen abhängig machen wollte.

Benötigt wird lediglich das CMS Mailer und FrontendUsers Modul.

Falls es dennoch zu einem Timeout oder anderen Übertragungsproblemen kommen sollte, wird die momentan versendete Mail mit der ID des letzten Users, dem eine Mail zugesandt werden konnte, temporär in der Datenbank zwischengespeichert.
Somit kann man beim erneuten Versenden die Mail lediglich an die User senden, die diese noch nicht erhalten haben.
Insbesondere hier besteht noch Klärungsbedarf, da es mit ziemlicher Sicherheit vorkommen kann, dass eben dieser letzte User beim erneuten Versenden die Nachricht zweimal bekommt, da die ID entweder vor oder nach dem Versand gespeichert wird. Je nachdem an welcher Stelle es zu einem Timeout kommt, steht die ID des letzten oder des vorletzten Users in der Datenbank. Ich habe bisher noch keine Möglichkeit gefunden, das zu umgehen bzw. zu testen. Aber lieber ein User mit zwei Mails als einer der sie garnicht erhält.

Nach efolgreichem Versandt an alle User werden die temporären Mails wieder gelöscht und bei Bedarf im Archiv gespeichert.
Man kann sowohl archivierte als auch temporäre Nachrichten bearbeiten und erneut versenden.

Da ich offline nicht testen kann, ob die Mails alle tatsächlich ankommen bzw. wie belastbar das Modul bezüglich der Anzahl der User ist und ich außerdem gerade über keine Seite mit ausreichend FrontendUsern verfüge deren Postfach ich ständig mit Testmails bombardieren kann, bin ich auf Eure Hilfe angewiesen.

Weiterhin ist dies mein erstes Projekt bei dem ich AJAX verwende. Daher möchte ich das Modul rundum auf Fehleranfälligkeit, Browserkompatiblität usw. testen.

Ziel ist es, eine stabile Version mit einer kleinen API zu erstellen, die auch von anderen Modulen genutzt werden kann.

Für jede Art von Feedback wäre ich sehr dankbar.

Dieses Projekt hat bisher keine Dateien veröffentlicht.

Noch nicht ganz so der Hit

mike-r wrote:

Dieses Projekt hat bisher keine Dateien veröffentlicht.

Noch nicht ganz so der Hit

Welchen Link hast Du benutzt?
Bei mir steht da ganz groß und breit BETA Releases FEU Mailer 0.8 BETA  July 20, 2008

Bitte erst lesen, dann klicken 

Ieek, war spät

Keine Neuigkeiten sind gute Neuigkeiten

Darf ich annehmen, dass es funktioniert.
Habe gerade 30 Mails (je 10 pro Job) damit versendet.
Scheinen angekommen zu sein.

Wie siehts bei Euch aus?

157 Mal gelesen. (im englischen Forum noch 63 Mal)
36 Downloads.
Und niemand hat mich darauf aufmerksam gemacht, dass nicht eine einzige Mail versendet wurde und bei Unix Servern einige Icons im Backend fehlen.
Schade.
Waren nur drei kleine Tippfehler.
Ist im Release Beta 2 behoben.

So!
Version 0.9 ist draußen.
Ich hoffe, ich konnte alle Fehler beheben (und habe keine neuen eingebaut).
Hab das Modul bisher nur mit folgenden Browsern testen können:

Safari 3
Firefox 2
Firefox 3
Netscape 7
Opera 9

Und das alles erstmal nur lokal auf meinem eMac.
Weiß also nicht wie es mit anderen Betriebssystemen, Browsern oder Serverumgebungen aussieht.
Für Rückmeldungen wäre ich Euch sehr dankbar.

Änderungen:

Kompatibilität mit CMSms 1.5.x hergestellt

Moduleigenes Icon hinzugefügt (das skelet fand ich doof )

Modul-Icons vergrößert

Funktion zum Speichern von Log-Daten gesendeter Mails eingefügt.
(Über diese Funktion können Emails an Benutzer, die zum Zeitpunkt des Versendens keine gültige Emailaddresse angegeben hatten, erneut versendet werden.)

Gespeicherte Mails zeigen nun Anzahl der Empfänger, bearbeiteter Benutzer und Gesamtanzahl von Benutzern der ausgewählten Gruppen an

Bestätigungsmeldungen vor dem tatsächlichen Senden einer Nachricht eingefügt
(Meldung gibt Gesamtanzahl von Benutzern der ausgewählten Gruppen, bereits bearbeitete Benutzer, Empfänger und noch zu bearbeitende Benutzer an)

Funktion zum erneuten Versenden von temporären Emails an alle Benutzer der ausgewählten Gruppen entfernt
Funktion zum Bearbeiten von temporären Emails entfernt
(laufende Jobs können somit nicht mehr geändert, sondern nur noch fortgesetzt werden)

Behebung verschiedener kleiner Fehler

Achja, und die Sprache ist jetzt auch in Deutsch verfügbar.


Bekannte Probleme:

Wenn der Benutzername als Emailaddresse gilt, wird nur diese Addresse verwendet.

Anderenfalls sucht das FrontendUsers Mailer Modul ausschließlich nach einer Benutzereigenschaft vom Typ "email".

Wenn der Benutzer mehrere Emailaddressen angegeben hat, wird nur die erste gefundene Addresse verwendet.

Wenn die Option "Email-Duplikate erlauben" im FrontendUsers Modul aktiviert ist, erhält dieser Email-Account evtl. mehrere Emails.
(hier bin ich mir noch nicht sicher, ob das gut oder schlecht ist)

Wenn Bilder oder andere Medien mit dem WYSIWYG-Editor eingefügt werden, werden diese nicht an die Email angehängt, sondern verweisen auf das Medium auf dem Server.
Diese Verweise werden meist in Form von relativen Pfadangaben eingefügt (z.B. ).
Für eine korrekte Darstellung müssen solche Verweise in absolute Verweise geändert werden (z.B. ).

Einige Smarty-Tags, Plugins oder Module funktoinieren nicht korrekt, da sie unter Umständen Daten aus der Serveranfrage in der Adressleiste des Browser benötigen.
Diese Daten existieren nur dann, wenn die Seite vom Frontend aus aufgerufen wird.
Da die Email aber vom Backend aus verarbeitet wird, fehlen derartige Daten.
Solche Fehler lassen sich leider nicht bzw. nur mit einer Modifikation der betreffenden Funktionen beheben.

Grüße,
NaN.

Ich habs mir gerade mal angeschaut, das sieht wirklich super aus, Gratulation

Ich wollte es eigentlich für meinen derzeitigen Auftrag einsetzen, aber das geht leider nicht, weil sich der Kunde für verschiedene Newsletter-Gruppen anmelden können soll. Ich dachte, das mache ich über die FEU-Gruppen, aber da gibt es keine Möglichkeit, dass der Kunde die Gruppen wählen kann. Naja, vielleicht gehts beim nächsten Auftrag ...

Einen Verbesserungsvorschlag hätte ich aber trotzdem, wenn es mir gestattet ist. Du schreibst, dass man darauf achten soll, dass die Pfade absolut sind. Du könntest doch aber auch mit regulären Ausdrücken die Pfade von Links und Bildern von relativen zu absoluten ersetzen oder?

Auf jeden Fall gute Arbeit

Danke für die Antwort.
Als Newsletter-Modul war es ursprünglich auch nicht gedacht.
Es ging mir vielmehr darum, dass man als Admin in der Lage sein sollte, ganz pauschal seine User zu erreichen.
Nicht nach News-Groups, sondern nach Usergroups sortiert.
Egal ob sie sich zu irgendeinem Newsletter angemeldet haben oder nicht.
Und das ganze so einfach wie möglich.
Wenn ich da jetzt noch anfange eine "Subscribe-Option" einzubauen, würde ich NewsletterMadeSimple neu erfinden.
Und da denke ich macht Calguys Newsletter-Modul schon recht gute Arbeit.
Aber mal sehen was sich da noch machen lässt.

Momentan verwende ich eine von der CMSms API bereitgestellte Funktion zum Rendern von Templates.
Das ist die gleiche Funktion, die vom Core auch zum Rendern im Frontend eingesetzt wird.
Hatte auch schon überlegt, die Mails danach nochmal nach regulären Ausdrücken zu durchsuchen und ggf. zu ersetzen.
Aber einfach pauschal Pfade zu ersetzen, würde dazu führen, dass auch Pfade ersetzt werden würden, die nicht zu irgendwelchen Links sondern tatsächlich zum Text gehören.
Ich dachte mir daher, dass es vielelicht besser wäre, sich mit dem Thema E-Mails noch etwas eingehender zu befassen und solche Medien evtl. als Datei an die Mail anzuhängen.
Bei einigen Webmailern sieht man sowas ja oft, dass z.B. eingebettet Bilder nicht im Text, sondern als Anhang kommen.
Aber möglicherweise ist das auch eine Sache das E-Mailanbieters.
Außerdem glaube ich, dass das im Gegenzug nicht besonders gut für den Traffic des Servers wäre.
Wenn ich jetzt 2000 Mails versende und dann jedesmal noch Bilder o.ä. im Anhang ist...
Na mal sehen...

Ja, das hatte ich mir schon gedacht. Das Modul ist aus meiner Sicht aber einfacher zu bedienen als das NMS Modul, schon allein, weil der Schritt mit den Jobs wegfällt. Es dürfte also den Technik-Muffel meiner Kunden einfacher zu erklären sein. Deshalb hatte ich überlegt, es als Newsletter zu missbrauchen

Anmelde-Templates, etc. würde ich auch weglassen, dafür kann man FEU und SelfRegistration verwenden. Ich wünschte mir beim SelfRegistration Modul allerdings eine Option, dass der Besucher wählen kann, welchen Gruppen er angehört. Diese Funktion könnte man in den Einstellungen ja abschaltbar machen. Aber das ist nicht Dein Bier ...

Das mit den Pfaden könnte man schon mit regulären Ausdrücken lösen, man könnte die Pfade ja nur innerhalb der a-Tags und img-Tags ersetzen. Ich habe sowas vor kurzem bei einem PDF-Generator gemacht, das ist jede Menge Feinarbeit, aber möglich. Falls Du diese Funktion doch einbaust, sollte sie auf jeden Fall abschaltbar sein.

Andiministrator wrote:
Anmelde-Templates, etc. würde ich auch weglassen, dafür kann man FEU und SelfRegistration verwenden. Ich wünschte mir beim SelfRegistration Modul allerdings eine Option, dass der Besucher wählen kann, welchen Gruppen er angehört. Diese Funktion könnte man in den Einstellungen ja abschaltbar machen. Aber das ist nicht Dein Bier ...

Das könnte man evtl. über die Ereignisverwaltung und einen UDT lösen.

Ja, kannst Du diesen Lösungsansatz kurz etwas näher erläutern? Habe mich bisher noch nicht mit UDT beschäftigt.

Ich würde eine Art Basis-Gruppe anlegen.
Jeder, der sich auf der Seite anmeldet gehört automatisch dieser Gruppe an.
Dann würde ich eine Eigenschaft namens "Newsgroups" (oder so) anlegen.
Idealerweise als Mehrfachauswahlfeld.
Dort stehen dann alle weiteren Gruppen (und am besten auch deren IDs) drin.

Die Module Selfreg und FEU senden ja Events, wenn ein neuer User angelegt wird.
Ich weiß jetzt nicht genau welche Parameter da immer mit übergeben werden, aber ich vermute mal die UserID wird da auf jedenfall mit dabei sein.
Über diese UserID könnte man dann in einem UDT die Eigenschaft "Newsgroups" auslesen.
Und dann könnte man mit einer einfachen Datenbankabfrage diesen User den in "Newsgroups" angegebenen Gruppen hinzufügen.

Ist jetzt reine Theorie, aber ich denke es dürfte machbar sein.

Der Vorteil dieser Basis-Gruppe ist der, dass, wenn man ALLE User erreichen will, muss man im FEU Mailer nicht alle Gruppen, sondern nur die Basis-Gruppe auswählen.
FEU Mailer findet dann automatisch alle weiteren Eigenschaften/Gruppen, die zum jeweiligen User gehören.

Klingt gut, werde ich mal testen. Danke für die Erklärung!

Das einzige Problem, welches mir dazu einfällt, ist, dass sich die User nicht so einfach wieder aus einer Gruppe austragen können.
Da müsste man mal schauen, ob FEUsers auch Events sendet, wenn ein User sein Profil ändert und dann wieder mit einem UDT arbeiten.