Das neue Jahr hat begonnen und auch wir starten wieder durch.
Wir hoffen, dass Sie die Weihnachtstage genossen haben und gut ins neue Jahr gekommen sind.
Auch 2013 sind wir natürlich wieder für sie da und freuen uns auf spannende Projekte!

In diesem Sinne: Einen guten und erfolgreichen Start ins neue Jahr!

Ich möchte die Gelegenheit nutzen um mich kurz vorzustellen, ich bin Christoph Lehmann, 28 Jahre jung und komme aus Kiel.

Vor meiner herzlichen Aufnahme im networkteam habe ich eine Lehre zum Elektro-Installateur und  anschließend zum Fachinformatiker mit Fachrichtung Systemintegration absolviert.

Nunmehr seit 5 einhalb Jahren bin ich als Server- und Netzwerkadministrator tätig. Meine Ausbildung bei einem kleinen Internet Service Provider macht mich zum Allrounder und somit zur perfekten Ergänzung dieses Unternehmens. Abseits meiner administrativen Tätigkeiten bin ich Frontend-Entwickler für TYPO3 und habe schon die ein oder andere Erweiterung geschrieben.

Ich freue mich weiterhin auf eine schöne Zusammenarbeit mit Ihnen und dem Team.

Over and out!

Weitere neue Features und Verbesserungen im Überblick:

