PS: Der RSS Feed ist auch bei uns auf der Startseite unten rechts eingebunden. Viel Spaß damit.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Und hier ein Aufruf, besonders an Agenturen und alle die interne Extension über Kundenprojekte hinweg einsetzen: Hier sollte ganz besonders wert darauf gelegt werden, dass die Extension sauber ist, weil sonst rächen sich die verkauften SEO-Zusatzpakete. Google sagt bei der Suche nach ‘inurl:tx_extensionkey_pi1′: Mehr als 640.000 Treffer … ooops (ja ich weiß, es sind nicht 640.000 Unique Kunden, aber es sind noch genügende).

Extension ist nicht im TER, sonst würd ich das hier nicht schreiben, Agentur ist informaiert, ich bin gespannt — könnten arbeitsreiche Tage werden

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Ablauf der Abmeldung
Im Formular ist nur die E-Mail Adresse anzugeben, die aus dem Newsletterverteiler entfernt werden soll. Nach dem Absenden wird die eingetragenen E-Mail Adresse zunächst validiert (Tx_Formhandler_Validator_Default (gültige E-Mail Adresse und ob sie in der Tabelle tt_address existiert)) und bei Erfolg wird in der Tabelle tt_address für den existierenden Datensatz, basierend auf der angegebenen E-Mail Adresse, das Feld hidden auf 1 gesetzt (Finisher_DB).

Alle weiteren Schritte, wie versenden von E-Mails an User und Admin, habe ich in diesem Tutorial weggelassen, da sie genau wie im Tutorial Newsletteranmeldung, umgesetzt werden können.

plugin.Tx_Formhandler.settings.predef.newsletter {
	# Common configuration
	name = Newsletterabmeldung
	addErrorAnchors = 1
	templateFile = fileadmin/templates/formhandler/newsletter_unsubscribe.html
	langFile.1 = fileadmin/templates/formhandler/newsletter_unsubscribe.xml
	cssFile.1 = fileadmin/css/my.css
	formValuesPrefix = formhandler
 
	requiredSign = TEXT
	requiredSign.value = *
	requiredSign.wrap = <span style="color: #DF9707;">|</span>
 
	#isErrorMarker.default = class="errorField"
	isErrorMarker.default =
 
	# HTML wrapping by validation error
	errorListTemplate {
		totalWrap = <div class="error">|</div>
		singleWrap = &nbsp;|&nbsp;
	}
 
	#PreProcessors
	preProcessors {
		1.class = PreProcessor_LoadGetPost
	}
 
	# Validators configuration
	validators {
		1 {
			class = Tx_Formhandler_Validator_Default
			config {
				fieldConf {
					emailunsubscribe {
						errorCheck.1 = required
						errorCheck.2 = email
						errorCheck.3 = isInDBTable
						errorCheck.3 {
							table = tt_address
							field = email
							fields {
								email.mapping = emailunsubscribe
							}
						}
					}
				}
			}
		}
	}
 
	# Finishers configuration
	finishers {
		1.class = Finisher_DB
		1.config {
		  debug = 1
			table = tt_address
			updateInsteadOfInsert = 1
			key = email
			key_value = TEXT
			key_value.data = GPvar:formhandler|emailunsubscribe
			fields {
				hidden.ifIsEmpty = 1
				email.mapping = emailunsubscribe
			}
		}
		2.class = Finisher_Redirect
		2.config {
			redirectPage = 97
		}
	}
}

<!-- ###TEMPLATE_FORM1### begin -->
<div id="formhandler_newsletter_unsubscribe_form">
	<form method="post" action="###REL_URL###">
	<table>
		<tr>
			<td>###LLL:newsletter_intro_unsubscribe###</td>
		</tr>
		<tr>
			<td>
				<table>
					<tr>
						<td class="newsletterlabel">###LLL:emailunsubscribe### ###required_emailunsubscribe###</td>
						<td><input type="text" ###is_error_emailunsubscribe### name="formhandler[emailunsubscribe]" id="emailunsubscribe" value="###value_emailunsubscribe###" size="30" class="newsletterinput"/></td>
					</tr>
			  </table>
			</td>
		<tr>
			<td class="newslettertext">###LLL:required_fields###</td>
		</tr>
		<tr>
			<td class="newslettertext">###LLL:newsletter_text_1###</td>
		</tr>
    <tr>
    	<td>&nbsp;</td>
    </tr>
    <tr>
    	<td><input type="submit" value="###LLL:submit###" ###submit_nextStep###/></td>
	  </tr>
    <tr>
    	<td>###ERROR###</td>
	  </tr>
	</table>
	</form>
</div>
<!-- ###TEMPLATE_FORM1### end -->
 
<!-- ###TEMPLATE_SUBMITTEDOK### begin -->
<table>
  <tr>
    <td>###LLL:emailunsubscribe###</td>
    <td>###value_emailunsubsrcibe###</td>
  </tr>
