TYPO3 Formhandler Mailkonfiguration

Vielleicht habt ihr euch auch schon einmal gefragt, warum Mails welche über Formhandler verschickt werden nicht mit den normalen Mail Einstellungen von TYPO3 verschickt werden. Die Einstellungen die in dem Konfigurationsarray

$TYPO3_CONF_VARS['MAIL']

vorgenommen werden scheinen keine Wirkung zu haben.

Formhandler verschickt standardmäßig Mails mit der Klasse Mailer_HtmlMail. Diese Klasse verschickt Mails direkt mit der Mail Funktion von PHP. Möchte man E-Mails vom Webserver nun mittels SMTP verschicken, so müssen als erstes die Mail Einstellungen im Installtool oder alternativ direkt in der Datei LocalConfiguration.php geändert werden.

Nachdem diese Einstellungen geändert wurden und der Test Mail Versand erfolgreich durchgeführt wurde muss die Konfiguration des Formhandler Finisher angepasst werden.

Dazu muss dem Finisher_Mail die Konfiguration

mailer {
    class = Mailer_TYPO3Mailer
}

hinzugefügt werden. Danach werden Mails vom Formhandler über die Mailer Klasse von TYPO3 verschickt. Dadurch haben die Einstellungen im TYPO3 Installtool Wirkung.

Continuous Deployment mit TYPO3 Surf Step by Step

