Kategorie: Typo3

  • TYPO3: Seitentitel mit Daten aus Extension befüllen

    Oft setzt man auf seiner Typo3 Seite Plugins ein, welche die Funktion Listenansicht und Detailansicht beinhalten. Klassische Beispiele hierfür sind Plugins wie News oder Stellenangebote. Für die SEO Optimierung ist es meist notwendig den Seitentitel entsprechend anzupassen, da man mit einer Seite „Stellenangebot“ meist relativ wenig anfangen kann. Hier wäre es gut, wenn z.B. der Titel des Stellenangebotes nach „Stellenangebot“ erscheint.

    Wenn die Erweiterung dies aber nicht von selbst macht, kann man dies einfach über ein Typoscript Template auf der Detailseite des Plugins erledigen. Man muss lediglich prüfen, an welcher Stelle der Titel gesetzt wird (falls man diesen schon in der Seitenkonfiguration überschrieben hat).

    page.headerData.5 >
    page.headerData.5 = TEXT
    page.headerData.5.data = GP:tx_jobfair_pi1|job
    page.headerData.5.wrap = <title>Stellenangebot - {DB:tx_jobfair_domain_model_job:|:job_title}</title>
    page.headerData.5.insertData = 1

     

  • TYPO3: formhandler Daten aus der Datenbank übernehmen

    Offenbar mutiert formhandler gerade zu einem meiner Lieblingsthemen in Typo3. Auch an dieser Stelle wieder der Hinweis: formhandler wird nicht mehr aktiv weiterentwickelt!

    Der Kundenwunsch ist eine Double-Opt-In Anmeldung für einen Newsletter mit tt_address und formhandler. Als kleines Schmankerl soll jedoch nach erfolgreicher Freischaltung bzw. Aktivierung der Newsletteranmeldung durch den Abonnenten der Administraotr der Seite noch zusätzlich per Email darüber informiert werden. Hintergrund für das Email an den Administrator ist die Verwendung einer eigenen Adressverwaltung, welche jedoch nicht extern erreichbar ist.

    Als Grundlage dient mir hierbei die Konfiguration von Browserwerk, welche bereits eine recht gute Anleitung zum Thema geschrieben haben.

    Konfiguration AuthCode-Validierung

    Die Konfiguration für das Email ist recht einfach. Hier gilt es nur zu beachten, dass der „AuthCodeValidator“ keine redirectPage hat – sonst leitet er bei erfolgreicher Validierung weiter an die „Erfolg“-Seite, noch bevor das Email verschickt werden kann. Hier ist es also wichtig, nur die errorRedirectPage zu setzen.

        preProcessors {
            1.class = PreProcessor_LoadGetPost
    
            10.class = PreProcessor_ValidateAuthCode
            10.config {
                errorRedirectPage = 123
                hiddenField = hidden
                uidField = uid
                table = tt_address
            }
        }

    Konfiguration Email-Finisher

    Das ist soweit kein Problem, man kann ja einen entsprechenden Finisher setzen, der dies übernimmt. Dort werden auch die Settings für das Versenden des Bestätigungsmails an den Admin eingestellt.

    finishers {
            3.class = Finisher_Mail
            3.config {
                checkBinaryCrLf = message
                admin {
                    templateFile = TEXT
                    templateFile.value = Pfad-zu/html/email-admin.html
                    sender_email = newsletteranmeldung@example.com
                    to_email = admin@example.com
                    subject = TEXT
                    subject.data = LLL:Pfad-zu/lang/lang.xml:email_admin_subject
                }
                user >
            }
            4.class = Finisher_Redirect
            4.config {
                redirectPage = 134
            }
    }

    Nun funktioniert das Formular soweit wie vom Kunden gewünscht. Der Abonennt meldet sich an, bekommt ein Email mit einem Link zur Bestätigung, und erst nach Klick auf den Link ist er freigeschaltet. Aber wie bekommt man aber nun die Information der Anmeldung (z.B. Email oder Name) in das Bestätigungsemail an den Admin? Man könnte es sich ja einfach machen und die Email mit als URL Parameter mitgeben. Das ist aber weder schön, noch gut, noch sinnvoll. Aber man bekommt ja die uid mitgeliefert.

    Markers

    In meiner Lösung verwende ich die Markers von formhandler, um zum einen die uid aus der URL auszulesen und dann den Datensatz aus tt_address auszulesen. Das Ganze findet noch vor dem PreProcessor statt. Bei pidInList sollte der Speicherort der tt_address-Datensätze angegeben werden.

    markers {
    	registermail = CONTENT
            registermail {
                table = tt_address
                select {
                    pidInList = 154
                    selectFields = email
                    where.dataWrap = uid={GP:subscription|uid}
                }
                renderObj = COA
                renderObj {
                    10.wrap = "|"
                    10 = TEXT
                    10.field = email
                }
            }
    }

    Jetzt kann man ohne weiteres im mastertemplate an beliebiger Stelle, zum Beispiel im Admin-Mail, mit ###registermail### auf die aus der Datenbank ausgelesenen Emailadresse zugreifen und diese so an den Admin übermitteln.

    <!-- ###master_email-admin-start-plain### -->
    
    ###LLL:email_admin_text###
    ###registermail###
    
    <!-- ###master_email-admin-start-plain### -->
    
    <!-- ###master_email-admin-start-html### -->
    
    <p><strong>###LLL:email_admin_text###</strong></p>
    <p>###registermail###</p>
    <br />
    <table>
    <!-- ###master_email-admin-start-html### -->

    Die fertige Typoscript-Konfiguration

    Die komplette Typoscript-Konfiguration kann dann so aussehen:

    plugin.Tx_Formhandler.settings.predef.double-opt-in-confirm {
    
    	name = Newsletter Registrierung - Validierung
        skipView = 1
    	formValuesPrefix = subscription
    
    	langFile.1 = TEXT
    	langFile.1.value = {$formhandler.double-opt-in-confirm.rootPath}/lang/lang.xml
    
    	templateFile = TEXT
    	templateFile.value = {$formhandler.double-opt-in-confirm.rootPath}/html/step-1.html
    
    	# The master template is a file containing the markup for specific field types or other sub templates (e.g. for emails). You can use these predefined markups in your HTML template for a specific form.
    	masterTemplateFile = TEXT
    	masterTemplateFile.value = {$formhandler.double-opt-in-confirm.rootPath}/html/mastertemplate.html
    
    	# CSS files
    	cssFile {
    		10 = TEXT
    		10.value = {$formhandler.double-opt-in-confirm.rootPath}/skin/css/none.css
    		10.if.isTrue = {$formhandler.double-opt-in-confirm.includeFoundationCSS}
    		20 = TEXT
    		20.value = {$formhandler.double-opt-in-confirm.rootPath}/skin/css/none.css
    	}
    	
    	# In case an error occurred, all markers ###is_error_[fieldname]### are filled with the configured value of the setting "default".
    	isErrorMarker {
    		default = error
    	}
    
    	markers {
    	    registermail = CONTENT
            registermail {
                table = tt_address
                select {
                    pidInList = {$formhandler.double-opt-in-confirm.recordStorage}
                    selectFields = email
                    where.dataWrap = uid={GP:subscription|uid}
                }
                renderObj = COA
                renderObj {
                    10.wrap = "|"
                    10 = TEXT
                    10.field = email
                }
            }
    	}
    
        preProcessors {
            1.class = PreProcessor_LoadGetPost
    
            10.class = PreProcessor_ValidateAuthCode
            10.config {
                errorRedirectPage = {$formhandler.double-opt-in-confirm.redirectErrorPage}
                hiddenField = hidden
                uidField = uid
                table = tt_address
            }
        }
    
        finishers {
            3.class = Finisher_Mail
            3.config {
                checkBinaryCrLf = message
                admin {
                    templateFile = TEXT
                    templateFile.value = {$formhandler.double-opt-in-confirm.rootPath}/html/email-admin.html
                    sender_email = {$formhandler.double-opt-in-confirm.email.admin.sender_email}
                    to_email = {$formhandler.double-opt-in-confirm.email.admin.to_email}
                    subject = TEXT
                    subject.data = LLL:{$formhandler.double-opt-in-confirm.rootPath}/lang/lang.xml:email_admin_subject
                }
                user >
            }
            4.class = Finisher_Redirect
            4.config {
                redirectPage = {$formhandler.double-opt-in-confirm.redirectSuccessPage}
            }
    
        }
    	
    	# These wraps define how an error message looks like. The message itself is set in the lang file.
    	singleErrorTemplate {
    		totalWrap = <small class="error">|</small>
    	}
    }

     

     

     

  • TYPO3: SSL Zertifikat in einer Multidomainumgebung

    Angenommen man hat eine Typo3 Multidomainumgebung, welche die Domains kundenname1.de, kundenname2.de und kundenname3.de ohne ein SSL Zertifikat verwaltet, der Webserver selbst befindet sich hinter einem Loadbalancer, welcher die Anfragen intern entsprechend weitergibt. Nach außen Port 443, intern werden Anfragen über Port 80 verarbeitet.

    Nun entscheidet der Kunde, dass die Domain kundenname3.de ein SSL Zertifikat erhalten muss. Das Zertifikat ist bereits auf dem Server eingerichtet, die Redirects im Webserver sind gesetzt, die Webserver-Konfiguration wurde angepasst und die BaseURL wurde für diese eine Domain für die Multidomainumgebung im Typo3 angepasst.

    Auf einmal steht man dann vor dem folgenden Problem: Im Backend ist über SSL der Seitenbaum nicht mehr sichtbar. Das liegt an den folgenden fehlenden Einträgen in der LocalConfiguration.php.

    'SYS' => array(
    	'trustedHostsPattern' => '.*\\.kundendomain1|.kundendomain2|.kundendomain3\\.de:*',
    	'reverseProxyIP' => '*.*.*.*',
    	'reverseProxySSL' => '*',
    ),

    Mit den Einträgen funktioniert nun auf jeden Fall mal das Backend mit SSL Zertifikat unter der Domain kundenname3.de – allerdings leiten die ersten Aufrufe der Domains im Frontend kundenname1.de und kundenname2.de jetzt auf SSL um. Somit werden die benötigten Sourcen wie z.B. CSS nicht korrekt ausgeliefert (das Zertifikat ist ja nicht für die Domain verfügbar), und die Webseiten ohne Zertifikat sehen aus wie … Kraut und Rüben. Alle weiteren Aufrufe, z.B. Klicks auf Unterseiten, sind jedoch kein Problem, da die baseURL weiterhin ohne SSL hinterlegt ist und den Links vorangestellt wird.

    Um das zu umgehen kann man sich mit folgender Einstellung in der LocalConfiguration.php helfen.

    ACHTUNG: Der Code sollte später in eine Extension ausgelagert werden, um ein Überschreiben durch Typo3 zu verhindern.

    Noch vor dem „return“ fügt man folgende Zeilen php-Code ein:

    $host = $_SERVER['HTTP_HOST'];
    switch( $host ) {
    	case 'kundenname1.de':
    	case 'www.kundenname1.de':
    	case 'kundenname2.de':
    	case 'www.kundenname2.de':
    		$reverseProxyIP = '';
    		$reverseProxySSL = '';
    		break;
    	default:
    		$reverseProxyIP = '*.*.*.*';
    		$reverseProxySSL = '*';
    		break;
    }

    Anschliessend werden die Einträge unter ‚SYS‘ angepasst.

    'SYS' => array(
    	'reverseProxyIP' => $reverseProxyIP,
    	'reverseProxySSL' => $reverseProxySSL,
    ),

    Mit dieser kleinen und einfachen Anpassung sollte nun sowohl das Typo3 Backend als auch das Frontend jeweils mit dem korrekten Protokoll ausgeliefert werden und funktionieren.

     

    Und damit das Ganze in der LocalConfiguration.php dann auch nicht zufälligerweise von Typo3 aus Versehen überschrieben wird packt man die Konfiguration am allerbesten in die ext_localconf.php einer eigenen Extension.

    $host = $_SERVER['HTTP_HOST'];
    switch( $host ) {
    	case 'kundenname1.de':
    	case 'www.kundenname1.de':
    	case 'kundenname2.de':
    	case 'www.kundenname2.de':
            $reverseProxyIP = '';
            $reverseProxySSL = '';
            break;
        default:
            $reverseProxyIP = '*.*.*.*';
            $reverseProxySSL = '*';
            break;
    }
    
    $GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxyIP'] = $reverseProxyIP;
    $GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxySSL'] = $reverseProxySSL;

     

  • TYPO3: sendy-Integration mit formhandler

    Da ich jedoch für ein Projekt kurz zuvor eine kleine Extension geschrieben habe, welche sendy (siehe Beitrag „Newsletterversand mit sendy“) in Typo3 integriert, möchte ich diese Lösung dennoch hier vorstellen.

    Hinweis: Die Entwicklung von formhandler wurde die Tage (Stand Oktober 2016) eingestellt.

    Ziel ist die Erstellung eines Formulares mit formhandler und Speichern der eingegebenen Daten in der sendy-Datenbank, um später darüber sowohl die Abonnenten als auch den Newsletterversand zu verwalten.

    1. Erstellung eines Formulares
    2. Erstellung eines Plugins „formhandler_sendy“
    3. Einbindung ins Formular

    Erstellung eines Formulares

    Zunächst erstellt man mit formhandler ein simples Formular. Bei einer Newsletteranmeldung reicht das Feld Email für den Anfang vollkommen aus (auch aus datenschutzrechtlichen Gründen). Ich habe in meinem Projekt den Beispielcode von Formhandler mit sr_freecap genutzt, um Spam zu vermeiden.

    Erstellung eines Plugins für sendy

    Als nächster Punkt muss ein neues Plugin erstellt werden. Als Name habe ich formhandler_sendy gewählt.

    Struktur:

    formhandler_sendy

    • Classes
      • Validator
        • Sendy.php
        • sendy_signup.php
    • Configuration
      • TypoScript
        • setup.txt
    • ext_emconf.php

    ext_emconf.php:

    $EM_CONF[$_EXTKEY] = array (
      'title' => 'Formhandler Sendy Integration',
      'description' => '',
      'category' => '',
      'version' => '0.0.1',
      'state' => 'stable',
      'uploadfolder' => false,
      'createDirs' => '',
      'clearcacheonload' => true,
      'author' => 'Florian Freiburg',
      'author_email' => ' ',
      'author_company' => 'Schreiber & Freunde GmbH & Co. KG',
      'constraints' => 
      array (
        'depends' => 
        array (
          'typo3' => '6.2.0-8.0.999',
          'php' => '5.3.2-7.0.999',
          'realurl' => '2.0.14-3.0.0',
          'formhandler' => '',
        ),
        'conflicts' =>
            array(),
        'suggests' => 
        array (
        ),
      ),
    );

    Classes/Validator/Sendy.php:

    <?php
    
    namespace Vendor\Formhandler_Sendy\Validator;
    /*                                                                        *
     * This script is part of the TYPO3 project - inspiring people to share!  *
     *                                                                        *
     * TYPO3 is free software; you can redistribute it and/or modify it under *
     * the terms of the GNU General Public License version 2 as published by  *
     * the Free Software Foundation.                                          *
     *                                                                        *
     * This script is distributed in the hope that it will be useful, but     *
     * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHAN-    *
     * TABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General      *
     * Public License for more details.                                       *
     *
     *                                                                        */
    
    /**
     * This finisher sends submitted form data to sendy (sendy.co).
     *
     * @author	Florian Freiburg
     * @package	Tx_Formhandler
     * @subpackage	Finisher
     */
    class Sendy extends \Typoheads\Formhandler\Validator\AbstractValidator {
    
    	/**
    	 * Validates the submitted values using given settings
    	 *
    	 * @param array &$errors Reference to the errors array to store the errors occurred
    	 * @return boolean
    	 */
    	public function validate(&$errors) {
    
    		//First validator returned errors, do nothing
    		if(!empty($errors)) {
    			return TRUE;
    		}
    
    		$params = array(
    			'sendyUrl' => $this->settings['sendyUrl'],
    			'listId' => $this->settings['listId']
    		);
    
    		require_once('sendy_signup.php');
    		$api = new sendy_signup();
    		$result = $api->add_subscription($params);
    
    		return $result;
    	}
    }
    ?>
    

    Classes/Validator/sendy_signup.php

    Sollten im Formular mehr Felder als nur die Emailadresse vorhanden sein, sollten diese natürlich mit aufgenommen werden. Weiterhin müssen diese Felder in der Empfängerliste im Sendy als Custom-Fields angelegt werden. Sendy kennt von sich aus nur die Felder Email und Name.

    <?php
    
    namespace Vendor\Formhandler_Sendy\Validator;
    
    class sendy_signup {
    
        public function __construct() {
    
        }
    
       public function add_subscription($params) {
    
            //------------------- Edit here --------------------//
           $sendy_url = $params['sendyUrl'];
           $list = $params['listId'];
    
           //------------------ /Edit here --------------------//
    
           //--------------------------------------------------//
           //POST variables
           $email = $_POST['sr_freecap']['email'];
    
           //subscribe
           $postdata = http_build_query(
               array(
                   'email' => $email,
                   'list' => $list,
                   'boolean' => 'true'
               )
           );
           $opts = array('http' => array('method'  => 'POST', 'header'  => 'Content-type: application/x-www-form-urlencoded', 'content' => $postdata));
           $context  = stream_context_create($opts);
           $result = file_get_contents($sendy_url.'/subscribe', false, $context);
           //--------------------------------------------------//
    
           return $result;
    
       }
    }
    
    ?>

    Configuration/TypoScript/setup.txt

    plugin.tx_formhandlersendy {
    
    }

     

    Einbindung ins Formular

    Die Einbindung ins Formular ist denkbar einfach. Hier wird einfach ein neuer Validator im Setup des Formulares hinzugefügt, welcher die sendy-Klasse anspricht. Die Werte in der Config des Validators für sendy sind natürlich anzupassen.

    plugin.Tx_Formhandler.settings.myExampleForm {
    
    	name = Newsletter registration with sendy.co
    
    	... your definitions ...
    	
    	# This block defines the error checks performed when the user hits submit.
    	validators {
    		1.class = Validator_Default
    		1.config.fieldConf {
    		
    			email.errorCheck.1 = required
    			email.errorCheck.2 = email
    			email.errorCheck.4 = emailExists
    			email.errorCheck.5 = betweenLength
                		email.errorCheck.5 {
    		                minValue = 8
                    		maxValue = 70
    			}
    			email.errorCheck.6 = containsAll
    			email.errorCheck.6 {
    			    words = @,.
    			}
    			freecapfield.errorCheck.1 = required
    			freecapfield.errorCheck.2 = srFreecap
    		}
    
    		# This special Validator will take care of adding the new subscriber. In case of an error, the according message will be displayed.
    	        2.class = Vendor\Formhandler_Sendy\Validator\Sendy
            	2.config {
    	            sendyUrl = http://path-to-your-sendy.com
            	    listId = sendy-subscriber-list-id
    	        }
    	}
    
    	... your finishers and loggers ...
    
        }
    }
    

     

    Da die Abmeldung über den versendeten Newsletter läuft (Abmeldelink in Email), wird an dieser Stelle auf ein weiteres Formular zu Abmeldung über Typo3 verzichtet. Prinzipiell ist dies ebenfalls über die Sendy-API möglich.

  • TYPO3: formhandler Version 2.4.0 & sr_freecap

    Wer die Kombination formhandler mit der Extension sr_freecap zur Vermeindung von Spam nutzt und die Tage ein Update der Erweiterung gemacht hat wird auf folgendes Problem stoßen:

    Es wird kein Captcha mehr angezeigt *PANIK*

    In Version 2.3.1 wurde von Formhandler simpel abgefragt, ob sr_freecap installiert ist. Anschliessend wurde sr_freecap instanziert, ein Captcha generiert und an das Template übergeben – auch wenn es gar nicht verwendet wird.

    Die neueste formhandler-Version 2.4.0 fragt zusätzlich noch ab, ob der Marker ###SR_FREECAP_### vorhanden ist. Diesen gibt es im Template aber nicht, auch nicht in den offiziellen Beispielen. Folglich kommt formhandler zum (Trug-)Schluss, kein Captcha generieren zu müssen.

    Da laut Homepage formhandler (leider) nicht mehr weiterentwickelt wird, habe ich mir mit einer kleinen Modifikation meines ausgelagerten Templates beholfen. In der Sektion von sr_freecap habe ich einen versteckten div untergebracht, welcher den Marker aus der Programmierung enthält.

    Das Captcha (Cache leeren!) danach sofort wieder korrekt angezeigt.

  • TYPO3: formhandler per Typoscript einbinden

    Manchmal werden Formulare in Bereichen benötigt, die auf der gesamten Webseite die selbe Darstellung und Position haben. Dem Redakteur die Pflege zuzumuten ist etwas, das mir persönlich missfällt. Die Arbeit nehme ich ihm gerne ab. Somit muss/soll/kann man das Formular, welches man mit Formhandler angelegt hat, per Typoscript einbinden.

    Wie das funktioniert ist hier kurz beschrieben, ich gehe von einem existierenden Formular aus.

    Typoscript:

    lib.myform < plugin.tx_formhandler_pi1
    lib.myform.settings < plugin.Tx_Formhandler.settings.predef.meinFormular

    Fluid-Template:

    <f:cObject typoscriptObjectPath="lib.myform" />

     

     

  • TYPO3: Extension vhs – Viewhelper für FLUID

    Mit Fluid lässt sich viel Logik aus Typoscript und PHP in die Frontend-Templates auslagern. Aber auch Fluid sind Grenzen gesetzt. Für Funktionalitäten, die nicht nativ in Fluid vorhanden sind, gibt es die TYPO3 Erweiterung vhs (das External Manual der Erweiterung findet ihr hier). Diese wurde 2012 das erste Mal im TER bereitgestellt und zählt mittlerweile über 30.000 Dowloads. Ich setze die Erweiterung mittlerweile selbst in fast jedem Projekt ein.

    Einmal über den Extensionmanager installiert, lässt sie sich fast sofort im Template verwenden. Hierzu muss man lediglich den Viewhelper über den Namespace im Template bekannt machen. Das kann man auf zwei Arten erledigen.

    Einbindung 1:

    {namespace v=FluidTYPO3\Vhs\ViewHelpers}
    
    <!-- Your code -->

    Einbindung 2:

    <div xmlns:v="http://typo3.org/ns/FluidTYPO3/Vhs/ViewHelpers"
         v:schemaLocation="https://fluidtypo3.org/schemas/vhs-master.xsd">
    	<!-- Fluid goes here -->
    </div>

    Und schon kann man loslegen. Aber für was braucht man die Erweiterung? Für alles, was man sonst über Typoscript lösen und erst dann dem Template übergeben würde. Aus meiner Sicht lassen sich manche Anforderungen nicht so leicht im Typoscript erledigen. Weiterhin ist aus meiner Sicht die Lesbarkeit von FLUID für Einsteiger besser geeignet.

     

    Beispiel 1:

    Gruppierte Ausgabe einer Liste

    Im folgenden Beispiel soll eine Nachrichtenliste (aus der Erweiterung „news“) ausgeben werden. Diese Liste soll durch den jeweiligen Monat, in dem sie einstellt wurde, getrennt werden. Also eine klassische Gruppierung nach Monat.

    Dazu merkt man sich der Einfachkeit halber einfach den Monat der Nachricht und vergleicht ihn mit der vorherigen. Geht aber nicht. Die nächste Variante wäre es den Monat der aktuellen News in einer Variablen zu speichern und beim nächsten Durchlauf mit dem aktuellen Monat zu vergleichen. Geht so aber auch nicht (eine Korrektur falls diese Aussagen nicht stimme ist erwünscht). Dafür kann vhs aber Variablen anlegen, speichern und abrufen.

    {namespace v=FluidTYPO3\Vhs\ViewHelpers}
    <v:variable.set name="oldMonth" value="00"></v:variable.set>
    <f:for each="{paginatedNews}" as="newsItem" iteration="iterator">
        <f:if condition="{oldMonth} != {f:format.date(date: newsItem.datetime, format: 'F')}">
            <div class="event-month row">{f:format.date(date: newsItem.datetime, format: 'F')}</div>
        </f:if>
        <f:render partial="List/EventsItem" arguments="{newsItem: newsItem,settings:settings,iterator:iterator}" />
        <v:variable.set name="oldMonth" value="{f:format.date(date: newsItem.datetime, format: 'F')}"></v:variable.set>
    </f:for>

    Zunächst wird per variable.set der Monatsname auf 00 gesetzt.

    Innherhalb der for-each-Schleife wird nun der Monat der zuvor gesetzten Variablen mit dem Monat der aktuellen Nachricht verglichen. Ist dieser nicht identisch, wird der Monatsname ausgegeben. Anschliessend wird die Variable auf den Monat der aktuellen News.

     

    Beispiel 2:

    Ausgabe der Inhalte aller untergeordneten Seiten (Onepager)

    Mit ein paar Zeilen lässt sich ein einfacher Onepager einrichten, der alle Inhalte der (in erster Ebene) untergeordneten Seiten ausgibt.

    {namespace v=FluidTYPO3\Vhs\ViewHelpers}
    <v:page.menu pageUid="{pageUid}" as="sections">
    
    </v:page.menu>

    pageUid übermittelt dem Viewhelper, welche Seite aus dem Menu ausgegeben werden soll. Das kann man statisch hinterlegen oder über Typoscript dynamisch an die variables des Templates übergeben.

    Nun durchläuft man in einer Schleife alle Menupunkte, zur Kontrolle kann man schon mal den Titel der jeweiligen Seite ausgeben.

    {namespace v=FluidTYPO3\Vhs\ViewHelpers}
    <v:page.menu pageUid="{pageUid}" as="sections">
        <f:for each="{sections}" as="section" iteration="iteration">
            <div class="section" id="section{section.uid}">
                <div class="content">
                    <h2>{section.title}</h2>
                </div>
            </div>
        </f:for>
    </v:page.menu>

    Jetzt benötigt man nur noch den in der jeweiligen Seite gepflegten Inhalt. Auch hier gibt es ein kleines Helferlein namens „content.render“ in der Erweiterung. Durch Übergabe der pageUid werden die Inhalte der Seite ausgelesen und gerendert. In meinem Fall hat das Template nur eine Spalte im Backend, weswegen keine zusätzlichen Argumente übergeben werden.

    Das fertige Snippet kann dann so aussehen:

    {namespace v=FluidTYPO3\Vhs\ViewHelpers}
    <v:page.menu pageUid="{pageUid}" as="sections">
        <f:for each="{sections}" as="section" iteration="iteration">
            <div class="section" id="section{section.uid}">
                <div class="content">
                    <h2>{section.title}</h2>
                    <v:content.render pageUid="{section.uid}" />
                </div>
            </div>
        </f:for>
    </v:page.menu>

     

    Natürlich kann die Erweiterung noch Vieles mehr als nur die beiden oben genannten Beispiele – ein Blick in die Dokumentation der Extension lohnt sich eigentlich immer.

  • TYPO3: Variablen in FLUID an ein Partial übergeben

    Durch Fluid können Templates wunderbar in Partials unterteilt werden, was der allgemeinen Übersicht sehr dienlich ist. Weiterhin können Partials in mehreren Templates wiederverwendet werden, ohne jedesmal den benötigten „Grund“-HTML-Code zu kopieren (ja, das funktioniert in TemplaVoila auch recht gut, aber darauf gehe ich hier nicht tiefer ein).

    Aber wie bekommt man seine Variablen aus dem Typoscript und dem Haupttemplate nun in das entsprechende Partial? Hierfür bietet der Viewhelper das arguments-Attribut. So kann man mit dem folgenden Beispiel-Code alle Variablen an das Partial „menu“ übergeben:

     
    <f:render partial="menu" arguments="{_all}" />