V4.10.0.00874 Bug + Featurerequest

[the_scrat]

hmmm ok, verstehe. Nein, nein, in der Tabelle oder auch am Quellcode wollte ich nicht rumspielen. Ich schau halt ab und zu mal nach (soweit erkennbar) wo was stattfindet. Bzw. was die API macht. Aber könnte man mit einer direkten Import (und startmethode) nicht die Funktion der Folgeemail "faken"? Also beim Import wird sozusagen eine Zeit genommen wann offiziell die letzte Mail verschickt wurde und das ist exakt die Zeitspanne damit das gewünschte Folgeemail rausgeht? Dazu ist doch "eigentlich" nur die ID und MailingListe der FollowUpListe notwendig. Alles andere kann ja dann intern ausgelesen und berechnet werden. Die Funktionen bestehen ja bereits.

Oder soll ich deiner Meinung nach jetzt den gleichen FollowUp nochmal anlegen und in 2 Listen verteilen?

[mirko]

Muss ich dich enttäuschen, gibt es nicht. Es gibt nur die API für das Anlegen/Ändern von Nutzern, allgemeinen Einstellungen und Empfängerverwaltung. Für alles andere gibt es das nicht. Selbst drin rumbasteln würde ich auf keinen Fall in den Tabellen, denn die Follow-Up-Responder sind nicht so einfach. Grob erklärt. Es gibt eine Tabelle mit den ganzen Folge-E-Mails, die haben alle eine ID und sort_order. Das sort_order gibt immer die nächste E-Mails an, weil man die E-Mails umsortieren kann. Dann gibt es für jeden Follow-Up-Responder eine Referenz-Tabelle dort steht der Empfänger drin, die nächste ID (sort_order ist das) und wann die letzte E-Mail versendet worden ist. Anhand der nächsten ID und Versanddatum der letzten E-Mail wird berechnet wann die nächste fällig ist. Das Umsetzen der ID wird ebenfalls in dieser Tabelle gemacht.

[the_scrat]

Hallo Mirko,

gibt es aktuell die Möglichkeit ein Mitglied über die API in einer FollowUp-Liste an einer bestimmten Position starten zu lassen? Dass es technisch geht, weiß ich, da der SWM ja eine neue Folge-E-Mail zuweisen kann. Aber wäre sowas auch als API Zugriff denkbar?
Eigentlich müsste man nur einen weiteren Parameter (optional) bei api_createRecipient/api_editRecipient in der $apiData angeben und zwar die Position (ID) der FollowUp-Nachricht.

Ich hab nämlich folgendes Problem. Wie du ja bereits weißt habe ich eine Liste mit über 1000 Inhalten. Nun möchte die Geschäftsleitung, dass ein Kunde auch nur einen Teil davon "kaufen kann". Die Inhalte sind jedoch exakt gleich. Die große Liste bleibt aber nach wie vor bestehen. Doch ich würde natürlich gerne die Originale Liste recyclen und ein Mitglied in den großen FollowUp packen, an einer bestimmten Position beginnen lassen und nach x Tagen kann ich ihn ja per API wieder von der Liste entfernen (oder auch nicht).

Leider hab ich noch nicht rausfinden können wie du das mit den Folge E-Mails gelöst hast. Aber eigentlich fehlt für solch eine Funktion doch nur der Parameter "ID" der Mail an der begonnen werden soll. Alles andere muss ja eh bereits angegeben werden, wie Userdaten und MailingListID.

Diese Funktion wäre sogar recht dringend. Und nochmal über 1000 Tabellen in der DB wäre eigentlich quatsch, weil die Inhalte ja wirklich die gleichen sind. Vorallem hätte man damit wirklich tolle Möglichkeiten einen "Komplettkurs" anzubieten und einzelne "Lektionen" zugänglich zu machen ohne separate FollowUp-Listen anzulegen.

[the_scrat]

Das ist schon klar, wenn das System gerade anderweitig beschäftigt ist, steht der Versand in der regulären Warteschlange an. Es geht auch nicht um einige Minuten hin oder her, aber beim derzeitigen Stand verschiebt sich die Zeit ins unendliche nach vorne.

