Newslettermodul

florian · 26.03.2017 15:57:28

Newslettermodul,
- Empfänger-Registrierung im Frontend mit double opt in,
- Verwaltung der Empfänger im Backend,
- Newslettertemplates,
- Vorschau des Newsletters vor Versand
- Versand nach und nach möglich (n Empfänger/Stunde) (als Cronjob o.ä.)
- NICHT alle Empfänger im BCC-Feld
- einfache Statistik (Öffnungsraten)
- Versand über die im WBCE-Backend eingestellte Funktion (PHPMailer bzw. SMTP)

Nachtrag
- kompatibel zu WBCE 1.1 und 1.2,
- kompatibel auch zu Fraggy/Beesign-Backendtheme

Ich bin bereit, dafür 500 € beizusteuern.

Last edited by florian (26.03.2017 16:07:07)

grindbatzn · 26.03.2017 22:30:55

Ich hab da ja mal das kleine Modul gemacht. Ist dann stecken geblieben:
http://wbce.at/downloads/wbce_newsletter-0.1.zip
Kennst du ja eh.
Das wäre mal der erste Punkt in deiner Liste - außer du spezifizierst, welche Felder du haben möchtest. ;-)

Die Empfänger-Verwaltung ist da momentan so halb; die nötigen DB Felder sind vorhanden, aber es gibt noch keine Editierfunktionen.

Es gibt auch schon eine Tabelle "newsletters"; aber noch ohne Modify.
Subject und Body wären der Newsletter (Body als HTML mit Platzhalter für den Namen) first_sent, last_sent sind Timestamps, count_sent die Zahl

Ein bissel mein Problem bei der Sache ist auch, dass ich die Mail-Function von WBCE nicht durchschaue.

Der Plan war:
Jeder Newsletter hat eine ID. Beim Trigger wird bei den Empfängern nachgesehen, wer die letzte Newsletter-ID noch NICHT im Feld user_hasgot hat, an diese ersten [einstellbar] wird der Newsletter verschickt, dann in user_hasgot eingetragen (Form: 1,2,3,4, die letzten 100 IDs)

Jeder Empfänger hat 2 ID-Strings, einer intern, einer "öffentlich".
Im Newsletter ist ein Bild mit dem Namen [user_idstr2]-[Newsletter-ID], das ein Script aufruft. Das hängt die Newsletter-ID beim Empfänger user_idstr2 in das Feld user_hasseen
Problem dabei: ICh glaube nicht, dass ein Spamfilter ein Mail durchlässt, das einen Link auf ein Bild mit Extension .php hat. Man muss also mit der .htaccess was tricksen.

Der Trigger:
Das kann schlichtweg der Aufruf des Anmeldeformulars sein. Also die Seite, auf der das Modul ist, wird von irgendeinem Besucher aufgerufen, dann werden im Hintergrund die zb nächsten 5 Newsletter versendet.
Außer man hat weit mehr Empfänger als Seitenbesucher. Dann braucht man einen Cron-Job.

Webversion:
Natürlich braucht man eine Webansicht. Das sollte kein Theater sein.

Ich würde das ja eher so machen, dass ich - mit welchem Modul auch immer! - die Newsletter als Seiten erstelle, dann vorn dort das HTML abhole, in den Newsletter-Body kopiere und das dann absende. Das könnte zb Topics sein, oder nur WYSIWYG-Seiten.

EDIT
Bilder kann man inline versenden oder eben als img-Tag. Vorteil Inline: Die Bilder sind immer dabei, auch wenn das im Mail-Client ausgeschaltet wurde. Nachteil: Technisch nicht ganz trivial, große Mails.
Und das Bild zum Tracken muss sowie als <img> eingehängt sein, klar, sonst kann man es ja nicht tracken.

Last edited by grindbatzn (26.03.2017 22:39:12)

florian · 27.03.2017 08:09:56

Das klingt so weit schon sehr gut, bis auf

Ich würde das ja eher so machen, dass ich - mit welchem Modul auch immer! - die Newsletter als Seiten erstelle, dann vorn dort das HTML abhole, in den Newsletter-Body kopiere und das dann absende. Das könnte zb Topics sein, oder nur WYSIWYG-Seiten.

Das hört sich so nach "Workaround" an (sorry) und ist für Kunden (denn die sollen/wollen damit arbeiten und die wollen Newsletter versenden) auch schon zu kompliziert.
Kurzum: Das Modul muss professionell aussehen und zuverlässig funktionieren.

Das kann schlichtweg der Aufruf des Anmeldeformulars sein.

