Powermail Absendername und Absenderemail eintragen

 

 

Wenn kein Absendername definiert ist, setzt powermail sich selbst automatisch als Absendername. Die meisten Webseitenbetreiber möchten jedoch lieber ihren eigenen Namen als Absender eintragen. Wenn man eine Mail and den Absender schickt, dann ist standardmäßig dieser auch der Absender an die Adresse des Empfängers. Dieses Verhalten lässt sich per TypoScript im Setup überschreiben:

plugin.tx_powermail_pi1.email {

  recipient_mail.sender {

    name.value = Mein Verein e.v.

    email >

    email = TEXT

    email.value = noreply@beispiel.com

  }

  sender_mail.sender {

    name.value = Mein Verein e.v.

    email >

    email = TEXT

    email.value = noreply@beispiel.com

  }

}

Powermail Feld mit Daten aus FE-User vorbelegen

 

 

Bei Powermail lassen sich Felder relativ leicht mit Daten aus dem aktuell angemeldeten Fe_user vorbelegen. Dazu muss man einfach nur bei der Bearbeitung des Formularfeldes ganz unten unter “Zusätzliche Einstellungen” bei “Dieses Feld mit Daten aus der fe_user füllen” den Wert des FE Users angeben (z.B. Name oder Adresse), der angezeigt werden soll.

Was aber, wenn man einen Wert des Fe-Users verwenden möchte, der noch nicht in der List auftaucht? Zum Beispiel den Skypenamen der Erweiterung mm_forum?

Dazu muss man das TCA ändern, also die Datei typo3conf/extTables.php editieren und dort ganz unten (oberhalb des schließenden ?>) folgendes eintragen:

$TCA[‘tx_powermail_fields’][‘columns’][‘fe_field’][‘config’][‘items’][1][0] = ‘Skype Name’;
$TCA[‘tx_powermail_fields’][‘columns’][‘fe_field’][‘config’][‘items’][1][1] = ‘tx_mmforum_skype’;

Danach den gesamten Cache leeren.

Vorsicht, wenn man in dieser Datei einen Syntaxfehler macht, lässt sich das Backend nicht mehr öffnen. In dem Fall den Fehler beheben und dann den BE-Cache manuel löschen, in dem man im Verzeichnis typo3conf alle Dateien löscht, die mit temp_CACHED_ beginnen.

Übersichtliche Recordlisten durch Benutzerdefinierte Queries im TYPO3 Backend erstellen

 

In großen Enterprise TYPO3 Projekten ist es für die Redakteure zum Teil nicht ganz leicht bestimmte Datensätze “manuel” zu finden. Auch die TYPO3 Backendsuche ist hier Teils nicht spezifisch genug. Hier empfielt es sich mit benutzerdefinierten Backen Queries zu arbeiten. Diese lassen sich mit dem Admin Tool “DB-Überprüfung” erzeugen und als Action in den “Aufgaben” bestimmten Backend Benutzern oder Benutzergruppen freigenen.

So noch nicht geschehen muss zunächst die Systemextension “sys_action” installiert werden.  Dann in den Aufgaben (Task Center) auf Befehl (Action) klicken (Bild 1) und eine neue Action vom Typ “SQL Query” erzeugen. Den Befehl bennen, ich nenne ihn “Powermail Formulare” (Bild 2).

Dann erzeugt man den Query. Dazu in DB-Überprüfung auf “Full Search” und hier auf “Advanced Query” und “Select Records” einstellen. Nun lassen sich die Tabelle der Records und verschiedene Sucheinstellungen erstellen. (Bild 3) Man sollte nicht vergessen, die Benutzergruppen, die diesen Query sehen dürfen, auszuwählen.

Nun muss man den Query in die Action speichern, in dem man beim Speichern-Feld den Namen der soeben erzeugten Action auswählt.

Nun können alle Backendbenutzer, die das Taskcenter (Aufgaben) angezeigt bekommen und zu einer der in Schritt 2 ausgewählten Benutzergruppen gehören den Query aufrufen und (in diesem Fall) alle Powermail Content Elemente angzeigt bekommen und diese Editieren.