[mirko]

So eine Zeitangabe kann aber immer nur ein Richtwert sein, denn werden gerade nebenbei noch 1000te Newsletter versendet, dann wird diese Zeit niemals eingehalten. Genauso ist es mit mehreren Folge-E-Mails, wenn 1000te um 6 Uhr versendet werden sollen, dann bekommt nur ein Teil der Empfänger die E-Mails 6 Uhr, die anderen vielleicht erst 06:30 Uhr, wenn die E-Mail groß ist.

[the_scrat]

Ich hab doch oben einen Grund geschrieben, welcher eine solche Bedinung erforderlich macht. Es mag sein, dass es Lisschen Müller nicht nutzt, mit einem FollowUp von 2 Mails und 4 Kunden. Aber wie oben bereits geschrieben haben wir einen FollowUp mit 1080 E-Mails und bereits über 100 Kunden (die dafür zahlen! und gerne den Wunsch hätten die Mail zu einer bestimmten Zeit zu erhalten).

Es ist also kein Wunsch von mir, sondern ein mehrfacher Kundenwunsch (derzeit von über 30 Kunden). Bisher stellen wir halt manuell das letzte Versanddatum zurück, doch wie oben beschrieben, kommen da täglich einige Minuten dazu, weil der SuperWebMailer ja nicht die Datetime zurückschreibt wann er das erste mal auf den Datensatz zugegriffen hat, sondern wann er tatsächlich mit dem Versand durch ist. Und dazwischen vergehen cronjobbedingt einige Minuten (selektieren +1Min, versand, +1 Min PRO TAG!).

[mirko]

Sicher kann man das einbauen, halt noch eine Bedingung mehr, bevor der Versand der jeweiligen E-Mail beginnen soll. Ob man das wirklich braucht, ist eine andere Frage....

[the_scrat]

Hi Mirko,

ich hätte noch einen Featurerequest. Es geht um den Versandzeitpunkt des FollowUp. Wie du ja schon weißt haben wir einen FollowUp mit über 1000 E-Mails. Einige unserer Kunden möchten die E-Mail zu einem bestimmten Zeitpunkt haben (z.B. 6 Uhr morgends). Das ist ja auch kein Thema. Das lässt sich ja über den Versandzeitpunkt einstellen. Leider verschiebt sich die Zeit mit der Anzahl der Mails immer weiter nach vorne. So sind bei vielen unserer Kunden bereits nach ca. 50 E-Mails der Verandzeitpunkt nicht mehr 6 Uhr, sondern 6:22 Uhr. Aber ich kann ja jetzt auch nicht alle Tage das Datum bei ettlichen Kunden ändern, damit die ihre Mails pünktlich bekommen. Klar dauert der Versand auch seine Zeit, aber wenn beim "letzten Versand" immer die Zeit zurückgeschrieben wird, wann das System tatsächlich verschickt hat, dann addiert sich das ja irgendwann auf, dass es nicht mehr passt.

Das ganze wird sicherlich auch dadurch begünstigt, weil das System ja (in meinem Fall jede Minute) erstmal die "fälligen Empfänger" selektiert und erst im 2. Schritt tatsächlich verschickt.

Ich weiß ja, dass du Optionen nicht magst, aber vielleicht könntest du im FollowUp bei Aktionen eine weitere Option einbauen in der man eine fixe Zeit eingibt (nicht Datum), wann das System probieren soll den Empfänger anzuschreiben. Hat keine Prio, wäre nur schön, wenn das irgendwie machbar wäre

[the_scrat]

Naja, zumindest ein Teilerfolg
Du könntest doch zumindest abfragen ob es einen Wert für die Liste in der userdefined.inc.php gibt, wenn nicht, nimm 50.

Mir ist schon klar, dass eine extrem hohe Zahl nicht nur den Browser von der Performance nach unten drückt, sondern auch die Datenbank. Aber wenn irgendwo 200-300 Teilnehmer drin sind, sollte das jeder anständige Browser schaffen

