Tomorrow Comes Today

Direct Mail (direct_mail) funktioniert beim Newsletterversand bekanntlich etwas speziell. So ist es üblich einen Newsletter zu erstellen und einzelne Inhaltelemente verschiedenen Newsletterkategorien (dmail_category) zuzuordnen. Durch dieses Prinzip ist es möglich, beispielsweise einen monatlichen Newsletter an alle Abonnenten zu versenden und trotzdem die Inhalte auf die jeweiligen Empfänger zuzuschneiden. So weit so gut.

Nutzt man nun diese Herangehensweise für den Newsletterversand und erstellt trotzdem sehr spezifische Newsletter für nur eine oder einige wenige Abonnenten, kann es vorkommen, dass einige Personen diesen Newsletter gar nicht erhalten. Und das ist auch richtig so, weil diese ja sonst eine leere E-Mail erhalten würden.

Problematisch ist jedoch der Algorithmus zum Versand in dem Modul „mod/class.dmailer.php“. Hier wird immer eine bestimmte Anzahl an E-Mails auf einmal verarbeitet (in den Standardeinstellungen 50), bevor der Versand fortgesetzt wird. Als Offset für diese 50 E-Mails wird die letzte E-Mail aus dem Maillog verwendet. D. h. der Versand wird immer beim ersten Empfänger nach der zuletzt versandten E-Mail wieder begonnen.

Bei der Iteration durch die 50 Empfänger werden jedoch alle Einträge hochgezählt. Sind nun alle Newsletter der 50 Empfänger ab dem gegebenen Offset leer, stoppt der Versand und beginnt wieder an der gleichen Stelle. D. h. er wird nie fortgeführt.

Hier ist der folgende Bugfix nötig. In der Funktion „dmailer_masssend_list($query_info,$mid)“ muss in der While-Schleife „while($recipRow = $TYPO3_DB->sql_fetch_assoc($res))“ das Hochzählen von „$c“ und „$ct“ mit einer Kondition versehen werden.

if($myRC){

$ct++;

$c++;

}

So wird das 50er Intervall nur erreicht, wenn tatsächlich 50 E-Mails versandt wurden.

Dieser Bug hat mich und Oliver einge Stunden intensives Debugging gekostet, aber gut - jetzt funktioniert alles.

Man muss sich ja doch immer ein wenig mehr Zeit für die Benutzerregistrierung über “sr_feuser_register” einplanen. Mal abgesehen davon, dass durch die fülle an Funktionalitäten die Konfiguration recht zeitintensiv ist, stößt man auch immer wieder auf kleinere Fehler oder Ungenauigkeiten.

In der aktuellen Version ist beispielsweise das HTML-Template nicht ganz korrekt. Die Folge ist, dass eingeloggte Benutzer beim Bearbeiten Ihrer Daten ein leeres Formular erhalten.
Ursache hierfür ist eine falsche Angabe des id-Attributs. Hier steht id=”tx-srfeuserregister-pi1-###FORM_NAME###”. Wichtig ist, dass hier der exakte String steht, damit die PI-Vars von der Extension ausgelesen werden können. Die Extension ersetzt den Marker allerdings schon durch den voll qualifizierten Identifier. Folglich wird ein zu langer String ausgegeben und die Extension versteht sich selbst nicht mehr.

Die Lösung hierfür stammt aus einer Mailingliste.

In einem der vielen Ordner mit HTML- und CSS-Spielereien lagen noch dynamische 3D Button rum, die ich gerade wiederentdeckt habe. Dabei arbeite ich mit verschiedenen PND Grafiken, um die Button-Grafiken mit Schatten über einen beliebigen Hintergrund zu legen und zudem ein Icon ebenfalls mit Schatten auf dem Button selbst zu plazieren. Wunderschön.

Das Problem machte hier immer der IE6, der nur mit grausamen JavaScript Hacks dazu zu bewegen war, die Transparenz der PNGs auch anzuzeigen. Der IE7 kann das nun, und man könnte meinen, dass diese tollen Buttons evtl. einsetzbar werden könnten.

Nur leider bauen diese noch auf einer HTML-Tabelle auf und die sind ja bekanntlich nicht dafür gedacht. Eine Alternative wären :before und :after Angaben, aber nein - die kann wiedermal der IE7 nicht!

Eigentlich ist das ein typischer Wiki-Eintrag, aber unser JBoss Wiki braucht noch eine Weile, bis es von der Entwicklungsinstallation in den Produktivbetrieb geht.

Bei mehreren TYPO3 Projekten tauchte beim Einrichten der Redaktionszugänge das Problem auf, dass ein Admin Dateien bearbeiten und löschen kann, ein Redakteur jedoch nicht. Warum?
“Die Lösung für das Problem […] ist mal wieder denkbar einfach. Der vom DAM angelegte Media-Ordner muss bei den Nutzern oder Gruppen als DB-Mount eingetragen sein. Dann geht auch das Bearbeiten und Löschen von Dateien […].”

Vielen Dank an setsuko für den Post auf dem TYPO3forum.