</table>
<!-- ###TEMPLATE_SUBMITTEDOK### end -->

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
	<data type="array">
		<languageKey index="default" type="array">
 
			<label index="emailunsubscribe">E-Mail</label>
 
			<label index="required_fields">* Pflichtfelder</label>
			<label index="newsletter_text_1">Die Daten werden nicht an Dritte weitergegeben.</label>
			<label index="submit">Formular senden</label>
 
			<label index="error_emailunsubscribe_required">Gültige E-Mail Adresse bitte eingeben.</label>
			<label index="error_emailunsubscribe_email">Gültige E-Mail Adresse bitte eingeben.</label>
			<label index="error_emailunsubscribe_isInDBTable">Diese E-Mail Adresse ist nicht registriert.</label>
		</languageKey>
	</data>
</T3locallang>

Dies ist ein Gast-Beitrag von Alois Rainbacher. Vielen Dank dafür.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Die Extension sr_feuser_register gibt bei der Nutzung des Autologin Features den Benutzernamen und das Passwort des Frontend Benutzers preis. Eine aktualisierte Version 2.6.2 steht im TER bereit.

Das zweite Bulletin behandelt eine ganze Reihe von Extensions:

• Crop and Square Thumbnails (tkcropthumbs)
• Typo3 eXtplorer (t3extplorer)
• TC BE User Admin (tc_beuser)
• Predigtsammlung (an_predigten)
• Apache Solr for TYPO3 (solr)
• PDF Controller (pdfcontroller)
• Share Your Car (cc20)
• JW Player (jwplayer)

Details finden sich in den jeweiligen Bulletins:

• TYPO3-EXT-SA-2012-002
• TYPO3-EXT-SA-2012-003

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Aber was ist zu tun um das ganze zum laufen zu bringen? Gar nicht so viel!

1. Extension “maintenance” aus dem TER installieren
2. Im Extension Manager das Setting “adminOnly” konfigurieren. Dieses Setting wird bei Aktivierung des Wartungsmodus automatisch gesetzt. Dort ist Einstellbar, wer sich während der Wartung in das Backend einloggen kann (alle User, nur Administratoren, Administratoren und CLI Benutzer)
3. Zur Kontrolle sollten die Einstellungen “DevIpMask”, “pageUnavailable_handling” und “pageUnavailable_handling_statheader” im Install-Tool überprüft werden
4. Um ganz sicher zu gehen, kann man seine getätigten Einstellungen noch im Report-Module im Bereich “maintenance” überprüfen
5. Danach einfach mal das TYPO3 Backend neu laden. In der rechten oberen Ecke sollte nun ein neues Icon auftauchen, was den Wartungsmodus aktiviert / deaktiviert

Schritt zwei, drei und vier sind nicht wirklich nötig um die Extension zu testen. Dennoch sind diese sinnvoll und empfehlenswert. Denn wie schon im verlinken Artikel beschrieben sollte die “DevIpMask” auf die aktuelle IP-Adresse zutreffen um weiterhin die richtige Seite zu sehen. “pageUnavailable_handling” sollte mittels READFILE, REDIRECT, USER_FUNCTION, oder ähnliches auf einen vernünftigen und aussagekräftigen Wert gesetzt werden, damit der Benutzer auch weiß warum die Seite für kurze Zeit nicht verfügbar ist. Und zu guter letzt sollten alle automatischen Anfragen mittels “pageUnavailable_handling_statheader” informiert werden (HTTP Header 503).

Bereits kurz nach dem ersten Release im TER hat Josef Florian Glatz vom österreichischen TYPO3Blog die Extension aufgegriffen, getestet und einen Artikel darüber verfasst. Dazu wurde ein kleiner Screencast erstellt, den er uns freundlicherweise zur Verfügung gestellt hat. Vielen Dank dafür!
[Im Feed kann dieses Video nicht angezeigt werden.Klicke zum Blogeintrag um das Video anzusehen.]

Wie immer würde ich mich als Entwickler über Feedback sehr freuen (auch negatives!). Gefundene Bugs sowie weitere Features werden gerne im Forge-Issue-Tracker entgegen genommen. Auch eine Bewertung (Rating) im TYPO3 Extension Repository zaubert einem Entwickler ein grinsen ins Gesicht

Und nun eine Frage aus eigenem Interesse: Werdet Ihr diese Extension einsetzen oder ist diese “unnütz”, weil TYPO3 alles von Haus aus mit bringt?

Weitere Links:

• EXT:maintenance auf Forge
• EXT:maintenance im TER
• Extension-Review auf TYPO3blog.at
• EXT:maintenance-Review auf Vimeo

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Wie also unschwer zu erkennen ist, war die Entwicklung dieser Extension  in letzter Zeit nicht ganz so aktiv. Dies liegt daran, dass der aktuelle Autor, Juraj Sulek, keine Zeit mehr zur Pflege sowie Weiterentwicklung dieser Extension hat. Aus diesem Grund wird hier ein Aufruf gestartet:

Hat jemand Lust, Zeit und Muße die Extension realurlmanagement zu übernehmen? Es wird ein neuer Autor gesucht!

Wenn Ihr euch nun angesprochen fühlt, könnt Ihr euch einfach bei Juraj via Forge melden. Er beißt nicht und ist gerne bereit dieses Projekt in neue Hände zu übergeben.