• Das Design des Seiten-Moduls und der Inhaltselemente wurde angepasst und mit Drag & Drop Funktionalität benutzerfreundlicher gestaltet. 
• Neuer Login Screen
• System Notizen wurden neu gestaltet
• Layout & Usebility Verbesserungen im Backend
• Doc-Header überarbeitet (Horizontale Zeile im oben Bereich des Backends mit Funktionen wie etwa "Speichern, Schließen, ausloggen usw.)
• Menü/Sitemap wurde umbenannt in "Spezial Menüs"
• Seitenbaumbereiche lassen sich via TSconfig einfärben
• Neues Spezial Menü: Sitemap of selected pages 
• Neue Typoscript Möglichkeiten (u.A. stdwrap.ifNull, Mehrfachwerte in Conditions, Wegfall des HTML Objektes)
• Neue TSconfig Möglichkeiten (u.A. readonly für beliebige Backend Felder, anstelle sie auszublenden)
• Überarbeitung der Sytem Konfiguration: localconf.php wird von LocalConfiguration.php  und AdditionalConfiguration.php abgelöst
• jQuery wird standardmäßig mitgeliefert und kann über page.javaScriptLibs auf diverse Art und Weise eingebunden werden (z.B. via CDN)
• Aktualisierung und Verbesserung des Caching Frameworks
• Refacturing des Bootstraps (Initialisierungscode wurde völlig überarbeitet)
• Bessere Codequalität mit deutlich mehr (über 5000 automatisierten) Unit-Tests durch Quality Assurance Guidelines

Dank Sensiolabs Deutschland gibt es die SymfonyLive Veranstaltungsreihe nun auch in Deutschland. In einer Umgebauten Kirchenruine im Ostteil Berlins gelegen, ist die Stimmung wie gewohnt von Anfang an ausgelassen.

Die Talks lesen sich schon in der Vorschau gut und mit Benjamin Eberlei, einem Core-Developer von Doctrine geht es auch entsprechend los. Sein Vortrag über die Neuerungen in Doctrine seit der Version 2.1 weckt das Interesse sich genauer mit dem Thema auseinander zu setzen. Insbesondere das Thema Filter API und Collection Criteria sind interessant. Die Filter API ermöglicht es Informationen aus z.B. dem Request automatisch in jede Query mit aufzunehmen. So ist es möglich die Sprache aus dem Request als Filter auf die Query anzuwenden oder aus der Session eine Kundennummer zum Filtern der Einträge zu verwenden.

Das Collection Criteria ermöglicht es auf einem Ergebnis einer Abfrage eine weitere Abfrage mittels eines Criterias zu definieren. Dies wird je nach Situation in SQL Umgewandelt und direkt aus der Datenbank gelesen oder als Filter auf den vorhandenen Daten angewandt.

Hugo Hamon, Head of Training von Sensiolabs Frankreich hat einen Talk über die Serializer Komponente von Symfony gehalten. Ein Thema bei dem ich Anfangs dachte das es recht trocken und wenig interessant wird, ich mich aber innerhalb kürzester Zeit eines besseren belehren lassen musst. In dem Vortrag ging es auch um die Möglichkeiten mittels der Komponente JSON und XML Schnittstellen zu realisieren und wie diese mit einfachen Mitteln auch versioniert werden können. Im Konkreten Beispiel wurde die Versionierung über den Accept-Header realisiert, was es erlaubt unterschiedliche Versionen der API auf dem selben Endpoint zu betreiben.

Im Zusammenhang damit wurde auch das JMSSerialzerBundle erwähnt, welches einem bei diesen Aufgaben gute Unterstützung zur Verfügung stellt. Interessant ist in diesem Bundle auch das Twig Plugin, welches es einem ermöglicht innerhalb eines Templates Informationen zu serialisieren, um diese z.B. per Ajax an den Server weiterzureichen.

https://speakerdeck.com/hhamon/introduction-to-serialization-with-symfony2

Einen lockeren und sehr Aufschlussreichen Talks hat Fabrice Bernhard über die Modernisierung von Legacy Anwendungen gehalten. Im Kern ging es um die Portierung von alten Anwendungen in modernere Strukturen und Optimierung der Wartbarkeit des Codes. Interessant war hier auch was unter Legacy Verstanden wird. Dabei handelt es sich um Anwendungen die unter PHP 5.0 und symfony 1 laufen. in meinen Augen nicht wirklich Legacy, aber die Tipps und Ideen wie man an solch eine Aufgabe heran geht sind die gleichen wie für noch ältere Anwendungen. Hier wurde auch auf die Problematik eingegangen, den Entscheidern diesen komplexen und aufwändigen Schritt schmackhaft zu machen. Denn bei den Verantwortlichen wird häufig das Problem nicht gesehen, welches entsteht, wenn die Codebasis nicht auf einen sauberen Stand gebracht wird. Das Zitat dazu war:

Before the big eat the small, nowadays the fast eat the slow ...

Ein sehr gutes Argument, wie ich finde.

http://de.slideshare.net/fabrice.bernhard/modernisation-of-legacy-php-applications

Ein weiterer Bemerkenswerter Vortrag kam von Bernhard Schussek dem Entwickler des Form-Frameworks in Symfony2. Mit seiner Ansage, dass er alle Zuhörer in 30 Minuten zum Form Master machen will, hat er sich auch nicht zu weit aus dem Fenster gelehnt: sein Vortrag war kurzweilig und sehr informativ.

https://speakerdeck.com/bschussek/symfony2-form-tricks

Am Folgenden Tag gab es an anderer Stelle (mit einem viel zu schwachen W-Lan) den Hackday. Es kamen mehr Leute als erwartet und so war es recht gemütlich. Nach längerer Zeit habe ich die Chance genutzt und mich um die offenen Pull-Requests des Stomp Clients gekümmert und auch gleich noch eine Einbindung in Travis-CI vorgenommen.

Es war eine schöne Konferenz mit interessanten Talks und ebenso interessanten Leuten. Vielen Dank ans networkteam!

Symfony ist ähnlich wie TYPO3 Flow ein Application Framework welches die Entwicklung von Webanwendungen erleichtert und für viele Anwendungsfälle vorgefertigte Komponenten zur Verfügung stellt.

Die TYPO3-Extension powermail ist sehr mächtig und wir nutzen diese bei fast jedem Projekt, damit unsere Kunden aufwändige Email-Formulare selbständig bearbeiten und aufbauen können. Es gibt diese Erweiterung bereits in der Version 2.x - bei den meisten TYPO3-Installationen nutzen wir aber oft noch die Vorgänger-Version, da diese derzeit vom Funktionsumfang noch deutlich mehr bietet.

Immer wieder gibt es besondere Anforderungen auf Seiten des Kunden, die mit der standardmäßigen Konfiguration nicht einfach umzusetzen sind. In diesem Blogeintrag zeige ich ein paar sinnvolle Snippets, die uns das Leben einfacher gemacht haben.

Absolute Links aus dem RTE-Text in Emails generieren

Standardmäßig werden interne Links in TYPO3 relativ gesetzt und dabei die aktuelle Domain weggelassen. Da beim Versenden von Emails die gleiche Logik verwendet wird, lassen sich diese relativen Links nicht im Email-Client aufrufen, da in diesem Kontext die jeweilige Domain fehlt. Über eine TypoScript-Einstellung lässt sich dieses aber beheben. Es wird per Condition abgefangen, ob auf der aktuellen Seite das Powermail Plugin eingebunden ist, was über die mitgelieferte User-Funktion einfach erkannt werden kann. Dann werden automatisch alle Links in dem RTE mit der Domain vervollständigt, so dass diese in den Emails problemlos angeklickt werden können, auch wenn es sich dabei um interne Verlinkungen handelt:

Styling der Emails

Möchte man komplett auf das Styling der Email verzichten und diese nicht als HTML-Version sondern als reinen Plaintext versenden, kann man dies über die Konstante

plugin.powermail.emailformat.recipient_mail = plain

erreichen, um diese z.B. durch ein Ticketsystem automatisch importieren zu können. Meistens möchte man jedoch das Aussehen der Email an das Corporate Design der Firma anpassen. Dies kann man über eigene Templates erreichen. Die beiden Dateien die dafür anzupassen sind lauten:

plugin.tx_powermail_pi1 {
  template.emails = fileadmin/templates/powermail/tmpl_emails.html?
  template.all = fileadmin/templates/powermail/tmpl_all.html
}

Da in einer HTML-Email keine externen CSS-Dateien geladen werden können, müssen die Styling-Angaben, wie in einem Newsletter, inline über das style-Attribut erfolgen. Um dies zu vereinfachen und zentral zu definieren, können in den Templates am besten Platzhalter verwendet werden, die beliebig benannt sein können. Zum Beispiel:

<!-- ###POWERMAIL_ALL### begin -->
  <table class="powermail_all" style="###POWERMAIL_TYPOSCRIPT_STYLE_TABLE###">
    <!-- ###CONTENT### --><!-- ###ITEM### -->
      <tr class="powermail_all_tr powermail_all_tr_###POWERMAIL_UID###">
        <td style="###POWERMAIL_TYPOSCRIPT_STYLE_TABLE_TH###" class="powermail_all_td powermail_all_label powermail_all_td_###POWERMAIL_UID###" valign="top">###POWERMAIL_LABEL###</td>
        <td style="###POWERMAIL_TYPOSCRIPT_STYLE_TABLE_TD###" class="powermail_all_td powermail_all_value powermail_all_td_###POWERMAIL_UID###" valign="top">###POWERMAIL_VALUE###</td>
      </tr>
    <!-- ###ITEM### --><!-- ###CONTENT### -->
  </table>
<!-- ###POWERMAIL_ALL### end -->

Die Werte der Styling-Attribute definiert man dann einfach in einem TypoScript-Template über das dynamicTyposcript von Powermail:

plugin.tx_powermail_pi1 {
  dynamicTyposcript {
    STYLE_TABLE = TEXT
    STYLE_TABLE.value = font-family:Verdana,sans-serif;border-collapse:collapse;border:1px solid #5EC5D6;width:100%
    STYLE_TABLE_TD = TEXT
    STYLE_TABLE_TD.value = border-bottom:1px solid #5EC5D6;padding:5px 10px 5px 10px
    STYLE_TABLE_TH < .STYLE_TABLE_TD
    STYLE_TABLE_TH.wrap = |;font-weight:bold;color:#0085BC?
    STYLE_TEXT = TEXT
    STYLE_TEXT.value = font-size:10.0pt;font-family:Verdana,sans-serif;color:black
  }
}

So kann man den Marker ###POWERMAIL_ALL### in den RTE-Texten weiterhin verwenden. Die dadurch generierte Tabelle wird dann in den gewünschten Farben / Aussehen in der Email platziert. Leider werden dabei alle Formularwerte in einer Tabelle generiert und können nicht getrennt oder unterschiedlich von einander dargestellt werden.

Aber auch dies ist mit den oben definierten Style-Markern möglich, in dem man sich im RTE das Formular individuell zusammenstellt und dabei auf die gleichen Werte zugreift:

<table style="###POWERMAIL_TYPOSCRIPT_STYLE_TABLE###">
 <tbody>
  <tr>
   <td style="###POWERMAIL_TYPOSCRIPT_STYLE_TABLE_TH###">Firma</td>
   <td style="###POWERMAIL_TYPOSCRIPT_STYLE_TABLE_TD###">###UID4###</td>
  </tr>
 </tbody>
</table>

Damit kann die Email individuell im RTE zusammen gestellt werden. Als Platzhalter wird dann direkt auf das jeweilige Feld z.B. ###UID4### zugegriffen.

Kopf- und Fußzeile in der Email

Möchte man die Werte aus dem Formular immer mit einer festen Kopf- und/oder Kopfzeile versehen, empfiehlt es sich diese Inhalte nicht in jedem Formular einzeln zu pflegen, sondern global in dem Email-Template von Powermail zu hinterlegen. So wird sicher gestellt, dass dieser Inhalt in allen verschickten Emails - egal aus welchem Formular dieser generiert wurde - identisch aussieht.

Bestimmte Felder in dem Email-Marker „###POWERMAIL_ALL###“ entfernen

Es ist bereits über die Konstante „plugin.powermail.markerALL.notIn“ möglich einzelne Felder aus dem Marker zu entfernen, so dass diese nicht in Emails übertragen werden. Der große Nachteil ist dann aber, dass dieser immer komplett entfernt wird - unabhängig davon ob es sich um die Bestätigungsseite oder die Email an den Sender / Empfänger handelt.

Möchte man jedoch nur bestimmte Werte z.B. aus der Bestätigungs-Email an den Absender entfernen, hilft der folgende TypoScript Code:

Die Werte der entsprechenden Felder werden einfach mit leerem Inhalt überschrieben, so dass diese beim Versand der Email komplett ignoriert werden und daher nicht einmal das Label des Feldes in der Email erscheint. Die jeweiligen Felder lassen sich gut über Konstanten definieren, damit man pro Email-Formular in der TYPO3-Installation verschiedene Felder definieren kann.

Zwei Powermailfelder in einer Zeile zusammenführen

Über CSS-Styling ist es möglich zwei Felder wie z.B. Vor- und Nachname in einer Zeile zusammen anzuzeigen und dann auch nur ein gemeinsames Label dafür zu verwenden. Dabei entsteht aber das Problem, dass auf der Bestätigungsseite, den Emails oder auch der Danke-Seite wo der ###POWERMAIL_ALL### Marker verwendet wird, fälschlicherweise das gemeinsam genutzte Label z.b. "Vor- und Nachname" mit dem Wert des Vornamens und darunter noch einmal das Label "Nachname" mit dem Wert des Nachnamens ausgegeben wird. Um diese Unschönheit zu beheben dient dieses dynamisch nutzbare Snipped:

plugin.tx_powermail_pi1 {
  markerALL.notIn = ###UID{$powermail.merge.field02}###
  mode {
    confirmation {
      uid{$powermail.merge.field01} = TEXT
      uid{$powermail.merge.field01}.value = {field:uid{$powermail.merge.field01}} {field:uid{$powermail.merge.field02}}
      uid{$powermail.merge.field01}.insertData = 1
    }
    recipient_mail.uid{$powermail.merge.field01} < .confirmation.uid{$powermail.merge.field01}
    sender_mail.uid{$powermail.merge.field01} < .confirmation.uid{$powermail.merge.field01}
    thx.uid{$powermail.merge.field01} < .confirmation.uid{$powermail.merge.field01}
  }
}

Hierbei wird das zweite Feld komplett aus dem markerALL entfernt und anstelle dessen der übermittelte Wert mit an das erste Feld gehängt. Über die beiden Konstanten können dann pro Formular die IDs der beiden Felder gesetzt werden:

powermail.merge.field01 =
powermail.merge.field02 =