Minimales Setup für Standard-Mailformular sollte mitbringen: Reply-To an Websitebesucher fester From-Name… …und From-Email (sonst ggf. falsch automatisiert ermittelt) Konfiguration könnte somit etwa aussehen wie folgt: Name | *replyto_name=input E-Mail | *replyto_email=input Nachricht | *Nachricht=textarea | from_name=hidden | example.com | from_email=hidden | info@example.com | formtype_mail=submit | Absenden | html_enabled=hidden | subject=hidden | example.com Mailformular
Heute benötigte ich innerhalb eines generischen Markers von tt_news Zugriff auf das Content-Element, in dem die Meldung angezeigt wird (also die Plugin-Einbindung). Warum man sowas braucht? Naja, Projekte entwickeln sich manchmal kreativ… 😉 Generische Marker werden im Zuge des Renderings der einzelnen Newsmeldungen ausgewertet, d.h. der Zugriff über field etc. ist jeweils auf den tt_news-Datensatz, nicht auf das Inhaltselement. Der Datensatz selbst hat auch keine Verknüpfung zum Inhaltselement. 🙁 Die Kollegen der marit.ag haben vor Längerem den Artikel „Datenbankfelder dynamisch per stdWrap.data auslesen“ verfasst. Damit ließe sich (via „getText“) auf beliebige Datensätze dynamisch zugreifen wie folgt: genericmarkers { ...
Um Bilder nicht nur eine feste Breite in Abhängigkeit von der colPos zuzuweisen, sondern auch noch zu croppen, bentötigt man folgendes Snippet: temp.tt_content.image < tt_content.image tt_content.image = CASE tt_content.image { key.field=colPos 0 < temp.tt_content.image 1 < temp.tt_content.image 2 < temp.tt_content.image 1.20.1.file.width > 1.20.1.file.height > 1.20.1.file { width = 698c height = 400c } 2.20.1.file.width > 2.20.1.file.height > 2.20.1.file { width = 200c height= 150c } }
Um Links in HTML-Elementen zu parsen benötigt man folgende Zeilen im setup: # Syntax: # ausgelassene Parameter können hinten weggelassen oder durch „-“ freigehalten werden # <link PID/URL/Mail TARGET/WIDTHxHEIGHT CLASS „TITLE“>LINKTEXT</link> # # Beispiele: # <link 2>Zur Seite</link> # <link 7 – a-link „zur Information“>hier</link> # <link http://www.google.de 300×400 myPopup-class „in neuem Fenster“>Google</link> # <link info@abc.de – myMail „E-Mail senden“>Kontakt</link> # tt_content.html.parseFunc.tags.link < lib.parseFunc.tags.link Das target kann dann noch über das setup folgendermaßen ändern: tt_content.html.parseFunc.tags.link.typolink { extTarget > extTarget = _self target > target = _self }
Auf welche Weise die Sprachbehandlung und Fallbacks erfolgen sollen bzw. ob die Regelung auch für Bilder greifen soll, ist von Projekt zu Projekt verschieden. Eine öfters anzutreffende Variante ist: Falls kein Bild in der Übersetzung der Seite vorhanden ist (pages_overlay), nimm das aus der Default-Sprache, falls dort auch keines ist, dann schau in der Rootline nach oben bis eines gefunden wird. // 1. Idealerweise das Bild aus dem media-Feld der Sprache nehmen (override) // 2. Falls leer, dann das aus der Default-Sprache (override.ifEmpty) // 3. Falls da auch nix drin steht, dann levelmedia bis Root hochgucken temp.dynamicImage = IMG_RESOURCE...
Hier einmal ein paar userConfig Einstellungen, die z.B. hilfreich sind, wenn der Redaktionsbenutzer nur seinen Namen oder Passwort ändern darf. setup.override { # Persönliche Daten ein/ausblenden realName = ## Ihr Name email = ## Ihre E-Mail-Adresse emailMeAtLogin = 0 ## Mich per E-Mail benachrichtigen, wenn sich jemand mit meinem Konto anmeldet password = ## Neues Passwort password2 = ## Neues Passwort (Wiederholung) lang = de ## Backend-Sprache # Beim Start ein/ausblenden startModule = ## Beim Start folgendes Modul aufrufen ...
Folgendes Problem: Bei der Anmeldung zu einem Newsletter soll der Haken bei HTML-Mails Standardmäßig eingeschaltet sein. User haben meist nicht die Möglichkeit dies zu steuern. Dieses kleine Snippet macht es möglich. # html als Standard plugin.feadmin.dmailsubscription { table=tt_address create.overrideValues.disable = 1 create.overrideValues.module_sys_dmail_html = 1 } Oder man baut direkt in das Anmeldeformular ein hiddenfield mit dem entsprechenden Wert ein: lib.nl-anmeldung = HTML lib.nl-anmeldung.value( <div> <div><h1>Newsletter</h1></div> <form action=“kontakt/newsletter/?“ method=“post“ name=“tt_address_form“ /> <input type=“hidden“ name=“FE[tt_address][name]“ value=“—“ /> <p>E-Mailadresse:<br /></p> <input type=“text“ name=“FE[tt_address][email]“ /> <input type=“hidden“ name=“FE[tt_address][module_sys_dmail_html]“ value=“1″ /> <br /> <input type=“submit“ name=“whatever“...
Das Szenario ein geschützter Kundenbereich ein Newsletter für Kunden (Direct Mail) ein Newsletter-Archiv im Kundenbereich Das Problem Wird der Newsletter (bzw. die interne Seite, die dem Newsletter als Basis dient) via Frontend-Benutzergruppen-Einschränkung vor ungewollten Blicken geschützt, kann sein Inhalt auch von Direct Mail nicht gecrawlt werden. Schützt man die Seite hingegen nicht, kann sie von jedem beliebigen User aufgerufen werden, sobald er die URL kennt. Die Lösung Wie löst ihr solche Anforderungen ohne viel Technik-Bastelei?
Nach langem Befragen von Google und keinem passenden Ergebnis, haben wir nun eine Lösung gefunden, wie man die Bildbreite oder -höhe abhängig vom gewählten Rahmen setzen kann. Die Lösung über tt_content.image.20.maxW.cObject zu gehen ist in unserem Fall nicht flexibel genug gewesen, da hier nur die Breite und nicht die Höhe angesprochen werden kann. Als erstes wenn gewünscht eigene Rahmen anlegen. Setup: tt_content.stdWrap { innerWrap.cObject = CASE innerWrap.cObject { 31 =< tt_content.stdWrap.innerWrap.cObject.default 31.30.value = ><div class=“teaser“>|</div></div> 32 =< tt_content.stdWrap.innerWrap.cObject.default 32.30.value = ><div class=“teaser last“>|</div></div> } } Pageconfig: TCEFORM.tt_content { section_frame.removeItems = 1,5,6,10,11,12,20,21 section_frame.altLabels.0 = Bitte wählen Sie Ihr Layout section_frame.addItems.31 = Teaser...
Wer des öfteren mal die Funktionalität von TYPO3 mit eigenen Extensions erweitert, wird des Öfteren auf das Problem stoßen, dass bei der Erweiterung von Tabellen oder beim anlegen von Extension-spezifischen Datenbanktabellen bei der hauseigenen Suche außen vor bleiben. Hier ist es sinnvoll, der Suche mitzuteilen, es möge doch bei der Suche auch zusätzliche Felder berücksichtigen. Dies lässt sich einfach und – im Gegensatz zu IF-Abfragen – einfach über TypoScript lösen. Um der Suche die neuen Datenbank-Tabellen und/oder Felder mitzuteilen, geht man folgendermaßen vor. Standard-Wert für „Überschriften und Schlagwörter“: tt_content.search.30.dataArray.20.valueArray.10.value = pages.title-subtitle-keywords-description Standard-Wert für „Seiteninhalt“: tt_content.search.30.dataArray.20.valueArray.20.value = pages.title-subtitle-keywords-description : tt_content.header-bodytext-imagecaption Zur...