Der Trigger sollte per Cronjob ansprechbar sein. Der Aufruf des Formulars als Trigger geschieht nicht häugig genug, da dauert es womöglich Tage, bis alle Newsletter versandt sind.

webbird · 27.03.2017 10:11:57

Ich hatte mal angefangen KeepInTouch neu aufzubauen. Wohlgemerkt, nicht Kit2 bzw. kitFramework. Gibt auch irgendwo einen Thread dazu. Da ich sowas nicht zum Selbstzweck programmiere und mir das Feedback fehlte, ist das dann zugunsten anderer Dinge - wie BC2 - erst mal zurückgestellt worden. Bei konkretem Interesse und konkreter Unterstützung (Feedback, Tests) nehme ich das aber gern wieder auf.

Edit: https://forum.blackcat-cms.org/viewtopic.php?f=24&t=501
Edit2: https://forum.wbce.org/viewtopic.php?id=217

Last edited by webbird (27.03.2017 10:14:06)

webbird · 27.03.2017 10:26:57

- Versand nach und nach möglich (n Empfänger/Stunde) (als Cronjob o.ä.)
- einfache Statistik (Öffnungsraten)

Diese zwei Punkte sind nicht ganz trivial. Wir hatten die Diskussion ja schon mal.

"n Empfänger pro Stunde"

Das ist interpretierbar. n auf einen Rutsch und dann den Rest der Stunde idle, oder die Anzahl der Empfänger auf die 60 Minuten verteilen und dann z.B. 5 - idle - 5 - idle... *Präzise* wird das nie, weil der Versand einer einzelnen Mail je nach Auslastung des Servers und Qualität der Verbindung unterschiedlich lang dauern kann. Zudem muss eine maximale Anzahl definiert werden, sonst kann ein Benutzer ja auch 10000 eintragen...

Prinzipiell lassen sich lang laufende Prozesse z.B. per AJAX anstarten. Forken, wie etwa in Perl, geht in PHP nicht. Cronjob sehe ich kritisch, weil es passieren könnte, dass der nächste Lauf gestartet wird, obwohl der vorherige noch gar nicht beendet wurde. Bei unglücklicher Implementierung kann man damit sogar einen ganzen Webserver lahm legen.

"Statistik"

Da gibt es zwei Ausprägungen: Das reine Öffnen der Mail und das Anklicken eines Links in der Mail.

Das reine Öffnen wird bei HTML-Mails in der Regel über Grafiken gelöst. Hat der Empfänger HTML abgeschaltet, funktioniert das schon nicht mehr. Die meisten Mailprogramme und Webmailer schalten auch bei HTML-Inhalten mittlerweile das Laden von Grafiken per default ab, weil es ein Sicherheitsrisiko ist. Das heißt selbst bei aktiviertem HTML kann man nicht sicher sein, dass die Grafik geladen wird und somit das Zählen funktioniert.

Das Zählen von Links ist etwas einfacher, muß dann aber über ein Modul erfolgen. Es würde ja nicht genügen / funktionieren, dem Link auf z.B. eine Seite (<url>/pages/bla.php) irgendeinen Parameter anzuhängen, weil der nirgendwo interpretiert wird. Statt dessen müßten alle Links auf ein zentrales Modul verweisen, welches den Counter pflegt und dann auf die eigentliche Seite weiterleitet. Dazu muß das Modul die Seite kennen. Das geht entweder über eine Art GUID (a la shortlinks.de oder tinyurl.com), oder indem man den "echten" Link hinten dran hängt. Letzteres wiederum erlaubt es dem Benutzer, die Seite unter Umgehung des Zählers direkt aufzurufen.

Last edited by webbird (27.03.2017 10:27:34)

grindbatzn · 27.03.2017 10:58:16

Was mich zuerst interessieren würde:
Was soll bei der Anmeldung zum Newsletter erfasst werden?

Ich wäre ja ganz spartanisch nur für Anrede, vollständiger Name, eMail.
Anrede: Herr/Frau/keine . wobei ich mir momentan nicht vorstellen kann, wie man mit "keine" umgeht
zb bei Name "Geboti GmbH" oder "Kegelverein Fritz", oder "Suchaka Kri Bleglo" Oder "Hilfswerk Sudoref"
Schreibt man da dann (?):
Sehr geehrte(r) Geboti GmbH
Oder einfach: Hallo Kegelverein Fritz

Man könnte auch 5 zur Auswahl haben (Auswahlliste)
Sehr geehrte Frau
Sehr geehrter Herr
Sehr geehrte
Sehr geehrter
Sehr geehrtes