Ps: Datenbankfeldernamen werden aufgrund der Extension lo_backendhelper angezeigt. Dies ist leider kein TYPO3 Standart.

Dynamisches CSS für dynamische Header und Seitenfarben

 

 

Dynamisches CSS muss bei TYPO3 Version 4.5 nicht mehr unter Nutzung des &type=xx Typenkonzepts erzeugt werden. Deswegen wurde dieser Artikel komplett überarbeitet.

Stattdessen lässt sich das inline CSS des Page Objektes nutzen. Dieses wird automatisch in eine Datei ausgelagert.

CSS dynamisch generieren

page.cssInline {
10 = TEXT
10 {
value =  body {background: red;}
}
}

Headerbild dynamisch einbinden

Möchte man nun Headerbilder und verschiedene Seitenfarben dynamisch wechseln, so kann man den entsprechenden Code dynamisch erzeugen.  Eine Möglichkeit ist, man nutzt entweder vorhandene Felder der “page” Tabelle oder erzeugt per Extension neue Felder. Dann kann man diese Felder zur Generierung von dynamischen CSS nutzen, zum Beispiel um einen dynamischen Header zu Erzeugen.

page.cssInline {
10 = TEXT
10 {
wrap (
#header {
background-image: url(‘uploads/media/|’);
}
)
field: media
}
20 = TEXT
20 {
wrap = .color1 {color:|}
field = tx_myextension_color1
}
}

Exkurs: Data Eigenschaften Alternativwerte (//) und levelfield

Häufig möchte man jedoch nicht für jede Seite ein Headerbild definieren sondern entweder ein defaultbild angeben oder auch das Headerbild aus einer Oberseite verwenden. Dabei kann man sich eine schöne Syntax der data Eigenschaft zu eigen machen, die leider recht wenig bekannt ist. In der .data Eigenschaft lässt sich der doppelte Slash // zur Angabe von Allternativwerten nutzen.

10.data = filed:subtitle // field:title

Würde den Untertitel ausgeben und – sollte dieser leer sein – den Titel als Alternative ausgeben.

Zusätzlich gibt es eine weitere praktische data Eigenschaft: das Levelfield. MIi dem Levelfield kann man automatisch Felder der “page” Tabelle aus der Rootline auslesen. Dies funktioniert aus Performancegründen jedoch nur mit Feldern die dazu vorgesehen wurden (z.B title und media). Man kann jedoch durch einen Eintrag in der localconf.php auch weitere Felder für das levelfield vorsehen:

$TYPO3_CONF_VARS[‘FE’][‘addRootLineFields’] =
‘navtitle, media, tx_myextension_color1’;

Diese Felder lassen sich dann in der .data Eigenschaft per levelfield wie folgt abrufen

# Headerbild der Elternseite
10.data = levelfield: -1, media

# Headerbild der Seite von Level 1
20.data = levelfield: 1, media

# Headerbild in der Rootline nach oben suchen
20.data = levelfield: -1, media, slide

Um sicherzustellen, dass wenn ein Bild angegeben ist dieses auch genutzt wird nutzt man nun das Konzept der Alternativwerte in data.

Das Headerbild dynamisch in der Rootline suchen

page.cssInline {
10 = TEXT
10 {
wrap (
#header {
background-image: url(‘uploads/media/|’);
}
)
data = field:media //   levelfield: -1, media, slide
}
}

Seitentitel in TYPO3 und Suchmaschinenoptimierung

 

In TYPO3 gibt es diverse Felder, die diverse Titel einer Seite beschreiben. Leider werden diese Titel of in einer Art und weise eingesetzt, die es dem ungeübten Redakteur erschwert Suchmaschinenoptimierte Titel zu nutzen.

Titel in Webseiten und Suchmaschinenoptimierung – Begriffsklärung

Metatitel – Titel im Head Bereich zwischen <title> und </title>

