@dasoe
danke für Deine Hinweise. Ich bin mir aber fast sicher, dass ich alle Diese (außer den Cache per FTP zu löschen) schon x mal umgesetzt habe. :-(
Das mit der doppelt vorhandenen direct-Mail Variante kann zwar sein, denn ich selbst habe eine Form dieser Extension (df-dmailer) erstellt. Aber außer hinzugefügte Datenfelder und eigene XCLASSes, wird kein Einfluss auf andere Module genommen und nach entfernen sollte es damit sowieso keine Probleme oder Konflikte geben, zumal der Fehler anscheinend durch "plugin_mgm" selbst verursacht wird.
Auch wenn alle anderen nicht relevanten Extension deinstalliert sind, dann ist der Fehler trotzdem nicht weg. Das plugin_mgm selbst habe ich auch schon mehrfach vom Server gelöscht und ganz neu installiert.
Dem steht entgegen, dass der Fehler aber überhaupt erst nach dem Update auf direct-mail 1.1.0 auftauchte aber - egal was man anstellt - leider nicht mehr verschwindet. Selbst nicht, wenn diese Ext. komplett vom Server gelöscht worden ist!
Was mit im nachhinein einfällt. Im Extension Info der 1.1.0 steht unten ein Fehler🙁Errors: Some tables or fields are missing and of wrong type!) und nach dem update lassen sich einige DB-Felder nicht aktualisieren, werden jedesmal bei einem "Compare" angemeckert. Noch ein Grund, für das downgrade auf die 1.0.8.
Ich kann das ganze überhaupt nicht nachvollziehen. Dieser Fehler ist hier und auch im typo3.org Forum mehrfach dargestellt. Eine Lösung ist aber nirgends zu finden.
D.
Ich habe hier die Lösung! (Danke an den Support von Mittwaldmedien)
Anscheinend ist es ein Bug...
Folgendes wurde geändert, jetzt scheint es zu gehen:
// Diese Zeile auskommentiert
//$res = $GLOBALS[\'TYPO3_DB\']->exec_SELECTquery(\'*\', \'pages\', \'doktype!=255 AND module IN (\\\'\'.implode(\'\\\',\\\'\',$name).\'\\\') AND\'.$perms_clause.t3lib_BEfunc::deleteClause(\'pages\'));
// Dafür das hier rein:
$res = $GLOBALS[\'TYPO3_DB\']->exec_SELECTquery(\'*\', \'pages\', \'doktype!=255 AND module IN (\\\'\'.$name.\'\\\') AND\'.$perms_clause.t3lib_BEfunc::deleteClause(\'pages\'));
Das implode() ist überflüssig, da der String in $name schon eine kommaseparierte Liste ist...
Aus irgendeinem Grund ging der SOurce aber nicht davon aus...
Hat schon jemand positive Erfahrungen mit dem Dircet Mail Update auf 1.1.0 gemacht??
Danke es klappt:
... module IN (\''.$name.'\') AND ...
Hi!
Könnt mir vielleicht erklären, warum mein Direct_Mail nur ca. 10% der gedachten Mails versendet ???
Es macht sogar den Anschein, als ob insgesamt nur 5 Mails pro Zyklus rausgehen. Beim ersten Mal ist dann halt noch die Admin-Mail dabei.
Der Cronjob macht seine Dienste super (minütlich, das selbe bei einer längeren Zeitspanne (2 oder 3 Minuten)) grast er die Mails ab und macht bei meiner Testgruppe (162 Empfänger - alle ich) mit jedem Zyklus 50 Mails weg (so steht's zumindest im Log im Backend).
Ankommen tun nun nur ca. 10%, also pro Zyklus 5 Mails.
Woran kann das liegen?
Liegt das vielleicht an postfix? Kann man dort die Einstellung vornehmen, dass mehr Mails parallel verschickt werden? und wenn ja, wie mach ich das?
Wenn das Script zu schnell arbeitet, dann kann ich auch ohne Probleme zwischen jedem Aufruf eine kleine Pause (1 Sekunde sollte reichen) setzen, dann haben die nächsten 5 Mails einen anderen Zeitstempel. Blos wo muss ich diese Einstellung vornehmen? In der Funktion runcron() in t3lib_dmailer sehe ich keine Schleife ...
OK. Das habe ich dann eben getestet (Pause zwischen dem Versand). Funktioniert nicht. Mist.
Grüße und Danke
McGregor
Hi!
Ich habe das Problem gelöst.
Die Firewall war hauptsächlich Schuld. Sie konnte die Menge an Mails nicht verkraften, die ich versendet habe.
Deswegen habe ich ein sleep(1) zwischen jedem Mailversand eingebaut.
Bei meinen 2000 Adressen ist das kein Problem.
Die Stelle ist im class.t3lib_dmailer.php
in der Funktion
function dmailer_masssend_list($query_info,$mid,$handle=NULL)
if ($table=='PLAINLIST') {
$sendIdsArr=explode(',',$sendIds);
reset($listArr);
while(list($kval,$recipRow)=each($listArr)) {
$kval++;
if (!in_array($kval,$sendIdsArr)) {
if ($c>=$this->sendPerCycle) {$returnVal = false; break;}
$recipRow['uid']=$kval;
$this->shipOfMail($mid,$recipRow,$tKey);
sleep(1); // HIER SCHLAFEN !!!
$ct++;
$c++;
}
}
} else {
$idList = implode(',',$listArr);
if ($idList) {
$res = // lange DB-Abfrage
if ($GLOBALS['TYPO3_DB']->sql_error()) {die $GLOBALS['TYPO3_DB']->sql_error());}
while($recipRow = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)) {
if ($c>=$this->sendPerCycle) {$returnVal = false; break;}
$this->shipOfMail($mid,$recipRow,$tKey);
sleep(1); // HIER SCHLAFEN !!!
$ct++;
$c++;
}
}
}
Ich hoffe, dass hilft jemanden weiter...
Grüße
McGregor
NACHTRAG:
Natürlich habe ich meinen Cron-Job so angepasst, dass der Versand sich dadurch nicht überschneidet, d.h. alle 3 Minuten wird der Cronjob angestossen und bei 50 Mails a 1 Sekunde bleibt genügend Zeit bei Verzögerungen beim Versand...
Hallo,
wenn die Menge an Mails schuld daran ist, warum hast Du denn nicht die Variable "sendPerCycle" verkleinert? Demnach wird doch eh ein Stopp gesetzt.
D.
Hallo dfluess,
bei mir funktioniert versand von mails immer noch nicht 🙁
Übrigens, ich finde diese Zeile bei mir gar nicht! Wo sind sie?
Die Version 1.1.0 habe ich ändlich installiert, bringt aber nix 🙁
HILFE!
dfluess schrieb
// Diese Zeile auskommentiert
//$res = $GLOBALS[\'TYPO3_DB\']->exec_SELECTquery(\'*\', \'pages\', \'doktype!=255 AND module IN (\\\'\'.implode(\'\\\',\\\'\',$name).\'\\\') AND\'.$perms_clause.t3lib_BEfunc::deleteClause(\'pages\'));
// Dafür das hier rein:
$res = $GLOBALS[\'TYPO3_DB\']->exec_SELECTquery(\'*\', \'pages\', \'doktype!=255 AND module IN (\\\'\'.$name.\'\\\') AND\'.$perms_clause.t3lib_BEfunc::deleteClause(\'pages\'));
dfluess schrieb
Anscheinend ist es ein Bug...
Folgendes wurde geändert, jetzt scheint es zu gehen:
// Diese Zeile auskommentiert
//$res = $GLOBALS[\'TYPO3_DB\']->exec_SELECTquery(\'*\', \'pages\', \'doktype!=255 AND module IN (\\\'\'.implode(\'\\\',\\\'\',$name).\'\\\') AND\'.$perms_clause.t3lib_BEfunc::deleteClause(\'pages\'));
// Dafür das hier rein:
$res = $GLOBALS[\'TYPO3_DB\']->exec_SELECTquery(\'*\', \'pages\', \'doktype!=255 AND module IN (\\\'\'.$name.\'\\\') AND\'.$perms_clause.t3lib_BEfunc::deleteClause(\'pages\'));
Hallo dfluess,
da ich auch das Problem hab, dass Massenmails zwar als versendet gelisted werden, aber beim Empfänger nie ankommen, würd mich dringend interessieren wo genau ich die oben angeführte Ersetzung vornehmen soll.
Ganz herzlichen dank im voraus.
Christine
Hallo,
also diese Modifizierung behebt aber kein Sendeproblem; unterdrückt nur eine Fehlerausgabe im BE.
Nur wenn Du einen Fehler in dieser Form hast:
//
Warning: implode(): Bad arguments. in /typo3_src-3.8.1/t3lib/class.t3lib_befunc.php on line 3177
Es wird nur eine Liste aller Pages angezeigt. Das Modul ist so nicht verfügbar.
//
Und/Oder
//
Warning: implode(): Bad arguments. in /typo3_src-3.8.1/t3lib/class.t3lib_befunc.php on line 3177
Warning: Cannot modify header information - headers already sent by (output started at /typo3_src-3.8.1/t3lib/class.t3lib_befunc.php:3177) in /typo3_src-3.8.1/typo3/ext/direct_mail/mod/class.mod_web_dmail.php on line 1320
//
Dann könntest Du den Code ändern. Das verhindert den Fehler im BE. Die Newsletter werden trotzdem versendet!
Die Newsletter, die Du versendest, sind das Test-Newsletter an Dein Postfach oder Newsletter an verschiedene Empfänger?
D.
Wo ist die codezeile versteckt die das Problem von 1.0.0 löst?