Und noch eine Frage für Zwischendurch: Was haltet Ihr von solchen “Angeboten” / “Gesuchen” auf diesem Blog? Passend, da es um eines der meist genutzten Features (Extensions) geht und es ist völlig in Ordnung oder seid Ihr von einer solchen Art von Posts genervt? Kleines Feedback in den Comments wäre klasse.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Man lädt sich also die Erweiterung “gridelements” aus dem TER, installiert sie und bindet die “Statischen Templates” ein. Danach den System-Ordner, den man als “Allgemeine Datensatzsammlung” angegeben hat öffnen und dort einen neuen Datensatz vom Typ “CE Backend Layout” anlegen. Die Funktionsweise ist hier die gleiche wie bei den Backend Layouts. Danach lässt sich das neu angelegte Element auf einer Seite einfügen. Man findet es in der Rubrik “Raster-Elemente”. Hat man z. B. ein zweispaltiges Element angelegt, sieht das Backend ungefähr so aus:

Nachdem das erfreulicherweise schon alles war, kümmern wir uns um die Ausgabe auf der Webseite. Dazu kann man per Typoscript definieren, wie dieses Element ausgegeben werden soll. Für das zweispaltige Element könnte das so aussehen:

tt_content.gridelements_pi1.20.10.setup {
	# ID of gridelement
	1 < temp.gridelements.defaultGridSetup
	1 {
		columns {
			# colPos ID
			11 < .default
			11.wrap = <div class="firstcol">|</div>
			# colPos ID
			12 < .default
			12.wrap = <div class="secondcol">|</div>
		}
		wrap = <div class="element2cols">|</div>
	}
}

Wichtig sind hier die verwendeten Zahlen. Die “1″ entspricht der ID des angelegten “gridelements”. Darin befinden sich die “columns”, die anhand ihrer colPos mit einem “wrap” versehen werden können. Der “wrap” am Ende umschließt das komplette Element. Zusätzliche Elemente können nach dem gleichen Schema hinzugefügt werden.

Selbst wenn man keine Raster-Elemente benötigt, empfiehlt es sich, die Erweiterung gridelements zu installieren. Denn man erhält mit dieser Extension auch eine Drag&Drop-Funktionalität für die Inhaltselemente, wie man sie von Templavoila kennt.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Um die mögliche Manipulation der zentralen index.php Datei bei TYPO3 zu entdecken ist die Extension CheckMySite sehr hilfreich.

Die Extension überprüft die index.php bei jedem Seitenaufruf auf potenziellen Schadcode indem ca. 60 Regeln abgearbeitet werden. Auf die Prüfung einer zuvor hinterlegten Signatur wurde bewußt verzichtet, damit nicht bei jedem TYPO3 Update neue Signaturen erzeugt werden müssen. Das Regelset bildet alle momentan bekannten Angriffszenarien ab und kann bei Bedarf später erweitert werden.

Wird potenzielle Schadcode entdeckt, wird eine Mail an eine vorher definierte Adresse geschickt. Die Nachricht wird in regelmäßigen Abständen erneut verschickt, damit sie nicht untergeht. Der Zeitraum kann frei definiert werden.

Außerdem wird der Frontend Output von TYPO3 unterbunden und stattdessen ein frei wählbarer Text, wie zum Beispiel “Webseite wegen Wartungsarbeiten nicht erreichbar” angezeigt oder auf eine andere URL (z.B. eine statische Wartungsseite) umgeleitet. Dadurch wird sichergestellt, dass sich der Schadcode nicht weiter verbeiten oder von Google indiziert werden kann.

Nachdem der Schadcode entfernt wurde, läuft die Webseite wieder wie gewohnt.

Laut Extension Autor verzögert sich der Seitenaufbau durch die Überprüfung um etwa 20 ms. Für Seiten mit normalem Traffic dürfte das keine Rolle spielen, bei größeren Webseiten oder Seiten mit Lastspitzen sollte die Serverlast aber im Auge behalten werden.

Die aktuell im TER verfügbare Version 2.0.3 von CheckMySite setzt PHP 5.3 voraus. Durch die Änderung einer Zeile Code läuft sie aber auch problemlos in PHP 5.2.
Dazu muss in der Datei typo3conf/ext/checkmysite/lib/class.checkfile.php das Code Schnipsel

realpath(__DIR__).'/check.db';

durch

realpath(t3lib_extMgm::extPath('checkmysite')).'/check.db';

ersetzt werden.

Andernfalls wird das TYPO3 Protokoll mit Fehlermeldungen dieser Art überschwemmt:

PHP Warning: touch(): Unable to create file /check.db because Permission denied in /pfad/zu/typo3conf/ext/checkmysite/lib/class.checkfile.php line 228

Außerdem wird dann bei jedem Seitenaufruf eine Mail verschickt und nicht nur ein mal pro eingestelltem Intervall. Bei regem Traffic kann das eine Mailbox schnell sprengen.

Ein Update der Extension, die auch mit PHP 5.2 kompatibel ist, wurde bereits in Aussicht gestellt.

Installation

