ich hab grad ein fieses Problem. Ich binde den Textbaustein oxagb aus der Webseite auch direkt in die Kunden-Mail ein (per oxcontent). Auf ominöse Weise verschwinden bei der Einbindung die Zeilenumbrüche (also die “echten”
) aus dem Code, so daß ich eine einzelne Zeile mit 19.000 Zeichen in der Mail habe. Der Mailserver der Herren in Magenta quitiert nun seit der letzten AGB Anpassung die Mails mit “Line too long” - nach einigen Recherchen darf eine Zeile wohl nur 16k Zeichen enthalten.
Frage: Wie schaffe ich es, dass die Einbindung mit oxcontent die Zeilenumbrüche erhält?
ich fürchte, dass die “
” unterwegs, also auf irgendeinem E-Mail-Relay verloren gehen. Da kannst Du so gut wie gar nix machen. Hast Du mal prüfen können, wie das bei Dir im Ausgang aussieht?
danke für die Antwort - definitv nein, die Mail wird schon von meinem Mailserver nicht ausgeliefert - auf der Suche bin ich aber grad über die Antwort selber gestolpert. Der im Backend verwendete FCKEditor entfernt die
s wenn man aus der HTML Ansicht speichert. Speichert man aus der Quelltextansicht, sind die
mit in der Datenbank.
Ich empfehle Dir das Modul myemail.php zu verwenden - das findest Du über Suche hier im Forum. Damit kannst Du die AGB etc. als PDF an die Bestell-Email automatisch anhängen und senden lassen. Das ist eine saubere, zeitgemässe Lösung.
PS: “
” ist doch Linefeed für php Script und der HTML-FCK-Texteditor in Oxid löscht den natürlich raus.
Du könntest aber Dein Skript mal direkt in der Datenbank ablegen, also ohne den Editor zu verwenden, dann könnte es vielleicht funktionieren - hab ich noch nicht getestet.
OH: In eigener Sache sehe ich gerade, dass ich mit 101 jetzt Senior Member bin. Doch schon so alt.
[QUOTE=Earlybird;84654]
Du könntest aber Dein Skript mal direkt in der Datenbank ablegen, also ohne den Editor zu verwenden, dann könnte es vielleicht funktionieren - hab ich noch nicht getestet.
[/QUOTE]
Wie gesagt, drückt man auf den “Quellcode” Knopf wird der Quellcode inkl. Linefeeds angezeigt - es wäre ehrlich gesagt auch meine Erwartung dass das was ich hier sehe dann so in der DB landet - lustigerweise baut der FCK Editor die Linefeeds ja beim laden aus der DB auch so wieder ein…
Ich rede hier ja nicht von Script Code - das Problem liegt am Mailsystem. Die Mail wird per ASCII Text transportiert und es gibt bei den meisten Providern ein techisch bedingtes Limit, dass eine Zeile in einer Mailübertragung nicht länger als 16.000 Zeichen sein darf.
Wenn ich nun den AGB HTML Code in die Mail reinkloppe, entsteht da eine einzige Zeile in der ASCII Darstellung die mehr als diese 16k Zeichen hat -> peng
Genau und deshalb habe ich Dich ja schon gefragt wie die Zusammenhänge sind.
Also erklär doch mal bitte wie das Programm überhaupt laufen soll: Welche Datei, was wo wie …
Naja ich denke mal der Eingangspost sagt was ich tue, aber hier gerne nochmal das Problem:
Ich pflege den Textbaustein “oxagb” über den Editor im Backend
Diesen Baustein habe ich in mail/html/order_cust.tpl per [{ oxcontent ident=oxagb }] eingebunden
Bestellt nun ein Kunde im Shop, erstell das System die Bestellbestätigung und fügt dabei den Textblock oxagb in die E-Mail ein.
Soweit so gut.
Das Problem: Wenn ich mir den QUELLTEXT der Mail anschaue, ist der gesamte AGB Text eine einzige Zeile, die in meinem Falle aus ca 18500 Zeichen besteht. Die verwendete Mail-Factory übergibt den Kram nun an meinem Mailserver, dem ist das auch noch recht egal, der versucht nun diese Mail per SMTP an T-Online zu liefern. Gemäßt dem SMTP Standard wird nun der Nachrichten Body “as is” übertragen, dabei kommt nun auch die Zeile mit dem AGB Block dran. Der SMTP Server der Gegenstelle ist nun aber der Meinung das er keine Zeilen mit mehr als 16k Zeichen haben möchte (ein Puffergrößen Problem) und lehnt die Mail ab. D.h. die einzige Chance Mails an T-Online zu liefern ist dafür zu sorgen das die Zeilenumbrüche erhalten bleiben damit die Zeilen weniger als 16k Zeichen haben.
Ich war so naiv dass ich einfach nur unter “Quelltext” in den Editor geschaut habe, wo das “gut” aussah und dann verwundert war, wieso in der Mail keine
mehr sind. Die Eingangsfrage ist also falsch, weil das Problem schon früher auftritt.
Neu Frage wäre demnach: Wie schaffe ich es, dass der Editor die Linefeeds nicht bereinigt, ohne in die Quelltextansicht zu schalten.
Schick mir bitte mal eine PM und ich ruf Dich dann zurück. So werden wir das schneller diskutieren können und anschliessend hier die Lösung abgeben. OK?
Da Du Dich nicht mehr gemeldest hast - was ich als sehr undankbar empfinde - möchte ich die Problemlösung jetzt wenigstens für die Community aufzeigen.
TUTORIAL:
Problem Zeilenumbruch
Die Lösung dazu ist trivial:
Im HTML-Teil, also der Message der Email, steht im vorgebenen Fall die AGB.
Zum Test habe ich mal 60 Seiten mit " Absatz<br /> " gemailt.
Der komplette Code sieht dann zur Veranschaulichung etwa so aus (das ist keine Oxid-Datei):
Ergebnis
Das funktioniert perfekt im Test mit 60 Seiten - warum auch nicht?
Mögliche Problem -Ursache:
Der User verwechselt - wie in der babylonischen Sprachverwirrung - php Linfeed “
” mit html " <br /> im Message-Teil und weitere Fehlermöglickeiten bieten noch Verwechslungen mit smarty, css, java etc. Nobody is perfect.
Problem FCK-Editor
Wie bereit im Thread zuvor gesagt ist dieser zwar eigenwillig aber auch narrensicher. In unserem Fall arbeitet er auch korrekt. Der User will den Zeilenumbruch mit “
” eingeben und der Fehler wird still beseitigt. Wenn man allerdings seinen eigenen Quellcode z.B. für die CMS-Seiten eingibt, kanns auch nervig werden. Ein Ausweg ist dann die direkte Code-Eingabe in die Datenbank ohne Editor.
Ich hoffe das ist verständlich und bitte um Feedback dazu.
[QUOTE=Earlybird;84652]Ich empfehle Dir das Modul myemail.php zu verwenden - das findest Du über Suche hier im Forum. Damit kannst Du die AGB etc. als PDF an die Bestell-Email automatisch anhängen und senden lassen. Das ist eine saubere, zeitgemässe Lösung.[/QUOTE]
Wenn Du die AGBs in die eMail einfügen willst, dann wäre das hier wohl die bessere Variante als stundenlang nach Zeichensatz- und Formatierungsproblemen zwischen verschiedenen Scriptsprachen zu analysieren und zu überlisten / umgehen.