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!

Um Context Sensitive Help nun aktivieren zu können, sind 2 Schritte nötig.

1. Es muss eine entsprechende Datei mit den Hilfetexten erstellen werden
2. Die Datei ext_tables.php der Extension muss modifiziert bzw. erweitert werden

Im Root-Verzeichnis der Extension erstellt man sich eine XML-Datei oder kopiert sich die locallang.xml und benennt diese in "locallang_csh_ExtensionKey_DBTabelle.xml" um. In diese XML-Datei werden wie gewohnt die verschiedenen Übersetzungen der Sprachen angelegt. Lediglich die META-Angabe unterscheidet sich und sollte in etwa wie folgt aussehen:

<meta type="array">
	<description>CSH for your own table.</description>
	<type>CSH</type>
	<csh_table>tx_meineExtension_DBTabelle</csh_table>
</meta>

Der Index der Label-Tags setzt sich aus dem Tabellenfeld und ".description" zusammen, z.B.

<label index="subtitle.description">Eine Beschreibung für das Beschreibungsfeld.</label>

Im zweiten Schritt muss die XML-Datei TYPO3 bekannt gemacht werden und dies erfolgt in der Datei ext_tables.php (ebenfalls im Root-Verzeichnis der Extension). Hier wird nun die folgende Zeile (bei mir am Ende der Datei) eingefügt:

t3lib_extMgm::addLLrefForTCAdescr(
  'tx_meineExtension_DBTabelle',
  'EXT:ExtensionKey/locallang_csh_ExtensionKey_DBTabelle.xml'
);

Danach werden die Hilfetexte beim überfahren der Feldbeschriftung mit der Maus nachgeladen. Ich persönlich finde es nicht gerade praktisch, dass es keinen Hinweis in Form eines Icons mehr gibt. Dadurch muss man immer Raten hinter welcher Feldbezeichnung vll. auch eine Beschreibung verborgen ist.

Die genannten 2 Schritte kann man nun für weitere DB-Tabellen wiederholen und somit für jedes Eingabefeld eine entsprechende Beschreibung einbinden.

P.S.: Wer bereits mit Extbase programmiert, muss sich darum nicht mehr kümmern, sofern mit dem Extension Builder gearbeitet wird. Dieser erstellt die CSH-Dateien bereits beim anlegen der Extension unter /Resources/Private/Language/. Insofern braucht man nur noch die Beschreibungstexte tippen und hineinkopieren.

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

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

Ich gebe zu, ich habe nicht jede Extension des TER ausprobiert, die Facebook, Twitter & Co in ihrem Namen hat, aber doch ein paar.  Das Ziel der Extension ist allerdings, alles bzw. soviel wie möglich unter einen Hut zu bekommen. Die Extension steckt von den Featuren her noch in den Kinderschuhen, die Planungen sind allerdings schon weiter fortgeschritten.

Aktuelle Features:

• Share Buttons für Facebook, Twitter, Google+ auf Basis von Extbase  & Fluid.
• Integration der 2click-Variante von heise.de
• Gut dokumentierte ViewHelper, die sich auch problemlos in andere Extensions integrieren lassen.

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

Die Extension “news” basiert auf Extbase & Fluid und ist für mich der Nachfolger von tt_ news, ist von dieser aber komplett unabhängig. Die wichtigsten Links:

• Forge: http://forge.typo3.org/projects/extension-news/issues
• Git: http://git.typo3.org/TYPO3v4/Extensions/news.git

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

Aus diesen Gründen habe ich vor kurzem mit der “Google Services” Extension begonnen (TER). Der erste Service ist eine saubere und erweiterbare Sitemap Integration, welche ich euch vorstellen will. Zudem Suche ich weitere Möglichkeiten und Ideen für die Google Service Erweiterung. Doch wie wird eine Sitemap erstellt?

Extension Integration

Nach der Installation sollte das Static Template der Extension integriert werden. Es wird eine neue Seite angelegt (es wird keine eID-Funktionalität für die Google Sitemap benutzt) und das Sitemap Plugin auf der Seite platziert. Es wird der passende Provider ausgewählt und die Daten-Quelle bestimmt. Nach einem “Speichern und Anschauen”, kann die generierte Erweiterung eingesehen werden. Die Extension baut dabei vollständig auf ExtBase / Fluid auf und versucht das Problem der Sitemap Generierung so weit wie möglich zu abstrahieren.

Eigene Sitemap Erstellen

Hierbei wird es interessant. Weder Hooks noch XClass sollte hier eine Rolle spielen. Stattdessen habe ich an eine aktive Registrierung ähnlich des Scheduler gedacht. Die Erweiterbarkeit der Sitemap liegt in dem SitemapProvider Service. Der SitemapProvider lässt sich aus jeder Extension befüllen und um weitere Provider ergänzen. Hier ein Beispiel:

Anpassungen an eurer ext_localconf.php:

if(t3lib_extMgm::isLoaded('google_services')) {
require_once(t3lib_extMgm::extPath('google_services', 'Classes/Service/SitemapProvider.php'));
Tx_GoogleServices_Service_SitemapProvider::addProvider(t3lib_extMgm::extPath('yourkey', 'Classes/Service/SitemapProvider/ModelName.php'), 'Tx_Yourkey_Service_SitemapProvider_ModelName');
}

Eine neue Klasse z.B. Classes/Service/SitemapProvider/ModelName.php

class Tx_Yourkey_Service_SitemapProvider_ModelName implements Tx_GoogleServices_Service_SitemapProvider_SitemapProviderInterface {
 
    public function getRecords($startPage, $basePages, Tx_GoogleServices_Controller_SitemapController $obj) {
        $nodes = array();
 
        // Build up a $nodes Array of Tx_GoogleServices_Domain_Model_SitemapNode Objects
        // Use $obj->getUriBuilder() to build valid FE URLs (incl. RealURL)
 
        return $nodes;
    }
}

Ist die Klasse und der SitemapProvider passend bestückt, dann könnt Ihr den Provider nun mit in dem Plugin auswählen.

Was haltet ihr von diesem Ansatz? Video Sitemaps, News Sitemaps, Geo Sitemaps und Image Sitemaps sind in Arbeit. Weitere Idee und Ergänzungen sowohl in der Struktur als auch in der Funktionalität sind herzlich willkommen. Einfach kommentieren! Achtung: Die Extension befindet sich noch im Beta Status. Ihr findet die Extension bereits im TER.

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

• MM DAM – FEFileList (mm_dam_filelist)
• Events (julle_events)
• WEC Staff Directory (wec_staffdirectory)
• TGM news (tgm_news)
• TGM media (tgm_media)
• TGM calendar module (tgm_cal)
• DAM Lightbox (damlightbox)
• Download system (sb_downloader)
• iwbase (iwbase)
• Fussballtippspiel (toto)
• Font resizer (fontsizer)
• Adminer (t3adminer)

Wenn Ihr betroffende Erweiterungen einsetzt heißt es wie immer, updaten oder eine andere Lösung finden…

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