Dieser Titel ist eines der wichtigsten Instrumente der Suchmaschinenoptimierung. Bei vielen Seiten lässt sich die Platzierung um so manchen Punkt erhöhen, wenn man nur diesen Titel ändert und hier Keywords nutzt.

Alias / Dateiname und Suchmaschinenoptimierung

Nutzt man RealUrl oder eine andere Extension, die statische Pfade simuliert, so bekommt jede Seite auch einen Pfad, der dem Dateinamen einer HTML Datei entspricht. Wie wichtig dieser Dateiname im Einzelnen ist, wird diskutiert, definitiv wird er aber in Google-Suchergebnissen markiert.

Titel für Menüs, Linktitel und Suchmaschinen

Auch die für Menüs verwendeten Titel spielen eine Rolle in der Suchmaschinenoptimierung, allerdings müssen diese Titel für die Besucher auch immer verständlich sein.

Hauptüberschrift der Webseite, erste oder einzige h1 Überschrift.

Auch die Inhalte einer Webseite, vor allem in Überschriften, spielen eine Rolle in der Suchmaschienoptimierung. Einige SEO Ansätze empfehlen daher pro einzelner Webseite nur eine H1-Überschrift zu nutzen, die dann die Kernaussage in suchmaschinengerechter, aber für den Besucher nützlicher weise präsentiert. Dies wäre die Hauptüberschrift der Seite.

Den Redakteur in TYPO3 korrekt die Titel pflegen lassen

Und nun kommt die entscheidende Frage: Wie bekomme ich meinen Redakteur dazu alle diese Titel korrekt zu pflegen?!?

Ich würde empfehlen, von der Standardmäßigen Verwendung der Titel in TYPO3 etwas abzuweichen:

Dort gibt es standardmäßig einen Titel (Pflichtfeld), einen Navigationstitel und einen Untertitel sowie ein Alias Feld. Wenn der Navigationstitel gesetzt ist, wird dieser im Menü genutzt, ansonsten der Tite. Der Titel wird immer als  Metattitel genutzt und eventuell auch noch als größte H1 Überschrift ausgegeben.

Der Redakteur denkt vom Menü aus und pflegt andere Titel nach

Redakteure wollen schnell ans Ziel gelangen und denken meist erst vom Menü aus. Wollen sie dann später die meist längeren Suchmaschinentitel nachpflegen, so müssen sie den bisherigen Titel in den Navtitel kopieren und dann den Metatitel ins Titelfeld eintragen. In der Standardkonfiguration sieht dann der Seitenbaum mit den bis zu 65 Zeichen langen Metatiteln ziemlich blöd aus, der Redakteur findet sich nicht mehr zu recht und gibt auf.

Der Titel der Seite sollte daher meiner Meinung nach in erster Linie im Menü angezeigt werden und für die anderen Titel nur ein Fallback sein.

Für die Pflege der Metatitel würde ich empfehlen, die Extension seo_basics zu installieren. Der in das neu erzeugte Feld eingetragene Meta-Seitentitel kann darüber hinaus auch noch in der Info-Ansicht im überblick dargestellt werden und erleichtert den Redakteuren das Nachtragen fehlender Titel.

Mit dem verändern des Alias bzw realURL Path sollte man dagegen bei Webseiten, die online sind vorsichtig sein. Am besten man lässt die Redakteure in der Data-Entry Phase diese Titel Pflegen und spricht es mit ihnen durch, nachher sollte man den Redakteuren das Feld aber am besten ausblenden, damit sie es nicht ändern.

Wenn es pro Webseite je nur einen h1 Titel geben soll, so muss man dafür sorgen, dass sonst auch keine h1 Überschriften ausgegeben werden können. Dazu sollte man den RTE entsprechend konfigurieren und dafür sorgen, dass die Überschriften der Content-Elemente als <h2> ausgegeben werden.

Mit einem sorgfältig konfigurierten Backen sollte die Suchmaschinenoptimierung den Redakteuren schon viel leichter fallen.