Support-Forum Mirko Böer Softwareentwicklungen

Für mich ist das Problem gelöst.
Ich musste nur auf dem Server das mod_rewrite Modul so anpassen, dass das Newsletter-Verzeichnis vom \"Umschreiben\" ausgenommen wird und somit die dort liegenden Seiten nicht von vornherein als vorhanden markiert sind.
Ursache ist eine mod_rewrite-Regel, die alle Seitenaufrufe auf die index.php umleitet.

Danke an Mirko für die schnelle und gute Lösung des Problems!

Das Problem scheint immer noch ungelöst zu sein bzw. es gibt dafür kein Fix?

Vielleicht kann man am TYPO3 irgendwas drehen, so dass er einen Fehlercode liefert und danach erst umlenkt. So wie TYPO3 das jetzt macht, existiert jede Seite, d.h. man kann hinter der Domain / eingeben was man will, gibt immer ein 200 OK.

Danke, ich werde mal sehen, was sich auf dem Server so machen lässt. Nachdem TYPO3 darauf läuft, werden alle nicht referenzierbaren Seiten auf die Startseite verwiesen und dadurch als \"vorhanden\" simuliert...

Hier ist das Problem, dass SuperMailer keinen freien Dateinamen finden kann. Er sucht für den alt. Browserlink und für das Newsletterarchiv einen freien Dateinamen. SuperMailer \"denkt\" sich einen Dateinamen aus und versucht die Datei per http:// aufzurufen. Klappt der Aufruf, wird der nächste Dateiname ausgedacht und abgetestet. Und so geht das immer weiter, hier in diesem Fall endet das einer Endlosschleife, d.h. er testet 1000te Dateinamen ab aber erhält vom Server immer wieder die Meldung \"Datei existiert\" bzw. 200 OK. Normal wäre, dass der Server 404 = Datei nicht gefunden zurückliefert und danach entweder eine Fehlerseite zeigt oder eine Umleitung auf die normale Webseite durchführt.

In der Version werde ich das ändern, d.h. er wird 50x probieren einen Dateinamen zu finden, klappt das nicht, wird einfach der zuletzt probierte Dateiname verwendet. Das ist zwar nicht schön und es könnten durch Zufall Dateien überschrieben werden aber wenn der Server nicht \"normal\" konfiguriert ist, kann man nichts machen.

Projektdatei (gezippt) mit allen eingegebenen Daten mir mal herschicken, die Empfänger aber vorher löschen.

Original von jenswi:
Hab es getestet, aber leider ohne Erfolg!
Er bleibt weiterhin hängen.

Da kann ich mich nur anschließen - gibt es inzwischen eine Lösung für dieses Problem?
Bei mir hängt sich der Supermailer beim Mailversand immer während der \"Installation des alternativen Browserlinks\" auf (nachdem \"Test des Skriptes\" abgehakt wurde).
Ein Versand ohne den alternativen Browserlink geht ohne Probleme, die Einstellungen für den Upload per FTP sind korrekt und auch die passive/aktive Ãœbertragung ist egal. Auch ein Upload per Skript habe ich ohne Erfolg getestet.
Auf einen Fehlerbericht kann ich lang warten - wenn nicht gleich ewig...

dann kannst mir nur per E-Mail die Projektdatei zum Testen schicken, möglichst jedoch ohne Empfängerdaten.

Hallo Mirko!

Hab es getestet, aber leider ohne Erfolg!
Er bleibt weiterhin hängen.

Gruß
Jens

Ja, upload per FTP. Werde das mal testen, allerdings erst morgen, da die gute Frau heute noch etwas zu arbeiten hat.

Ich meld mich wieder!

Upload per FTP? Dann mach mal unter Menü Projekt - Alternativer Browserlink die passive Ãœbertragung aus bzw. an, je nach dem ob es aktiviert oder deaktiviert ist.

Hallo!

Erstmal Danke für die schnelle Antwort, das ging echt fix!

Ich warte nun schon seit 20 Minuten, aber da kommt keine Fehlermeldung. Nach Punkt 3 \"Test des Skripts\" passiert nichts mehr!

Hallo Jens,

mindestens 4,5 Minuten warten, danach müsste ein Fehlerreport kommen, den muss ich sehen.

Hallo zusammen!

Ich habe folgendes Problem.
Einer unserer Kunden setzt SuperMailer ein.
Wenn ein Newsletter mit alternativen Browserlink verschickt werden soll, so hängt sich SuperMailer dabei auf. Es kommt keine Fehlermeldung, nichts!
Die Einstellungen wurden kontrolliert und sind korrekt, sogar eine Neuinstallation wurde schon durchgeführt - alles ohne Erfolg.
Ohne alternativen Browserlink, also mit direktem Link, funktioniert es wunderbar.

Für hilfreiche Tipps wäre ich sehr dankbar!

Gruß Jens