Andererseits frage ich mich weiterhin warum für jede Nachricht eigene Tabellen angelegt werden. Das killt nämlich meinen Browser wirklich. Ich hab einen FollowUp mit über 1000 E-Mails. In der Datenbank sind alleine wegen einem Followup schonmal 7000 Tabellen belegt. Dann noch 2-3 andere.... siehe angehängte Grafik. Alleine das Laden der Seite brauchte ca. 3 min. bis phpmyadmin einfach nur die unteste Zeile dargestellt hat.

Naja Ich finds jedenfalls super, dass du das System etwas flexibler machst. Auch wenn die Testmail-Funktion keine "Nochmal-Schick" Funktion ist, kann man sie ja trotzdem dazu gebrauchen.

[mirko]

Ich habe deinen Text schon gelesen, keine Angst! Das Entfernen der Angabe [TEST] war ja auch nur ein Tipp für dich, weil du immer so ungeduldig bist.
Zumindest ab der nächsten Version kann man das [TEST] in der userdefined.inc.php ausschalten, wenn man das will, bisher wollte das aber keiner, mal von Dir abgesehen. Bei der Limit-Angabe auf 50 bleibt so wie diese jetzt ist, es ist eine Test-Mail-Funktion und keine "Nochmal-Schick" Funktion. Du kannst natürlich die Zahl selbst erhöhen aber gibst du dort 50000000 an und du hast auch so viele Empfänger, dann wird wohl der Browser bei der Datenmenge nicht mehr mitspielen wollen.

[the_scrat]

Hi Mirko,

das ist mir schon klar wie ich das Test wegbekomme. Ich hab manchmal so das Gefühl, dass du dir den Text den ich schreibe nicht richtig durchliest. Es geht hier nicht um sonderwünsche sondern um reguläre Anpassungen, wie es in manchen Unternehmen nunmal notwendig sind. Natürlich könnte und kann ich den String [TEST] einfach rauslöschen. Dieser ist nunmal fix in der Datei. Aber sowas ist doch quatsch.

Daher mein Vorschlag, leg dir doch mal eine Datei an mit solchen Variablen und Strings. Das sind dann die Standardwerte, die DU definierst und wahrscheinlich 98% der Benutzer zufriedenstellt. Wenn aber Leute, so wie ich einfach andere Werte brauchen um uns das Leben zu erleichtern, brauchen wir nicht unnötig im Quelltext danach suchen, sondern überschreiben diesen Wert einfach in einer Zentralen Datei. Für diese Datei ist jeder selbst verantwortlich. Verstehst du was ich meine?
Es geht hier um Wiederverwendbarkeit, ich versteh nicht, warum du deinen Kunden nicht mehr Entscheidungsfreiheit geben möchtest. Wenn ich der Meinung bin der Wert von von 50 auf 50000000 geändert werden, muss das mein System packen und nicht deins. Dein Standard ist 50. Meiner eben nicht

Und ob du jetzt im Quelltext schreibst

Code: Alles auswählen

  if( isset($_GET["TestMail"]) ) {
     $_f1OJf = 50;
  }

oder

Code: Alles auswählen

  if( isset($_GET["TestMail"]) ) {
     $_f1OJf = $GLOBALS['TestMailSelectList'];
  }

Denn so muss ich bei jedem Update ständig zig Dateien manuell ändern, weil es keine zentrale Wertanpassungsmöglichkeit (wow, was für ein Wort) gibt!

[mirko]

Du immer mit deinen Extra-Wünschen. Viele wollten das TEST davor unbedingt haben, damit man zwischen Test-E-Mail und der späteren richtigen E-Mail unterscheiden kann. Sind keine Tracking-Links in der E-Mail, dann kann man später nicht mehr zwischen Test-E-Mail und richtige E-Mail unterscheiden. In der responderpreview.php suchst nach "[TEST] ". und löschst es raus, dann wird es nicht mehr eingefügt.

[the_scrat]

Hi Mirko,

das mit dem der Funktion api_removeRecipient ist soweit nachvollziehbar. Man geht einfach davon aus, dass da was zurückkommt, bzw. bin ich....Ich hab zwar schon im Quelltext etwas gelesen, aber so ein gecrypteter Quelltext macht halt auch keinen Spaß