Die Installation ist super einfach: Extension über den Extension Manager aus dem TER downloaden und installieren. Danach Empfänger und Absender Adresse eingeben. Auch mehrere Empfänger sind möglich. Außerdem kann der Text, der bei der Entdeckung von Schadcode angezeigt wird, angepasst werden oder eine Weiterleitungs Adresse definiert werden. Zuletzt wird noch der Intervall der Benachrichtigungsmail festgelegt. Standard ist eine halbe Stunde. Nach dem Speichern ist die Installation abgeschlossen und die Webseite wird überwacht.

Fazit

Durch die Extension CheckMySite kann eine Webseite sehr leicht sicherer gemacht werden. Man darf sich aber nicht der Illusion hingeben, dadurch unverwundbar zu sein. Ein weiteres beliebtes Angriffsziel für Manipulationen ist zum Beispiel die .htaccess Datei, die nicht überwacht wird. Updates des TYPO3 Cores und aller Extensions sollten also immer Priorität haben.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

<!--[if lt IE 7]> <html lang="de" class="no-js ie6"> <![endif]-->
<!--[if IE 7]> <html lang="de" class="no-js ie7"> <![endif]-->
<!--[if IE 8]> <html lang="de" class="no-js ie8"> <![endif]-->
<!--[if gt IE 8]><!--> <html lang="de" class="no-js"> <!--<![endif]-->

Je nach eingesetztem Browser hat man also zusätzliche CSS-Klassen im <html> Tag, anhand derer man seine Seite für verschiedene IE-Browser-Versionen anpassen kann. Dieser Ansatz hat den Vorteil, dass man alle CSS-Angaben in einer CSS-Datei machen kann und dazu keine CSS-Hacks benötigt, um die unterschiedlichen IEs anzusprechen. Und da das alles in einer Datei machbar ist, spart man sich auch noch ein paar HTTP-Requests – im Vergleich zur Einbindung von versionsspezifischen Stylesheets per Conditional Comment.

Aber wie bekommt man das jetzt in eine TYPO3-Seite?

Nur mit der Angabe von “config.doctype = html5″ ist es hier natürlich nicht getan. Es gibt meines Wissens auch keine Standard-Typoscript-Anweisung, mit der man den obigen Code in die Webseite bekommt. Aber für solche Fälle gibt es ja Extensions! Und hier hilft die Extension “html5boilerplate“. Nach der Installation dieser Extension lässt sich der obige Code wie folgt einfügen:

config.html5boilerplate {
 htmlTag (
    <!--[if lt IE 7]> <html lang="de" class="no-js ie6"> <![endif]-->
    <!--[if IE 7]> <html lang="de" class="no-js ie7"> <![endif]-->
    <!--[if IE 8]> <html lang="de" class="no-js ie8"> <![endif]-->
    <!--[if gt IE 8]><!--> <html lang="de" class="no-js"> <!--<![endif]-->
  )
}

Somit hätte man den kompliziertesten Teil der HTML5 Boilerplate in TYPO3 integriert. Alles andere lässt sich im Prinzip mit hinlänglich bekannten TYPO3-Boardmitteln erledigen.

Die Extension liefert dazu auch Statische Templates (Typoscript) zum Einbinden mit, in denen neben dem obigen Snippet auch viele andere Anweisungen definiert sind. Es wird z. B. Modernizr im <head> eingebunden und alle anderen Skripte per “page.includeJSFooter” in den Footer geladen. Es lohnt sich also, einen Blick in die TS-Templates zu werfen, selbst wenn man die Extension eigtl. nur für das Setzen des HTML-Tags verwenden möchte.

Einer Webseite nach HTML5 Boilerplate Prinzipien steht dank dieser Extension nichts im Wege.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Der Scheduler Task legt parallel zur “localconf.php” eine “localhost_AutoRealURLDomainConfiguration.php”-Datei ab. In dieser werden automatisch (im Intervall des Scheduler Tasks) alle Domains, welche keine Weiterleitungen sind, mit der passenden rootpage_id konfiguriert (Achtung: Syntax-Highlightig funktioniert nicht richtig).

class Tx_Extension_Scheduler_RealUrlDomainConfiguration extends tx_scheduler_Task {
 
    public function execute() {
        $nl = "\n";
        $phpCode = '<?php'.$nl;
        $res = $GLOBALS['TYPO3_DB']->exec_SELECTquery('*','sys_domain','hidden=0 AND redirectTo=""','','',1000);
        while($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)){
            $phpCode .= '$TYPO3_CONF_VARS[\'EXTCONF\'][\'realurl\'][\''.$row['domainName'].'\'] = $TYPO3_CONF_VARS[\'EXTCONF\'][\'realurl\'][\'_DEFAULT\'];'.$nl;
            $phpCode .= '$TYPO3_CONF_VARS[\'EXTCONF\'][\'realurl\'][\''.$row['domainName'].'\'][\'pagePath\'][\'rootpage_id\'] = '.$row['pid'].';'.$nl;
        }
        $phpCode .= '?>';
 
        // write
        $path = PATH_site.'typo3conf/localhost_AutoRealURLDomainConfiguration.php';
        return file_put_contents($path, $phpCode);
    }
}

Der Aufruf der neuen RealURL-Konfigurationdatei findet dann HINTER euren normalen RealURL Konfiguration (in der “localconf.php”) statt.

