Newsletter: Diesmal die komplette Erklärung -- winsel jammer

[Jensensen]

hallo marcus, hallo jürgen,

damit habt ihr womöglich recht, allerdings werdet ihr mir zustimmen, dass nach einem bloßen überfliegen in den seltensten fällen eine lösung zu finden ist und auch, dass man bei anwendung dieser methode, insbesondere im falle von phpwcms, nicht besonders weit kommen wird.

nun ja, gelegentlich versuche ich damit die besondere dramatik des problems zu unterstreichen. hier liegt sie in einer zunehmenden verzweiflung begründet.

es ist somit allen aufmerksamen lesern auch klar, dass obige hilfestellungen bislang eben nicht ausreichend sind.
[übrigens interessiert mich nicht, dass andere user offenbar mit einem halbherzigen, unausgereiften, schlampigen verfahren gut klar kommen, sich wegen der kompliziertheit des verfahrens geschlagen geben und ihren abonnenten nur einen einzigen newsletter anbieten oder sich ggf. damit abfinden, in der korrespondenz mit ihren interessenten einen haufen kauderwelsch bei der anmeldung zu versenden.]


in erinnerung an die ausgangsfrage
(dieser thread, angedacht für doofe wie mich und mit einer mutmaßlich verbesserten such-finden-convenience, ist längst wieder gescheitert)

und
da ich mit dieser und vielen anderen in einer didaktisch nicht nachvollziehbaren programmierersprache gefassten anleitungen im WIKI nichts anfangen kann

Theoretisch sollten solche Anpassungen doch über eine PHP Funktion, die im Formular CP registriert werden kann, benutzerdefiniert abgefangen werden?!
http://www.phpwcms-howto.de/wiki/doku.p ... ]=formular

...

frage ich noch einmal erneut nach:
wie viele eigentlich noch und welche extra-scripte sowie templates werden also demnach wann und wo benötigt, um eine SCH-EISS SIMPLE newsletteranmeldung in der Form
Hallo Bums Maus,
willkommen, Sie haben folgende Newsletter bestellt:
BLAH_1
BLAH_n

realisieren zu können?

Übrigens: ich schreibe hier ausdrücklich und gleichsam provokativ Hallo {vorname} Bums {nachname} Maus. Denn die [zudem aufwendige] Erfassung dieser Variablen ist [auch noch vollkommen] obsolet, da es beim späteren Versand der Newsletter überhaupt nicht möglich ist, Interessenten in personalisierter Weise anzusprechen.

Ich kürze ab:
phpwcms Newsletter ist - trotz unzumutbaren und unzulänglichen Aufwands mit script-template-geraffel - nicht markttauglich, nicht kompetitiv - in jedwede Richtung.
Aus der [sensiblen] Perspektive des Empfängers bedeutet das [überspitzt]: "Ja guck, da kommt wieder einmal der verkrüppelte Newsletter von phpwcms - Die kennen mich noch nicht einmal beim Namen"...

klar ist auch, dass ihr nix dafür könnt, dass es so knifflig ist. darum nochmals danke für die hinweise.
btw. ich schreibe wie ich bin, kühl, mit heißem herz für die sache. ausserdem bin ich musiker. emotionen "abschalten" fällt mir insofern schwer.

[flip-flop]

Vielleicht hilft das ein wenig bezüglich der Anrede:



Mit einem Script ist in diesem speziellen Fall nicht viel zu machen, da das Feld Newsletter separat behandelt wird.

Knut

[markus s]

was ich da nicht verstehe,
warum nicht den CP newsletter verwenden ?
was spricht dagegen ?
was man braucht ist der CP, dann eine vorlage in der template datei.
wenn man will ein bildchen dazu und schwupp alles
läuft.
auch mit abo kanälen !
mit an und abmeldung etc...

wo ist hier das problem ?
ich frage nur nach name und der emailadresse ab.
das ganze hr/frau gedöns habe ich mir gespart...

[flip-flop]

Das geht natürlich auch mit dem CP Newsletter, die Anrede muss dann halt direkt beim Namen mit eingegeben werden.

Eine Anrede gehört schon dazu, das sehe ich genau so wie Jens.

Vom Grundsatz her fehlt in der DB mindestens ein Feld Anrede.

Knut

[Marceau]

Da ich bei einem aktuellen Projekt eine mehrsprachige Seite benutze und die Bestätigungsmail der Sprache des Absenders entprechen sollte habe ich das Ganze mal für mich erweitert.