Der Name ist wohl am einfachen so, wie ihn die Leute angeben, Mitsamt Titel. Weil: Der Akademische Grad kann vorne stehen - oder hinten, manche wollen ihn gar nicht angeben, für andere ist das hochgestellte a das wichtigste.

eMail ist klar

Sprache: Nun, man könnte erfassen, welche Sprache bei mehrsprachigen Seiten gerade eingestellt ist. Das Anmeldeformular kann auf vielen Seiten sein, die Anmeldungen landen alle in einer Liste.

Anmerkungen: Ja, ein kleines Feldchen tut nicht weh und vielleicht will ja wer gleich spezielle Wünsche äußern.
zb "Nur Newsletter zum THema XX" - was man in der Praxis wohl nicht wirklich erfüllen kann.

Ich habe einen Kunden, der relativ oft Newsletter versendet. Der hat ein Anmeldeformular mit ca 50 Checkboxen - in der Praxis sieht jeder Newsletter für alle gleich aus. WIe soll man das auch händeln, bei den meisten würde nur mehr eine Zeile Text überbleiben.

florian · 27.03.2017 11:06:09

-entfernt-

Last edited by florian (07.04.2017 17:50:29)

grindbatzn · 27.03.2017 11:23:07

Zum Verfassen des Newsletters:
Klar würde sich einfach ein WYSIWYG Editor anbieten. Da gibt es aber einen Fallstrick:
Ich kann zwar einfache CSS-Anweisungen im Mail mitschicken, aber keinesfalls zb Google-Fonts oder sonstwas. Ich muss den Editor also so präparieren, dass er eine andere editor.css verwendet. Wie geht das?
Am stabilsten sind sowieso Inline-Styles.

Bei einem Kunden hab ich das so gelöst:
Es gibt eine Seite "Aktuell", auf der läuft Itemz. Damit kann er ganz leicht Block um Block machen: Bild, TItel, Text, Link zum Angebot.
Wenn alles fertig, kopiert er den Quellcode aus der Seite, setzt ihn als Body in sein Newsletter-Script (eine externe Sache) und ab die Post.
Die Seite Aktuell bleibt natürlich stehen - das ist eben die Webansicht des Newsletters.

Der Kunde weiß, dass das im Mail dann etwas anders aussieht, aber das ist OK für ihn. Bei manchen Kunden aber besteht da die Gefahr, dass sie ewig "herumgestalten" (Leerzeichen für harte Zeilenwechsel und sonstiger Horror) und dann entsetzt sind, wie das bei den Empfängern aussieht.

Last edited by grindbatzn (27.03.2017 11:26:56)

better-work

florian · 27.03.2017 11:42:22

Für den WYSIWYG-Editor könntest Du eine Insellösung wie http://premiumsoftware.net/cleditor/ einfügen.
Aber irgendwo anders Beitrag erstellen, Quellcode markieren und einfügen - sorry, nein, no way. Das kriege ich nicht verargumentiert, das ist zu 1997.
Eine weitere denkbare Lösung wäre,
1) Red. erstellt eine Newsletterausgabe mit Itemz oder Topics (das dann die Webansicht des Newsletters ist)
2) Red. wählt im Newslettermodul per Dropdown den Itemz/Topics-Beitrag aus, der verwendet/versendet werden soll
3) Newslettertool zieht sich das HTML und erstellt eine Vorschau, wie in etwa die Mail aussieht
4) Red. schaut noch mal drüber und kann dann entweder den Text in Itemz/Topics weiter bearbeiten oder den Versand starten

Last edited by florian (27.03.2017 11:43:16)

better-work

grindbatzn · 27.03.2017 12:20:15

Jo, eine genauere Spezifikaton bleibt uns wohl nicht erspart ;-)

Zu verschiedenen Möglichkeiten:
Es gibt immer jemanden, der dann dies oder das noch haben will. Es ist einfacher, eine vorhandenen Möglichkeit auszublenden, als sie dazu zu machen.
Ich würde ein Kommentarfeld dazumachen, wer weiß, wofür es gut ist. Ein display:none ist schnell gemacht.
Die 5 "Geschlechter" kann man ja vorsehen, aber auch weglassen. Wenn dich der erste Transgender X wegen Diskriminierung verklagen will, bist du froh, wenn du das Feld griffbereit hast. ;-)

Zum Erfassen des Inhaltes:
Es muss natürlich beide Möglichkeiten geben: WYSIWYG/HTML und section-Picker bzw TopicsPicker.
Dass mein Kunde das per QuellCode Copy/Paste macht, liegt einfach daran, dass er ein externes Newsletter-Script verwendet.
http://www.zeltstadt.at/zelte/aktuell.html