// normale RealURL Config hier (_DEFAULT)
 
$autoRealConf = dirname(__FILE__).'/localhost_AutoRealURLDomainConfiguration.php';
if(file_exists($autoRealConf))
	require_once($autoRealConf);
 
// Besonderheiten für Domains hier (Domain)

Vorteil dieser Lösung ist, dass man im Backendmodul “Konfiguration” alle Domains in der RealURL Konfiguration wiederfindet und auch die Änderungen passend sichtbar sind. Habt ihr eine andere, vielleicht leichtere/bessere Lösung?

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Im folgenden Tutorial werden wir kaum Angaben im Plugin vom Formhandler machen. Alles was wir benötigen sind 4 Dateien und eine Zeile TypoScript. Vor- und zugleich Nachteil von Formhandler ist, dass jegliche Konfiguration in Dateien ausgelagert werden muss/sollte, was dann aber wiederum den Vorteil hat, dass diese Konfiguration sehr schnell auf ein anderes System portieren kann. Nach der Einbindung der TypoScriptzeile erscheint im Plugin ein neuer Eintrag in der Selectbox für “Vordefinierte Formulare”. Einfach auswählen. Fertig.

Ich werde hier nicht auf jede einzelne Option von Formhandler eingehen, das würde den Rahmen sprengen. Wenn es Euch interessiert, dann könnt Ihr die Webseite von Formhandler oder auch mein erstes Tutorial lesen, dass ich auf meiner Webseite präsentiere: Stefans TYPO3-Seite.

Ablauf der Anmeldung

Wir erstellen eine Seite mit einem Formular auf dem sich die beiden Felder name und email befinden. Nach dem Absenden werden die eingetragenen Daten zunächst validiert (Tx_Formhandler_Validator_Default) und bei Erfolg in die Tabelle tt_address abgespeichert (Finisher_DB). Hier setze ich die Spalte hidden per default auf 1, damit der User nicht sofort aktiv ist. Natürlich wäre auch eine Speicherung in fe_users möglich, aber dann müssten wir dem Datensatz noch eine Gruppe, einen Benutzernamen und ein Passwort zuordnen. Zu viel für meinen Geschmack. Nach der Speicherung wird aus den gesammelten Daten ein AuthCode erstellt (Finisher_GenerateAuthCode) und per Mail an der User und als Info auch an den Admin geschickt (Tx_Formhandler_Finisher_Mail). Klickt der User den Link mit dem enthaltenen AuthCode an, wird der PreProcessor aktiv (PreProcessor_LoadGetPost) und läd sich die benötigten Daten aus der URL in den Speicher. An Hand dieser Daten kann der AuthCode-Validator aktiv werden (PreProcessor_ValidateAuthCode). Dieser überprüft, ob der AuthCode gültig ist und setzt den Datensatz bei einer erfolgreichen Überprüfung automatisch auf visible (hidden=0). Außerdem können hier je nach Gültigkeit Page-UIDs angegeben werden auf die weitergeleitet wird.

newsletter.ts

plugin.Tx_Formhandler.settings.predef.newsletter {
	# Common configuration
	name = Newsletterregistrierung
	addErrorAnchors = 1
	templateFile = fileadmin/templates/formhandler/newsletter.html
	langFile.1 = fileadmin/templates/formhandler/newsletter.xml
	cssFile.1 = fileadmin/templates/formhandler/newsletter.css
	formValuesPrefix = formhandler
 
	requiredSign = TEXT
	requiredSign.value = *
	requiredSign.wrap = <span style="color: #DF9707;">|</span>
 
	isErrorMarker.default = class="errorField"
 
	# HTML wrapping by validation error
	errorListTemplate {
		totalWrap = <div class="error"><ul>|</ul></div>
		singleWrap = <li>|</li>
	}
 
	#PreProcessors
	preProcessors {
		1.class = PreProcessor_LoadGetPost
		2.class = PreProcessor_ValidateAuthCode
		2.config {
			redirectPage = 234
			errorRedirectPage = 235
			hiddenField = hidden
		}
	}
 
	# Validators configuration
	validators {
		1 {
			class = Tx_Formhandler_Validator_Default
			config {
				fieldConf {
					name {
						errorCheck.1 = required
					}
					email {
						errorCheck.1 = required
						errorCheck.2 = email
					}
				}
			}
		}
	}
 
	# Finishers configuration
	finishers {
		1.class = Finisher_DB
		1.config {
			table = tt_address
			key = uid
			fields {
				email.mapping = email
				name.mapping = name
				pid.ifIsEmpty = 57
				hidden.ifIsEmpty = 1
				module_sys_dmail_html.ifIsEmpty = 1
			}
		}
		2.class = Finisher_GenerateAuthCode
		2.config {
			table = tt_address
		}
		3.class = Tx_Formhandler_Finisher_Mail
		3.config {
			limitMailsToUser = 5
			admin {
				to_email = AdminEmailAdresse
				to_name = DeinNamw
				subject = Neue Newsletterregistrierung auf [webseite]
				sender_email = webmaster@xxx
				sender_name = Webmaster
				htmlEmailAsAttachment = 0
			}
			user {
				to_email = email
				to_name = name
				subject = Dein Anliegen von [webseite]
				sender_email = webmaster@xxx
				sender_name = Webmaster
				replyto_email = DeineEmailAdresse
				replyto_name = TEXT
				replyto_name.value = Deine Name
				htmlEmailAsAttachment = 0
		 	}
		}
		4.class = Finisher_Redirect
		4.config {
			redirectPage = 233
		}
	}
}