Das mit api_Recipients.api_activateOrdeactivateRecipient ist wirklich super, das hilft mir extrem weiter.

Die Thematik mit der Folge E-Mail ist mir bekannt. Allerdings gibt es manche Leute die gleich 10-20 E-Mails neu zugeschickt bekommen wollen, weil sie halt die letzten Wochen vergessen haben ihr Postfach zu leeren und somit nix mehr ankommt. Wenn ich über den Weg der Folge E-Mail gehe, werd ich ja wahnsinnig Sinn der Folgeemail sollte doch sein, dass man einen User an eine andere Position innerhalb der Reihenfolge setzt.

Ich nutze bisher immer den Testversand, der ist einfach und unkompliziert. So klicke ich mich von Followup Nachricht zu Nachricht und wähle nur Empfänger und Adresse aus.
Es wäre eben nur schön, wenn man die Anzahl der Empfänger in der Liste updatesicher speichern kann sowie den Prefix [TEST] entfernt. Dann kann ich den Testversand damit "missbrauchen". Standardmäßig kann der Wert ja weiterhin 50 sein und der Prefix in jeder full bzw. Updateversion auf [TEST] stehen, doch für individuelle Werte, wäre eine Datei recht mit eigenen dateien, die zum Schluss eingelesen wird und ggf. standardwerte überschreibt. Globale Variablen eben. $GLOBALS[testmailprefix] = ''; $GLOBALS['testmailcount']=100;
In der Funktion frägst du nur die $GLOBALS ab, entweder es steht der Standardwert drin, oder eben ein indiviueller. Einen Mehraufwand hast du damit nicht, es erleichtert dir sogar die Arbeit, weil du alle Werte an einer Stelle definieren kannst und nicht erst in der Datei

[mirko]

Hallo Mirko,

habe heute das Update installiert, läuft soweit alles wunderbar.
Erstmal auch vielen Dank, dass du die ganzen "Sonderwünsche" umgesetzt hast. Erleichtert mir wirklich sehr die Arbeit und ich hoffe mal auch vielen anderen.

Ich hab allerdings einen kleinen Fehler gefunden in der aktuellen Version (könnte auch sein, dass der schon länger dort ist)

• Bug:
• E-Mailings anzeigen -> Filter -> Sortiere Liste nach Hier wird die Ausgabe genau in die falsche Richtung sortiert.

Ja das stimmt, ist im Quelltext der HTML-Seite falsch bezeichnet.

[*] API Bug: Beim hinzufügen per API erhalte ich als Result die ID des neuen Benutzers und kann zusätzlich über $client->fault abfragen ob ein Fehler aufgetreten ist, beim Löschen (api_Recipients.api_removeRecipient) hingegen erhalte ich IMMER als Rückgabewert "1" und $client->fault ist immer false (somit "kein Fehler"). Das passiert auch, wenn der User garnicht in der Liste existent ist in der Liste aus der ich ihn entfernen möchte, was meiner logischen Meinung nach ein $client->fault = true! sein müsste. [/list]

Vielleicht nicht logisch aber es wird keine Prüfung gemacht, ob der bzw. die Empfänger gelöscht worden sind. Der Funktion api_removeRecipient übergibt man mehrere IDs zum Löschen (übergibt man nur eine ID, wird automatisch ein array daraus gemacht), es wird dabei immer TRUE zurückgegeben, außer es traten SQL-Fehler auf, dann FALSE. Die api_removeRecipient ruft eine meiner internen Funktionen auf, meine Funktion speichert nicht für jede übergebene ID die Löschaktion, das spart Speicher und ausgeben kann man bei 100ten IDs den Status sowieso nicht, das macht keinen Sinn. Es gibt noch mehr Funktionen bei denen der Status nur mit true oder false zurückgegeben wird z.B. api_removeRecipientsFromGroups, api_resetBounceStateOfRecipient oder api_activateOrdeactivateRecipient. Wenn du bei den Funktionen wissen willst, ob etwas passiert ist, dann musst du vorher mit api_getRecipient den Empfänger dir holen und nach Ausführung der jeweiligen Aktion nochmals die Daten holen und vergleichen. Ist aber eigentlich nicht notwendig, das wird immer durchgeführt, falls das notwendig ist.