An sich ist die Variante mit Itemz aber nicht die schlechteste Wahl. Es zwingt zu strukturierten Inhalten und lässt sich halbwegs stylen - auch für Mails.
Du musst im Auge behalten: Manche Mail-Clients haben sehr veraltete Render-Engines. Du lernst Tabellen-Layouts wieder kennen.

WIe man die reine Textversion erstellt, ist mir noch unklar. Ganz automatisch (strip_tags) wird nicht gehen, schon wegen der Links, die dann sinnentleert wären ("klicken Sie hier")

Last edited by grindbatzn (27.03.2017 12:20:59)

webbird · 27.03.2017 15:08:12

Ich würde noch ergänzen

- lauffähig / getestet mit PHP 7

florian · 03.04.2017 15:32:07

https://forum.wbce.org/viewtopic.php?id=1159

webbird · 07.04.2017 17:35:41

florian wrote:

Ich habe kein Problem damit, wenn für ein Modul ein zusätzliches Framework oder eine Library installiert werden muss.
ABER: Ich habe ein Problem damit, wenn sich diese Library dann auf allen Seiten einklinkt und es dort zu Seiteneffekten kommt (LibraryAdmin / jQueryLib, sorry), und ich habe ein noch größeres Problem damit, wenn ich oder gar die Kunden vor Eingabeformularen stehen, die an Umfang und Komplexität einem Formular für die Einkommenssteuererklärung nur wenig nachstehen.

Nur damit das nicht falsch in Erinnerung bleibt: KeepInTouch v2017 braucht die wblib2 sowie jQuery, damit das BE vernünftig funktioniert. LA gibt es in BC nicht und wird auch nicht gebraucht, weil wir auch so ausreichende Möglichkeiten haben, um jQuery Plugins zu installieren und entweder zentral oder seitenbasiert einzubinden. Ein nachträgliches Verwurschteln des Seiteninhalts wie bei WB ist daher überhaupt nicht notwendig.

Die Anmerkung zur Komplexität der Formulare bezog sich hoffentlich (bzw. mit ziemlicher Sicherheit) auf das alte KeepInTouch. Ralf hat seine Software immer im Kundenauftrag erstellt und nachher kostenlos auch allen anderen zur Verfügung gestellt. Wenn die Kunden es halt so komplex haben wollten, haben sie es eben auch so bekommen. Dass das Ergebnis oft nicht DAU-tauglich war (was keine Herabsetzung sein soll), war auch Ralf bewußt. Er hat eben in erster Linie zahlende Kunden bedient - wenn andere das auch gebrauchen konnten, haben sie von professioneller Software profitiert, wenn nicht, auch gut, er wurde schließlich für seine Arbeit bezahlt.

Ich zwinge hier niemandem meine Lösungen auf, möchte aber doch sehr darum bitten, keine falschen oder total veralteten "Informationen" zu streuen. Wie KeepInTouch 2017 aussieht, ist auf der oben verlinkten Seite zu sehen. Wer interessiert ist, ist gerne eingeladen, sich dort - und NUR dort! - dazu zu äußern. Wer eine schlichtere* Lösung sucht, kann sich die von Chio ansehen und dort mitdiskutieren. Beides aber bitte auf Basis aktueller Informationen und Tests.

* Ich habe davon noch nichts gesehen und will mit "schlichter" keine Bewertung abgeben. Ich interpretiere lediglich die Diskussion so, dass das Modul im besten WB(CE)-Sinn "einfach" gehalten ist.

florian · 07.04.2017 17:51:00

Ok, akzeptiert, ich habe den Beitrag entfernt

WBCE CMS Forum

#1 26.03.2017 15:57:28

Newslettermodul

#2 26.03.2017 22:30:55

Re: Newslettermodul

#3 27.03.2017 08:09:56

Re: Newslettermodul

#4 27.03.2017 10:11:57

Re: Newslettermodul

#5 27.03.2017 10:26:57

Re: Newslettermodul

#6 27.03.2017 10:58:16

Re: Newslettermodul

#7 27.03.2017 11:06:09

Re: Newslettermodul

#8 27.03.2017 11:23:07

Re: Newslettermodul

#9 27.03.2017 11:42:22

Re: Newslettermodul

#10 27.03.2017 12:20:15

Re: Newslettermodul

#11 27.03.2017 15:08:12

Re: Newslettermodul

#12 03.04.2017 15:32:07

Re: Newslettermodul

#13 07.04.2017 17:35:41

Re: Newslettermodul

#14 07.04.2017 17:51:00

Re: Newslettermodul

Board footer