Folgende Stellen müssen angepasst werden:

/include/inc_lib/content/cnt23.readform.inc.php

Suche nach:

Code: Select all

case 'subject':	$newletter_array['subject'] = $newsletter[1]; break;

Darunter einsetzen:

Code: Select all

case 'lang': $newletter_array['lang']	= $newsletter[1]; break;

/include/inc_front/content/cnt23.article.inc.php

Suche nach:

Code: Select all

case 'double_optin':	$form_newletter_setting['double_optin'] =  intval($form_value_nl[1]) ? 1 : 0;break;

darunter einfügen:

Code: Select all

case 'lang': $form_newletter_setting['language'] = $form_value_nl[1]; break;

Suche nach:

Code: Select all

$cnt_form['verifyemail'] = file_get_contents(PHPWCMS_TEMPLATE.'inc_cntpart/newsletter/email/default.opt-in.txt');

Ersetzen durch:

Code: Select all

if(!empty($form_newletter_setting['language'])) { 
   $cnt_form['verifyemail'] = file_get_contents(PHPWCMS_TEMPLATE.'inc_cntpart/newsletter/email/'.$form_newletter_setting['language'].'.opt-in.txt');
}
else {
   $cnt_form['verifyemail'] = file_get_contents(PHPWCMS_TEMPLATE.'inc_cntpart/newsletter/email/default.opt-in.txt');
}

Nun kann man im CP Formular im Abschnitt Newsletter die Sprache der Bestätigungsmail hinzufügen. Beispiel de für Deutsch oder en für Englisch:

lang=de

Nun geht man in den Ordner /template/inc_cntpart/newsletter/email/ und legt eine Textdatei an de.opt-in.txt für Deutsch. Das kann für jede Sprache verwenden, die man benötigt.
Wichtig ist hierbei wie gesagt, dass das eingetragene Sprachkürzel dem aus dem CP-Formular entspricht (Bsp. lang=de oder lang=en...)

Ich hoffe ich konnte es einiger Maßen gut rüber bringen, wie ich es meine...

[update]

Das könnte Oliver auch interessieren...

[Jensensen]

...dass uns die Datei
template/inc_cntpart/newsletter/email/default.opt-in.txt

und insbesondere deren Speicherort suggerierte, es handele sich um ein TEMPLATE --> der gewohnten Art.

HA - potzblitz - DEM IST --> leider NICHT SO!

Dateien mit abweichenden Dateinamen werden ignoriert.
[...]

es kann [derzeit] keine anderen "templates" geben, ausser 'default.opt-in.txt', in template/inc_cntpart/newsletter/email/
[...]

Wie macht ihr das mit dieser Datei in eurem git-projekt?
Wenn man diese Datei mit den eigenen Daten überschreibt, gibt es mit dem nächsten pull nur Theater. Auf untracked setzen, oder in gitignore reinschieben oder die eigene 'my-default.opt-in.txt" adden oder im extra branch mitschleifen oder ausserhalb des Projektes verwalten und auf den Webspace laden?

Ich habe nämlich bereits mehrfach die eigene Datei --> unbemerkt mit der default überschrieben - und das ist beim Publikum gar nicht so gut angekommen.
Dank und Grüße

[Oliver Georgi]

das ist ein evolutionäres Ding.

Und für den Merge ist das halt so eine Sache. Da musst Du versuchen, zu einem Punkt zu kommen, bei dem es immer zum Konflikt für die Datei kommt. Oder eben auf dem Schirm behalten. Ansonsten halt Stashes anschauen, bzw. generell unterschiedliche Branches pflegen.

Ich merge meist Bestandsprojekte nicht einfach so, sondern nutze meinen Produktivbranch und mache Merge mittels simplem Dateivergleich (Changes, WinMerge und Konsorten). Ist zuverlässiger, vor allem für den Template-Ordner und dateibasierte Vorlagen.

[update]

Idee: Einfacher wäre es vielleicht, zB die weiter oben aufgeführten Anregungen in den core zu übernehmen (Anrede, templating). Dann hätte man (unüberschreibbare) custom templates und könnte den Kram einfach überbügeln...
Als Modul wäre es natürlich auch nicht schlecht (-> besser) - scheint ja nicht weit davon entfernt zu sein.

BTW: Hallo Jens