Als Ergänzung zu dem bereits veröffentlichten Artikel Deployment mit TYPO3.Surf ist dieser Artikel zu verstehen. Es geht hauptsächlich um den grundsätzlichen Systemaufbau. Automatisches Deployment wird immer beliebter. Das hängt zum einen damit zusammen, dass die Tools einfacher werden und die Abhängigkeiten die eine Webapplikation mitbringt steigen. Im PHP Umfeld leistet composer (https://getcomposer.org) als Dependency Manager großartige Arbeit. Composer reicht allerdings in manchen Fällen nicht aus um eine Applikation auf dem Server zu aktualisieren, da evtl. noch ein Cache gelöscht werden soll oder die Datenbank aktualisiert werden muss.

Bei der Verwendung von TYPO3 Applikationen, egal ob Neos oder Flow habe ich bereits gute Erfahrungen mit TYPO3.Surf gemacht. Für TYPO3 CMS habe ich TYPO3.Surf noch nicht eingesetzt, jedoch sollte auch das möglich sein.

Aufbau der Systemumgebung

Ich entwickele lokal auf dem MacBook. Ich habe ebenfalls lokal einen Webserver sowie eine Datenbank installiert. Das könnte z.B. XAMPP sein. Der Quellcode liegt in einem GIT Repository. Daneben habe ich einen Testserver welcher aus dem Internet erreichbar ist. Das ist zur Zeit eine virtuelle Maschine auf einem zweiten Rechner der hier im Büro steht. In der Fritz Box sowie in Virtualbox habe ich die Ports so weitergeleitet, dass man von außen auf die virtuelle Maschine kommt. Damit ich nicht alle 24 Stunden eine neue IP Adresse herausgeben muss habe ich außerdem einen DynDNS Service genutzt. Meine Fritz Box ist so konfiguriert, dass diese den DynDNS Service über neue IP Adressen informiert.

In der virtuellen Maschine habe ich einen Apache Webserver installiert und konfiguriert. Außerdem ist dort eine Datenbank installiert. Die notwendigen Abhängigkeiten die meine Applikation noch mitbringen habe ich dort ebenfalls von Hand installiert. Da ich nicht eine zweite virtuelle Maschine dauerhaft auf dem Server laufen lassen wollte habe ich zusätzlich noch TeamCity installiert.

TeamCity ist ein Continuous Integration Server von Jetbrains. Auf die Konfiguration und genauen Funktionen von TeamCity werde ich in einem gesonderten Artikel eingehen.

TYPO3.Surf ist ebenfalls auf dem Server installiert. Dazu habe ich in einem Ordner der nicht aus dem Internet erreichbar ist ein TYPO3 Flow installiert. Die genauen Schritte hierzu habe ich in dem Artikel Deployment mit TYPO3.Surf beschrieben. Die Installation von TYPO3.Surf liegt also in meinem Fall auf dem selben Server wie die Webseite. Dies ist jedoch nicht unbedingt erforderlich. Der Server auf dem die Webseite läuft muss lediglich von dem Deployment Server erreichbar sein. Im Idealfall liegt ein SSH Key des Deployment Servers auf dem Webserver so dass die Authentifizierung mittels Public/Private Key stattfindet.

Ablauf Deployment

Wie läuft jetzt so ein Deployment auf den Webserver ab. Ich führe einen Commit in meiner IDE aus und Pushe die Änderungen zu Bitbucket. Ich arbeite mit Bitbucket, da es dort beliebig viele private Repositorys gibt solange die Teams nicht zu groß werden.

Der TeamCity Server ist so konfiguriert, dass er bei Änderungen im GIT ein Deployment ausführt. Ein Deployment heißt in diesem Fall, dass ein Shell Skript ausgeführt wird. Der Inhalt des Shell Skriptes ist der folgenden:

cd /home/smeier/surf
./flow surf:deploy mein-deployment

Es wird also in dem Verzeichnis gewechselt in dem das Deployment TYPO3 Flow installiert ist. In diesem Verzeichnis wird das Deployment durchgeführt. Dabei wird automatisch die Datenbank aktualisiert und der Cache gelöscht und beliebige weitere Dinge geändert die noch in der Deployment Config von TYPO3.Surf geändert werden.

Der Einsatz von TeamCity hat den Vorteil, dass ich noch weitere automatischen Tasks vor dem eigentlichen Deployment durchführen kann. Das können z.B. automatisierte Tests oder Code Analysen sein. Wie das genau funktioniert und was sonst noch alles möglich ist, werde ich in einem späteren Artikel beschreiben. Da stehe ich teilweise auch noch am Anfang und muss das selber erst einmal genau verstehen.

 

Formhandler richtig konfigurieren

Grundkonfiguration

TYPO3 Formhandler ist eine sehr mächtige Formular Extension für TYPO3 CMS. Nahezu jeder denkbare Anwendungsfall ist damit zu lösen. Von Formularen die einfach nur per Mail abgeschickt werden zu Einträgen in die Datenbank bis hin zu Newsletteranmeldungen bei externen Dienstleistern wie z.B. Cleverreach ist alles möglich. Ich habe schon viele Formulare mit Formhandler realisiert und kenne das Problem, dass die Einstiegshürde bzw. Lernkurve sehr steil ist. Daher versuche ich euch hier eine kleine Hilfestellung zu geben. Ich werde parallel zu dem wie ich diese Anleitung schreibe das ganze an einer Installation nachvollziehen. Als TYPO3 Version nutze ich die 6.2.12. Diese habe ich installiert und noch nicht weiter konfiguriert.

Als erstes installiere ich die Extension Formhandler. Die aktuelle Version ist 2.0.1. Ich habe eine Root Seite erstellt und in dieser ein TypoScript Template angelegt.

Ich habe nur ein absolutes minimum an TypoScript verwendet. Da es sich hier nur um einen Versuchsaufbau und nicht um eine Webseite handelt die online gehen soll habe ich das TypoScript auf die folgenden Zeilen beschränkt:

page = PAGE
page.10 <  styles.content.get

Dies reicht dafür, dass die Inhalte der Spalte Normal ausgegeben werden.

In der Spalte Normal lege ich nun ein Plugin Element an. Als Plugin wähle ich „Formhandler“ aus.

Rufen wir jetzt das Frontend auf so wird einzig und alleine
An error has occurred!
ausgegeben.

Trotz der Meldung dass ein Fehler aufgetreten ist heißt dies jedoch, dass Formhandler korrekt installiert wurde und arbeitet. Es existiert nun lediglich noch ein Konfigurationsproblem welches wir im nächsten Schritt lösen werden.

Formhandler Konfiguration

Als nächstes legen wir eine Konfiguration für Formhandler an. Der Einfachheit halber wird das TypoScript erst einmal in das normale Template geschrieben. Mir ist bewusst, dass das massive Nachteile hat, für den ersten Demo Zweck reicht das aber erst einmal.
Das folgende TypoScript tragen wir ins Template ein:

plugin.Tx_Formhandler.settings.predef.first-form {

  # This is the title of the predefined form shown in the dropdown box in the plugin options.
  name = My first form
  
  # All form fields are prefixed with this values (e.g. disable-submit[name])
  formValuesPrefix = form
  
  #The "id" attribute of the form. Needed for autoDisableSubmitButton.
  formID = contact-form

  langFile.1 = TEXT
  langFile.1.value = {$formhandler.first-form.rootPath}/lang/lang.xml

  templateFile = TEXT
  templateFile.value = {$formhandler.first-form.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.first-form.rootPath}/html/mastertemplate.html

  # In case an error occurred, all markers ###is_error_[fieldname]### are filled with the configured value of the setting "default".
  isErrorMarker {
    default = has-error
  }

  # These wraps define how an error message looks like. The message itself is set in the lang file.
  singleErrorTemplate {
    totalWrap = |
  }
  

  # This block defines the error checks performed when the user hits submit.
  validators {
    1.class = Validator_Default
    1.config.fieldConf {
      name.errorCheck.1 = required
      email.errorCheck.1 = required
      email.errorCheck.2 = email
      message.errorCheck.1 = required  
    }
  }        

  finishers {

    # Finisher_Mail sends emails to an admin and/or the user.
    1.class = Finisher_Mail
    1.config {
      checkBinaryCrLf = message
      admin {
        templateFile = TEXT
        templateFile.value = {$formhandler.first-form.rootPath}/html/email-admin.html
        sender_email = {$formhandler.first-form.email.admin.sender_email}
        to_email = {$formhandler.first-form.email.admin.to_email}
        subject = TEXT
        subject.data = LLL:{$formhandler.first-form.rootPath}/lang/lang.xml:email_admin_subject
      }
    }

    # Finisher_Redirect will redirect the user to another page after the form was submitted successfully.
    5.class = Finisher_Redirect
    5.config {
      redirectPage = {$formhandler.first-form.disable-submit.redirectPage}
    }
  }
}

 

Diese Konfiguration basiert auf einer Beispielkonfiguration von der Seite http://examples.typo3-formhandler.com/start/ diese ist eine gute Anlaufstelle für einfache Beispiele. Ebenso kann ich die Dokumentation empfehlen.

In dem obigen TypoScript wird auf Konstanten zugegriffen. Die nachfolgende Konfiguration habe ich für die Constants eingetragen:

formhandler.first-form {

  # cat=Formhandler - First Form/basic/10; type=string; label=Root path: Path where the example was saved to.
  rootPath = fileadmin/formhandler/first-form/
  
  email {
    admin {
      # cat=Formhandler - First Form/basic/20; type=string; label=Admin email sender: Email address to use as sender address for the admin email.
      sender_email = 

      # cat=Formhandler - First Form/basic/20; type=string; label=Admin email recipient: Email address of an admin to receive the contact request.
      to_email = 
    }
  }

  # cat=Formhandler - First Form/basic/40; type=string; label=Redirect Page: Page ID to redirect after successful form submission.
  redirectPage = 
  

}

Mit dem TypoScript und den Constants ist die Konfiguration für das Formular abgeschlossen.

Im TypoScript haben wir zuerst einmal den Namen sowie das formValuePrefix, also den Namespace der übertragenen Parameter definiert. Anschließend ist die Sprachdatei, das Template sowie ein Master Template angegeben. Die Mastertemplate Datei beinhaltet Schnipsel, welche in der Templatedatei verwendet werden können. Die Templatedatei gibt vor, welche Felder in dem Formular vorhanden sind.

Anschließend gibt es noch die Konfiguration für isErrorMarker. Dieser beinhaltet den Text, welcher ausgegeben wird wenn ein Validierungsfehler aufgetreten ist. In diesem Fall füllt Formhandler ein paar Platzhalter im Template die genutzt werden können. Die Konfiguration isErrorMarker.default füllt den Platzhalter ###is_error_[fieldname]###, welcher im Template verwendet werden kann.

Die Konfiguration singleErrorTemplate definiert welcher Inhalt um die Fehlermeldungen für die einzelnen Felder gewrappt werden soll.

Der nächste größere Block im TypoScript, der validators Block beschreibt welche Validatoren ausgeführt werden sollen nachdem das Formular abgeschickt wurde. In dem Beispiel sind name, email und message Pflichtfelder. Außerdem muss das email Feld eine gültige E-Mail beinhalten.

Der letzte Block im TypoScript, finishers beschreibt was passieren soll nachdem das Formular abgeschickt wurde und die Validatoren erfolgreich durchlaufen wurden. Das ausgefüllt Formular wird per E-Mail verschickt und der Besucher anschließend auf eine Danke Seite die in den Constants eingetragen wird weitergeleitet. Diese abschließenden Konfigurationen, also die Mail und die Weiterleitung auf die Danke Seite sind im Abschnitt finishers im TypoScript konfiguriert.

Wir wechseln jetzt zurück zum Plugin. Auf dem Tab Plugin ganz unten unter Predefined forms steht in der Select Box jetzt ein weitere Eintrag zur Verfügung. Wir wählen dort „My first form“ aus.

Das Template

Die Mastertemplate Datei die in dem Beispiel verwendet wird habe ich im Anhang als Download zur Verfügung gestellt.

Das Template (step-1.html) beinhaltet den folgenden Inhalt:

<!-- ###TEMPLATE_FORM1### -->
###master_multipart-form-start_contact-form###
###master_section-start###
###master_input_ajax_name###
###master_input_ajax_email###
###master_textarea_ajax_message###
###master_section-end###
###master_section-start###
###master_submit-disable###
###master_section-end###
###master_form-end###
<!-- ###TEMPLATE_FORM1### -->

dabei gibt es einige wichtige Bereiche. Das fängt mit dem Kommentar in der ersten und der letzten Zeile an. Dieser muss immer genau so sein. Der einzige Variable Teil daran ist die nummer. Diese beschreibt bei einem mehrstufigen Formular den Step des Formulares. Die zweite sowie alle weiteren Zeilen beziehen sich auf das Master Template. Es wird jeweils ein bestimmter Teil aus dem Master Template gerendert. Die Zeile zwei rendert z.B. den folgenden Bereich der Master Template Datei

class="container">
###HIDDEN_FIELDS###

Die Zeile zwei der Template Datei beinhaltet neben dem Master Template Platzhalter als Suffix noch den String _contact-form. Dieser String finden ohne den führenden Unterstrich in den Platzhalter ###fieldname### im Mastertemplate Verwendung. Man befüllt diesen Platzhalter also damit.

Neben den Dateien für das Template (step-1.html) sowie der Datei mastertemplate.html gibt es noch die Datei email-admin.html. Diese beinhaltet das Template für die Email die durch den Finisher_Mail verschickt wird. Das Template besitzt den folgenden Inhalt:

<!-- ###TEMPLATE_EMAIL_ADMIN_PLAIN### -->
###master_email-admin-start-plain###
###master_email-line-plain_name###
###master_email-line-plain_email###
###master_email-line-plain_message###
###master_email-admin-end-plain###
<!-- ###TEMPLATE_EMAIL_ADMIN_PLAIN### -->

<!-- ###TEMPLATE_EMAIL_ADMIN_HTML### -->
###master_email-admin-start-html###
###master_email-line-html_name###
###master_email-line-html_email###
###master_email-line-html_message###
###master_email-admin-end-html###
<!-- ###TEMPLATE_EMAIL_ADMIN_HTML### -->

Hier sind auch wieder die Kommentare sehr wichtig, diese legen die einzelnen Bereiche des Templates fest. Ansonsten beinhaltet das Template eine Start sowie eine abschließende Zeile. Es wird in diesem Template ebenfalls wieder auf das Master Template zugegriffen. Der Platzhalter ###master_email-line-plain_name### ist wieder zweigeteilt zu betrachten. Zum einen wäre da der erste Teil ###master_email-line-plain, welcher den Part in der Master Template Datei beschreibt. Der zweite Teil name### wird wieder als ###fieldname### in der Master Template Datei aufgelöst. In der Master Template Datei wird mit einem kleinen Trick auf den Wert des entsprechenden Formularfeldes zugegriffen.
In der Master Template Datei steht ###value_###fieldname###### . der Platzhalter ###fieldname### entspricht für das erste Feld dem Strin „name“. Somit wird in der Template Datei der Platzhalter ###value_name### ersetzt.

Die 3 Template Dateien werden in den Ordner /fileadmin/formhandler/first-form/html gespeichert.

Localization

Es gibt noch eine Sprachdatei mit folgendem Inhalt:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
	<meta type="array">
		<description>Language labels for first-Form</description>
	</meta>
	<data type="array">
		<languageKey index="default" type="array">
			<label index="label_fieldset">First Form</label>
			<label index="name">Name:</label>
			<label index="email">E-Mail:</label>
			<label index="message">Your Message:</label>
			<label index="captcha">Captcha - SPAM Protection</label>
			<label index="submit">Send</label>
			<label index="greetings">Dear</label>
			<label index="email_user_subject">Your contact request</label>
			<label index="email_user_text">We have received your request via the contact form on www.example.org. We will process your request and get in contact with you soon.</label>
			<label index="email_user_footer">---------------------------------- This message was created automatically. --------------------------------</label>
 
			<label index="email_admin_subject">Contact request</label>
			<label index="email_admin_text">A user filled out the contact form on www.example.org.</label>
			<label index="email_admin_footer">---------------------------------- This message was created automatically. --------------------------------</label>
 
			<label index="error_name_required">Please enter your name!</label>
			<label index="error_email_required">Please enter your email address!</label>
			<label index="error_email_email">Please enter a valid email address!</label>
			<label index="error_message_required">Please enter a message!</label>
		</languageKey>
	</data>
</T3locallang>

Interessant sind an dieser Datei die letzten 4 Zeilen. Für jede Validator Konfiguration sollte ein entsprechendes label angelegt werden. Der index des Labels setzt sich dabei wie folgt zusammen. Als erstes der String error, gefolgt von dem Namen des Feldes, also z.B. name. Abschließend wird der entsprechende Validator angefügt. Als komplettes Beispiel z.B. error_name_required. Die lang.xml Datei wird in dem Ordner fileadmin/formhandler/first-form/lang/ gespeichert. Mit dieser Konfiguration sollte das Formular nun im Frontend angezeigt werden.

Fragen

Solltet ihr noch Fragen haben oder sollte das bei euch nicht funktionieren, so hinterlasst mir eine Nachricht. In einem späteren Artikel werde ich euch beschreiben wie ihr die eingegebenen Daten in der Datenbank speichert.

Schöne URLs mit TYPO3 Neos

Heute schreibe ich darüber, wie man bei der Verwendung von Plugins mit eigenen Daten schöne und sprechende URLs erzeugen kann. Ein Plugin in TYPO3 Neos ist nichts anderes, als ein TYPO3 Flow Paket. In der offiziellen Dokumentation ist beschrieben, wie man ein Plugin anlegt und in Neos verfügbar macht (http://docs.typo3.org/neos/TYPO3NeosDocumentation/IntegratorGuide/CreatingAPlugin.html). Nachdem man das Plugin so konfiguriert hat steht dieses unter den verfügbaren Inhaltselementen zur Verfügung. Außerdem kann man über das Inhaltselement PluginView die Anzeige der Detail Ansicht etc. auf eine andere Seite verlegt werden. Dazu muss auf dieser anderen Seite lediglich ein Plugin View Inhaltselement eingebunden und konfiguriert werden. Wenn das alles so fertig eingerichtet ist können wir uns die Seite bereits ansehen und von der Listenansicht zu einer Einzelansicht wechseln. Bei der Einzelansicht besteht allerdings bezüglich der URLs noch Optimierungsbedarf. Die im Moment ausgespielten Detail URLs beinhalten etwas in der Art:

 

?--vendor_sitename-pluginname[@package]=package.name
&--vendor_sitename-pluginname[@controller]=standard
&--vendor_sitename-pluginname[@action]=detail
&--vendor_sitename-pluginname[object][__identity]=3084731f-869f-43a3-56c3-9156f24baad5

Diese GET Parameter benötigt TYPO3 Neos um das richtige Plugin zu rendern. Es ist jedoch nicht notwendig, dass diese alle in der URL übergeben werden. In der Datei Routes.yaml kann man einstellen wie URLs in dem Fall generiert werden sollen. Für obige Parameter könnte man beispielsweise die folgende Konfiguration vornehmen:

-
  name: 'Detail Route'
  uriPattern: '{node}/details/{--vendor_sitename-pluginname.object}.{@format}'
  defaults:
    '@package': 'TYPO3.Neos'
    '@controller': 'Frontend\Node'
    '@format': 'html'
    '@action': 'show'
    '--vender_sitename-pluginname':
      '@package': 'Package.Name'
      '@controller': 'Standard'
      '@action': 'detail'
      '@format': 'html'
  routeParts:
    node:
      handler:    TYPO3\Neos\Routing\FrontendNodeRoutePartHandler
    '--vendor_sitename-pluginname.object':
      objectType: '\Package\Name\Domain\Model\Object'
      uriPattern: '{property}'
  appendExceedingArguments: TRUE

Die obige Regel führt dazu, dass nur noch die Property in der URL ausgegeben wird. Es wird also eine URL in der Art

http://{domain}/{node}/detail/property.html

erzeugt und nicht wie vorher:

http://{domain}/{node}?--vendor_sitename-pluginname[@package]=package.name
&--vendor_sitename-pluginname[@controller]=standard
&--vendor_sitename-pluginname[@action]=detail
&--vendor_sitename-pluginname[object][__identity]=3084731f-869f-43a3-56c3-9156f24baad5

Die neuen URLs sind für Besucher viel einfacher zu lesen und auch für Google sind diese besser, da in der URL noch einmal ein Keyword untergebracht ist.

War dieser Artikel verständlich? Habt ihr Fragen oder sollte ich das ganze detaillierter beschreiben dann meldet euch einfach, Entweder über einen Kommentar unter diesem Beitrag, über das Kontaktformular oder per E-Mail.

TYPO3 Neos vs. TYPO3 CMS

Was sind die Unterschiede zwischen Neos und CMS. Beides sind Produkte unter dem Label TYPO3. Ursprünglich war der Plan, dass Neos nach Fertigstellung das CMS ablösen sollte. Dieser Plan ist gescheitert und beide Produkte werden nach wie vor noch weiter entwickelt. Zum aktuellen Zeitpunkt ist die Oberfläche von Neos beeindruckender und intuitiver für Redakteure zu bedienen.

Aus der offiziellen Demo von TYPO3 Neos stammt der folgende Screenshot.Bildschirmfoto 2015-05-03 um 20.57.37

zum Vergleich dazu hier ein Screenshot aus der Version 7.1 vom TYPO3 CMS.Bildschirmfoto 2015-05-03 um 21.00.16
Beide Demo Versionen sind über http://demo.typo3.org erreichbar.
Leicht zu erkennen ist, dass man bei Neos das Frontend sieht und die Backend Elemente nur darüber gelegt sind. Auch das bearbeiten von Inhalten erfolgt direkt im Front/Backend. Die neue Version von TYPO3 CMS erinnert immer noch stark an die vorherigen Versionen, auch wenn das Backend deutlich moderner aussieht.

Die Hürde sich in Neos einzuarbeiten sollte man als Entwickler jedoch nicht unterschätzen. Gerade wenn es etwas anspruchsvollere Aufgaben zu meistern gilt als nur Inhalt anzuzeigen kann es mit viel ausprobieren verbunden sein bis die richtige Lösung gefunden wird. Hilfreich ist es sicherlich wenn man sich vorher schon einmal mit TYPO3 Flow beschäftigt hat, das Framework auf dem TYPO3 Neos basiert.

TYPO3 CMS kann auf eine Vielzahl an Plugins, sowie den Extension Manager, zur einfachen Installation verweisen. Dagegen gibt es im Neos Projekt keinen Extensionmanager. Eventuelle Plugins bzw. Erweiterungen müssen als abhängige Pakete in der composer.json hinterlegt und über composer installiert werden. Viele Funktionen für die man unter TYPO3 CMS ein Plugin benötigt kann man in Neos jedoch von Haus aus realisieren. Ich habe gerade in einer Installation von TYPO3 CMS nachgesehen und die Extensions:

  • Formhandler
  • Realurl
  • Gridelements

werden neben einigen Kundenspezifischen Extensions dort genutzt. Ich denke viel mehr Erweiterungen habt ihr auch nicht im Einsatz. Ich vergleiche das jetzt einmal und schaue wie ich diese Dinge mit Neos realisieren würde. Schöne URLs liefert Neos von Haus aus und auch für die Darstellung von externen Daten besteht die Möglichkeit schöne URLs zu erzeugen. Formulare kann Neos auch mehr oder weniger von sich aus. Dazu wird das Paket TYPO3.Form verwendet, welches in einer Standardinstallation automatisch mit installiert wird. Bleibt Gridelements als Extension, auch diese Funktion kann man mit Neos ohne eigenes Plugin realisieren. Dazu muss nur ein entsprechender NodeType konfiguriert werden, welcher entsprechend weitere ChildNodes konfiguriert hat. Die Funktion für die ich bei TYPO3 CMS noch Plugins benötigte sind bei Neos von Haus aus dabei.

Die Entscheidung TYPO3 Neos oder TYPO3 CMS kann man immer nur selber treffen, jedoch ist Neos meiner Meinung nach inzwischen so weit, dass es sich definitiv lohnt einen Blick darauf zu werfen. Ich werde in den nächsten Tagen und Wochen weitere Artikel veröffentlichen die sich mit dem ein oder anderen Problem bei Neos oder auch bei CMS beschäftigt.

Deployment mit TYPO3.Surf

Ich habe mich in den letzten Wochen mit den Einstellungen und der Konfiguration von TYPO3.Surf beschäftigt. Geplant war schon viel eher ein weitere Artikel in dieser Reihe, jedoch ist durch einen Umzug und weitere Projekte einfach nicht die Zeit dazu vorhanden gewesen. Aber nun geht los. Step by Step Continous Deployment mit TYPO3.Surf.

Als erstes benötigen wir eine frische Installation von TYPO3.Flow. Eine Installationsanleitung habe ich hier niedergeschrieben: TYPO3.Flow installieren

In diese Installation installieren wir als nächstes TYPO3.Surf. „Deployment mit TYPO3.Surf“ weiterlesen

Typoscript subtitle als Seiten Titel anzeigen

Will man bei Typo3 den Standard Title ausschalten und stattdessen den Title individuell erstellen so ist dieses mit ein bisschen Typoscript möglich.

Der folgende Typoscript Block schaltet den Standard Title aus und nimmt stattdessen den sutitle aus dem Backend  für den Title Tag auf der Webseite.

config.noPageTitle = 2
#der Standard Title wird ausgeschaltet
page {
# Das Feld Subtitle wird auf der Webseite in dem
# Headerbereich ausgegeben und von umschlossen
headerData.6 = TEXT
# Nutze das Feld subtitle alternativ das Feld title sollte subtitle leer sein
headerData.6.field = subtitle // title
headerData.6.wrap = <title>|</title>
}

Typo3 4.6 Kontaktformular

Mit der Version 4.6 hielt bei Typo3 ein neuer Formular Editor Einzug. Dieser Wysiwyg Editor lässt sich nach kurzer Eingewöhnungsphase intuitiv bedienen. Im Backend kann man sehr gut nachvollziehen wie das Formular später aussehen wird. Doch nach dem Aufrufen des Frontends wird dort nur:

###LABEL### ###FIELD###

angezeigt. Wenn dieser Fehler auftritt muss nur das Static Template Default TS (form) eingebunden werden.