newsletter.xml

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
	<data type="array">
		<languageKey index="default" type="array">
			<label index="name">Name</label>
			<label index="email">E-Mail</label>
			<label index="submit">Send</label>
			<label index="is_error">One or more errors occoured while filling the form!</label>
			<label index="error_name_required">Enter your name!</label>
			<label index="error_email_required">Enter your E-mail address!</label>
			<label index="error_email_email">E-mail address must be valid syntax!</label>
			<label index="required_fields">Fields marked with * are required!</label>
		</languageKey>
		<languageKey index="de" type="array">
			<label index="name">Name</label>
			<label index="email">E-Mail</label>
			<label index="submit">Absenden</label>
			<label index="is_error">Beim Absenden des Formulars sind ein paar Fehler aufgetreten:!</label>
			<label index="error_name_required">Bitte gib Deinen Namen an!</label>
			<label index="error_email_required">Bitte gib Deine E-Mail-Adresse an!</label>
			<label index="error_email_email">Die eingetragene E-Mail-Adresse ist ungültig!</label>
			<label index="required_fields">Felder mit * sind Pflichtfelder!</label>
		</languageKey>
	</data>
</T3locallang>

newsletter.html

<!-- ###TEMPLATE_FORM1### begin -->
<div id="formhandler_newsletter_form">
	###ERROR###
	<form method="post" action="###REL_URL###">
		<p>###LLL:required_fields###</p>
		<input type="hidden" name="formhandler[submitted]" value="1" />
		<dl>
			<dt><label for="name">###LLL:name### ###required_name###</label></dt>
			<dd><input type="text" ###is_error_name### name="formhandler[name]" id="name" value="###value_name###"/></dd>
		</dl>
		<dl>
			<dt><label for="email">###LLL:email### ###required_email###</label></dt>
			<dd><input type="text" ###is_error_email### name="formhandler[email]" id="email" value="###value_email###"/></dd>
		</dl>
		<dl>
			<dd><input type="submit" value="###LLL:submit###" ###submit_nextStep###/></dd>
		</dl>
	</form>
</div>
<!-- ###TEMPLATE_FORM1### end -->
 
<!-- ###TEMPLATE_EMAIL_USER_PLAIN### begin -->
Hallo ###value_name###,
 
Du hast Dich soeben für meinen Newsletter auf [webseite] angemeldet.
Bitte klicke auf den folgenden Link, um die Registrierung abzuschließen:
 
###value_authCodeUrl###
<!-- ###TEMPLATE_EMAIL_USER_PLAIN### end -->
 
<!-- ###TEMPLATE_EMAIL_USER_HTML### begin -->
<p>Hallo ###value_name###</p>
<p>Du hast Dich soeben für meinen Newsletter auf [webseite] angemeldet.<br />
Bitte klicke auf den folgenden Link, um die Registrierung abzuschließen:</p>
<p><a href="###value_authCodeUrl###" target="_blank">Newsletteranmeldung bestätigen</a></p>
<!-- ###TEMPLATE_EMAIL_USER_HTML### end -->
 
<!-- ###TEMPLATE_EMAIL_ADMIN_PLAIN### begin -->
Hallo Admin,
 
Soeben hat sich ###value_name### (###value_email###) für den Newsletter auf [webseite] angemeldet.
 
Dein Server
<!-- ###TEMPLATE_EMAIL_ADMIN_PLAIN### end -->
 
<!-- ###TEMPLATE_EMAIL_ADMIN_HTML### begin -->
<p>Hallo Admin,</p>
<p>Soeben hat sich ###value_name### (###value_email###) für den Newsletter auf [webseite] angemeldet</p>
<p>Dein Server</p>
<!-- ###TEMPLATE_EMAIL_ADMIN_HTML### end -->
 
<!-- ###TEMPLATE_SUBMITTEDOK### begin -->
<table>
  <tr>
    <td>###LLL:name###</td>
    <td>###value_name###</td>
  </tr>
  <tr>
    <td>###LLL:email###</td>
    <td>###value_email###</td>
  </tr>
</table>
<!-- ###TEMPLATE_SUBMITTEDOK### end -->

newsletter.css

#formhandler_newsletter_form {
	width: 100%;
}
 
#formhandler_newsletter_form .error ul {
	margin: 0;
}
 
.errorField {
	background-color: #FF0000;
}

Die eine Zeile TypoScript