• Features:
• Ist es eigentlich möglich auf das "aktivieren/deaktivieren" Feld per API zuzugreifen?

Ja mit api_Recipients.api_activateOrdeactivateRecipient.

[*] Wäre es möglich im Versandprotokoll für * noch einen Filter einzubauen? Manchmal muss man nachvollziehen ob eine bestimmte Adresse auch wirklich alles bekommen hat, oder ob es da einen Fehler gab.

Dort willst auch noch suchen, ich schreibe es mir mal auf.

[*] Immer wieder behaupten Leute, dass sie z.B. bei einem Followup nur einen Teil der Mails erhalten haben. Also muss man ihnen diese Mails "nachschicken". Die Folge E-Mail neu einzustellen macht keinen Sinn, da ja dann die komplette Zeit abgewartet werden muss. Ich nutze bisher immer die "Test E-Mail" funktion, allerdings mit dem Nachteil, dass im Betreff [TEST] steht. Wär es möglich den Prefix [TEST] irgendwo in die config auszulagern, damit man ihn recht leicht streichen kann? Bisher öffne ich immer die Datei und lösch ihn von Hand raus. Ebenso wäre es super, wenn der Wert der E-Mailadressen im Testversand (bisher 50) irgendwo leicht angepasst werden kann (am besten Updatesicher).[/list]

Neben dem Follow-Up-Responder auf das letzte Symbol zur Anzeige der nächsten Folge-E-Mail für die Empfänger klicken. Dort musst den Empfänger raussuchen und ihm die Folge-E-Mail zuweisen. Der bekommt dann die E-Mail nochmals und danach die folgende E-Mail usw..

[the_scrat]

Hallo Mirko,

habe heute das Update installiert, läuft soweit alles wunderbar.
Erstmal auch vielen Dank, dass du die ganzen "Sonderwünsche" umgesetzt hast. Erleichtert mir wirklich sehr die Arbeit und ich hoffe mal auch vielen anderen.

Ich hab allerdings einen kleinen Fehler gefunden in der aktuellen Version (könnte auch sein, dass der schon länger dort ist)

• Bug:
• E-Mailings anzeigen -> Filter -> Sortiere Liste nach Hier wird die Ausgabe genau in die falsche Richtung sortiert.
• API Bug: Beim hinzufügen per API erhalte ich als Result die ID des neuen Benutzers und kann zusätzlich über $client->fault abfragen ob ein Fehler aufgetreten ist, beim Löschen (api_Recipients.api_removeRecipient) hingegen erhalte ich IMMER als Rückgabewert "1" und $client->fault ist immer false (somit "kein Fehler"). Das passiert auch, wenn der User garnicht in der Liste existent ist in der Liste aus der ich ihn entfernen möchte, was meiner logischen Meinung nach ein $client->fault = true! sein müsste.

• Features:
• Ist es eigentlich möglich auf das "aktivieren/deaktivieren" Feld per API zuzugreifen?
• Wäre es möglich im Versandprotokoll für * noch einen Filter einzubauen? Manchmal muss man nachvollziehen ob eine bestimmte Adresse auch wirklich alles bekommen hat, oder ob es da einen Fehler gab.
• Immer wieder behaupten Leute, dass sie z.B. bei einem Followup nur einen Teil der Mails erhalten haben. Also muss man ihnen diese Mails "nachschicken". Die Folge E-Mail neu einzustellen macht keinen Sinn, da ja dann die komplette Zeit abgewartet werden muss. Ich nutze bisher immer die "Test E-Mail" funktion, allerdings mit dem Nachteil, dass im Betreff [TEST] steht. Wär es möglich den Prefix [TEST] irgendwo in die config auszulagern, damit man ihn recht leicht streichen kann? Bisher öffne ich immer die Datei und lösch ihn von Hand raus. Ebenso wäre es super, wenn der Wert der E-Mailadressen im Testversand (bisher 50) irgendwo leicht angepasst werden kann (am besten Updatesicher).

Mehr fällt mir im Moment nicht ein, könnte aber sein, dass ich die Liste noch etwas erweitere