<INCLUDE_TYPOSCRIPT: source="FILE:fileadmin/templates/formhandler/newsletter.ts">

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Wenn eine neue TYPO3 Webseite fertig und live ist, würde man sich gerne entspannt zurücklehnen und die Webseite einfach mal laufen lassen. Aber so eine TYPO3 Installation ist ein komplexes Gebilde aus der verwendeten TYPO3 Version, Extensions aus dem TYPO3 Extension Repository und den eigenen Einstellungen. Deswegen ist es gar nicht so einfach, den Gesundheitszustand einer TYPO3 Instanz zu überwachen. Mit einer Überwachungssoftware wie Nagios kann man hauptsächlich den Zustand des Servers und der Hardware überwachen. Aber für die Innereien einer TYPO3 Instanz gibt es bislang noch keine anständige Lösung. Zwei Firmen aus Kiel und Hamburg haben sich zusammen getan und eine flexible und leistungsfähige Lösung geschaffen, die diese Anforderungen erfüllen soll:

1. zentrales Testen und Überwachen von entfernten TYPO3 Instanzen, Extensions und Setups
2. Integration Tests (auf der Basis von Selenium)
3. Flexible und komfortable Verwaltung über TYPO3 Datensätze
4. Erweiterbarkeit des gesamten Systems

Caretaker

Herausgekommen ist der Caretaker, eine TYPO3 basierte Lösung. Hier eine kleine Auswahl der Features und Möglichkeiten:

• Prüfen der Erreichbarkeit (HTTP Status Code / Ping)
• TYPO3 Core Version prüfen
• unsichere Extensions finden
• gezielte Prüfung einer Extension auf Versionsnummer
• Blacklist für Benutzernamen und Passwörter
• TYPO3 Core auf nicht autorisierte Änderungen am Code prüfen
• (Nicht-)Existenz von Dateien prüfen, 
z.B. ENABLE_INSTALL_TOOL
• TYPO3_CONF_VARS prüfen, 
z.B. auf Default Install Tool Passwort
• verfügbare Extension Updates anzeigen
• Benachrichtigungssytem
• Integration von eigenen Test Services

Wie funktioniert der Caretaker?

Das Caretaker Basis System wird zum einen auf einem zentralen Server als TYPO3 Extension installiert. Dazu kommt dann die Erweiterung caretaker_instance, die die eigentlichen Tests enthält. caretaker_instance kommuniziert über eine mit RSA verschlüsselte Verbindung mit den einzelnen TYPO3 Instanzen. Zusätzlich gibt es noch die Möglichkeit, per SNMP mit Instanzen zu kommunizieren.

Funktionsweise von Caretaker

Der Caretaker Server kann dabei lediglich lesend auf die einzelnen TYPO3 Instanzen zugreifen. Updates können über Caretaker nicht automatisiert eingespielt werden, da die Gefahr zu groß ist, eine TYPO3 Instanz dadurch funktionsunfähig zu machen.

Die Informationen über die neuesten Änderungen bei TYPO3 Extensions bezieht Caretaker über einen Scheduler Task, der regelmäßig die Liste der Extensions aus dem TER bezieht. Dieser Scheduler Task ist seit TYPO3 4.5 Bestandteil von TYPO3. Die jeweils neuesten TYPO3 Versionsnummern werden aus einem RSS Feed von Sourceforge ermittelt. Änderungen am TYPO3 Core werden durch Fingerprints erkannt. Die Extension caretaker_integrity liefert einige Fingerprints bereits mit. Für neue TYPO3 Versionen können die Fingerprints über einen Cronjob in caretaker_integrity generiert werden.

Caretaker Backend

Im TYPO3 Backend gibt es nach der Installation von Caretaker ein neues Modul, in dem die einzelnen Instanzen gepflegt werden können. Um die Übersichtlichkeit zu erhöhen, können TYPO3 Instanzen in Instanzgruppen zusammengefasst werden. Außerdem wird durch Farben (rot, gelb, grün) der Zustand der einzelnen Instanzen bzw. Tests angezeigt. Im TYPO3 Backend werden zudem die Tests und Testgruppen gepflegt und individuelle Einstellungen gemacht.

Caretaker Modul im TYPO3 Backend

Die wichtigsten Tests im Überblick

Ein paar der Tests, die ich in meiner Caretaker Installation eingerichtet habe, möchte ich im Folgenden kurz vorstellen:

• unsichere Extensions
  Das TYPO3 Security Team markiert unsichere Extensions in der Extension Liste. Sobald der Caretaker feststellt, dass eine bestimmte Version einer Extension als unsicher markiert ist, wird Alarm geschlagen
• unsichere TYPO3 Version
  In der Testkonfiguration kann festgelegt werden, welche Versionsnummer mindestens erfüllt sein muss. So kann schnell festgestellt werden, ob unsichere TYPO3 Versionen verwendet werden
• Source Integrity
  Über die eingangs bereits erwähnten Fingerprints werden die Dateien des Core mit den Fingerprints verglichen. Dadurch können unerwünschte Änderungen an Core Dateien sofort erkannt werden
• Datei “ENABLE_INSTALL_TOOL” vorhanden
  Hier wird geprüft, ob die Datei in typo3conf vorhanden ist und jünger als 2 Stunden ist
  
• Standard Install Tool Password “joh316″ ist aktiv
  TYPO3 weist zwar darauf hin, wenn das Standard Password noch aktiv ist, aber ich lasse das zusätzlich durch den Caretaker prüfen
• Prüfung der BE User Accounts auf verbotene Passwörter
  Prüft alle Backend Accounts auf verbotene Passwörter wie “password”, “12345678″, etc.
  
• Deprecation Log aktiv
  Prüft, ob das Deprecation Log noch aktiv ist
  
• Extension Updates verfügbar
  Dieser Test zeigt alle verfügbaren Extension Updates an
  
• HTTP / Ping Test
  Prüft die Erreichbarkeit der Webseite per Ping und wertet zusätzlich noch den Status Code einer Anfrage per HTTP aus
  

Weitere Test Services:

• Logfile Analyzer Service
• Redmine Testcase
• Selenium Testcase

Caretaker Frontend

Zusätzlich zum Backend bietet Caretaker auch eine Frontend Ausgabe der Test Ergebnisse. Diese Ausgabe kann zum Beispiel Kunden zugänglich gemacht werden.

Caretaker Frontend Ausgabe

Benachrichtigungen

Caretaker liefer ein simples und ein erweitertes Benachrichtigungssystem per Mail gleich mit. Für das erweiterte Benachrichtigungssystem ist aber leider noch keine Dokumentation verfügbar. Tobias Liebig, einer der Caretaker Entwickler, hat aber bereits einen Blog Eintrag mit einer Anleitung angekündigt!

Systemvoraussetzungen für den Einsatz von Caretaker

Die TYPO3 Instanz mit dem Caretaker Server benötigt PHP 5.2 mit OpenSSL Unterstützung und TYPO3 4.3 oder höher.

Für die Instanzen reicht TYPO3 4.o oder höher, allerdings wird auch hier PHP 5.2 benötigt.

Download

Caretaker ist zwar grundsätzlich auch im TER verfügbar, allerdings ist die veröffentlichte Version mehr als ein Jahr alt und hat sich seit dem schon wieder stark weiter entwickelt.

Es empfiehlt sich deshalb, den aktuellen Stand aus dem Subversion Repository auszuchecken.

Links zum Thema

• Extensions im TER:
• typo3.org/extensions/repository/view/caretaker/current/
• typo3.org/extensions/repository/view/caretaker_instance/current/
• Forge:
• forge.typo3.org/projects/extension-caretaker
• SVN: https://svn.typo3.org/TYPO3v4/Extensions/caretaker
• Dokumentation: forge.typo3.org/projects/extension-caretaker/wiki
• Webseite:
• typo3-caretaker.org
• Mailingliste:
• http://lists.typo3.org/pipermail/typo3-project-caretaker/
• Twitter:
• @typo3_caretaker

Support

Unterstützung durch die Entwickler und andere User bekommt man über die oben genannte Mailingliste.

Caretaker Entwicklung unterstützen

Die an Caretaker beteiligten Entwickler und Firmen haben eine Menge Zeit und Geld in das Projekt investiert. Für weitere Features werden noch Spenden gesucht, um die Entwicklung zu finanzieren.

Auf meiner persönlichen Wunschliste steht vor allem die Möglichkeit, im Caretaker Backend Abfragen dieser Art zu starten: Filter alle Instanzen raus, die die Extension XYZ in Version 1.2.3 nutzen. Abfragen dieser Art sind bislang leider nicht möglich und das ist meiner Meinung nach das größte Manko von Caretaker, denn wenn z.B. das Security Team ein  Security Bulletin raus gibt, muss ich alle Instanzen (und ich verwalte mit Caretaker mittlerweile verdammt viele) von Hand kontrollieren.

Außerdem würde ich mir häufigere TER Releases wünschen, denn das würde sicher zur vermehrten Nutzung von Caretaker beitragen. Die aktuell im TER verfügbare Version ist soweit ich das in Erinnerung habe, nur bis TYPO3 4.4 kompatibel. Öftere Updates wären auch für die Extension caretaker_integrity mit den Fingerprints nötig. Der mitgelieferte Cronjob läuft zumindest bei mir noch nicht so ganz rund und es ist bei jedem TYPO3 Release Handarbeit angesagt, um die neuen Fingerprints zu erzeugen. Auch fehlen Fingerprints von vielen älteren TYPO3 Versionen, die mit dem aktuellen Cronjob leider nicht erzeugt werden können.

Fazit

Caretaker ist ein super System, um viele TYPO3 Instanzen zu überwachen. Zum aktuellen Zeitpunkt muss man beim Einsatz von Caretaker aber noch an diversen Stellen selber Hand anlegen und sich zum Beispiel die richtige Dokumentation zusammen suchen.

Gegenüber anderen auf TYPO3 spezialisieren Monitoring Systemen wie zum Beispiel t3manager, hat Caretaker aber den entscheidenden Vorteil, dass man das System auf einer eigenen Maschine installieren kann und die Daten über seine TYPO3 Instanzen nicht in fremde Hände geben muss. Außerdem kann Caretaker flexibel an eigene Wünsche angepast werden.

Bei genügend Interesse schreibe ich demächst einen weiteren Artikel, die die Installation und Einrichtung von Caretaker genauer beschreibt. Bitte das Interesse in den Kommentaren bekunden.

Mich würde jetzt noch interessieren, wer den Caretaker bereits einsetzt und welche Erfahrungen gemacht wurden.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!