GEO Position

Für die Ermittlung einer GEO Position anhand einer IP Adresse, gibt es natürlich auch Erweiterungen, welche diese Aufgabe erfüllen. Diese müssen jedoch gewartet werden, weil die IP-Bereichs-Datenbanken aktuell gehalten werden müssen. Wer einmal “zwischendurch” eine Position einer IP benötigt, dem ist vielleicht schon mit dieser Methode geholfen.

    /**
     * @param string $ip
     * @return array|null
     */
    public function getPosition($ip = NULL) {
        if ($ip === NULL)
            $ip = t3lib_div::getIndpEnv('REMOTE_ADDR');
        try {
            $urlService = 'http://www.geoplugin.net/php.gp?ip=' . $ip;
            $content = unserialize(t3lib_div::getURL($urlService));
        } catch (Exception $exc) {
            return NULL;
        }
 
        return sizeof($content) ? $content : NULL;
    }

Aktuellen Tabellennamen im ExtBase Repository

Der Abstraktionlayer von ExtBase abstrahiert die Datenbank von TYPO3 vollständig. Wenn jedoch individuelle Abfragen (Statements) aus einem “generellen” Repository abgeschickt werden sollen, dann wird der Tabellenname benötigt – und das natürlich dynamisch! Diese Methode holt sich den Tabellennamen aus den DataMappern, sodass sich auch Abfragen, mit von Hand geschriebenen SQL Queries, ein bisschen besser abstrahieren lassen (wenn überhaupt möglich ).

    /**
     * Return the current tablename
     *
     * @return string
     */
    protected function getTableName() {
        return $this->persistenceManager->getBackend()->getDataMapper()->getDataMap($this->getRepositoryClassName())->getTableName();
    }

Fluid Label mit Error Klasse

Mit diesem ViewHelper könnt ihr auch für eure Labels in Formularen eine ErrorClass definieren. Einfach mit…

<yourkey:form.label property="yourProperty">Name</yourkey:form.label>

… auch das Label-Tag an die Property binden. Wenn die Eigenschaft eures Model dann im Validator zu einem Fehler führt, wird neben dem Formular-Feld auch das Label-Tag mit der passenden errorClass versehen.

class Tx_YourExtensionName_ViewHelpers_Form_LabelViewHelper extends Tx_Fluid_ViewHelpers_Form_AbstractFormFieldViewHelper {
 
    /**
     * @var string
     */
    protected $tagName = 'label';
 
    /**
     * Initialize the arguments.
     *
     * @return void
     */
    public function initializeArguments() {
        parent::initializeArguments();
        $this->registerArgument('errorClass', 'string', 'CSS class to set if there are errors for this view helper', FALSE, 'f3-form-error');
        $this->registerUniversalTagAttributes();
    }
 
    /**
     * Renders the textfield.
     *
     * @return string
     */
    public function render() {
        if (strlen($this->arguments['property'])) {
            $this->setErrorClassAttribute();
            $this->tag->addAttribute('for', $this->arguments['property']);
        }
        $this->tag->setContent($this->renderChildren());
        return $this->tag->render();
    }
 
}

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

Hier möchte ich euch gerne mit den häufigst gebrauchten Snippets Abhilfe verschaffen.

Das wichtigste zuerst: sämtliche Konfigurationen der Dateiliste sind per TypoScript im Setup-Teil des Templates vorzunehmen und finden im tt_content.uploads.20 Bereich statt. Dank des mittlerweile standardmäßig vorhandenen TypoScript Editor im Backend sind zwar schon viele Einstellungen per “Suggest Drop-Down” zu erahnen, aber halt doch nicht immer so durchsichtig.

Sinnvolle Dateigrößen-Bezeichnungen einpflegen:

tt_content.uploads.20.itemRendering.30.bytes.labels = Byte | KB | MB | GB

Dateiendung (*.pdf, *.doc, etc.) verstecken:

tt_content.uploads.20.stripFileExtensionFromLinkText = 1

Thumbnail-Generierung beeinflussen:

tt_content.uploads.20.linkProc.iconCObject.file.maxH = 100 #maximale Höhe der Thumbnails
tt_content.uploads.20.linkProc.iconCObject.file.maxW = 100 # maximale Breite der Thumbnails
# etc.

Bestimmen welches Frame eines GIFs bzw. welche Seite eines PDFs angezeigt werden soll:

tt_content.uploads.20.linkProc.iconCObject.file.maxH = 100 #maximale Höhe der Thumbnails
tt_content.uploads.20.linkProc.iconCObject.file.frame = 2 # zweite Seite eines PDFs als Thumbnail generieren

Viel Spaß beim Experimentieren!

------------------------------------------------------
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!

1. Backend-Layout anlegen

Als erstes im System-Ordner, den man bei “Allgemeine Datensatzsammlung” der Root-Seite angegeben hat, einen neuen Datensatz vom Typ “Backend-Layout” anlegen. Man vergibt einen Titel (z. B. Startseite oder Unterseite) und  öffnet über “Konfiguration” den sog. “Grid wizard”. Dort lässt sich dann ein Backend-Layout zusammen klicken, das in meinem Fall auch die Ausgabe im Frontend widerspiegelt.

Die einzelnen Bereiche lassen sich noch benennen und mit Spaltennummern (colPos) versehen.

2. Backend-Layout auswählen

Nach dem Speichern, kann dieses Backend-Layout bereits in den Seiteneigenschaften einer Seite ausgewählt werden. Dazu einfach den Reiter “Erscheinungsbild” anklicken.

Man kann das Backend-Layout für die aktuelle Seite und für deren Unterseiten einstellen. Nach der Auswahl zeigt das Backend direkt die vorher getroffene Konfiguration an – und zwar in korrekter Spalten- und Zeilen-Aufteilung.

Somit wäre das Backend schon mal fertig konfiguriert. Bei Bedarf kann man sich natürlich noch weitere Backend-Layouts bzw. Seiten-Templates anlegen.

3. Die Verknüpfung mit dem Frontend

Um die angelegten Backend-Layouts mit der Ausgabe zu verknüpfen, benötigt man nur folgendes Typoscript Setup:

page = PAGE
page.10 = FLUIDTEMPLATE
page.10 {
	file.stdWrap.cObject = CASE
	file.stdWrap.cObject {
		# slide the template
		key.data = levelfield:-1, backend_layout_next_level, slide
		key.override.field = backend_layout
		# default template file
		default = TEXT
		default.value = fileadmin/templates/index.html
		# template file for backend-layout with ID 2
		2 = TEXT
		2.value = fileadmin/templates/subpage.html
	}
}

Im obigen Beispiel wird abhängig vom gewählten Backend-Layout, eine entsprechendes Template-Datei verwendet. Ich habe ein Standard-Template (default) angegeben und ein Template für das Backend-Layout mit der ID 2. Bei weiteren vorhanden Backend-Layouts, kann diese Liste natürlich erweitert werden. Dazu nur die korrekte ID benutzen.

4. Inhalte für die Ausgabe im Template bereitstellen

Wer von Templavoila kommt, dürfte z. B. die Navigation immer per “TypoScript Object Path” eingebunden haben. Die gute Nachricht: diese können beibehalten und direkt im Template aufgerufen werden. Aber wie kommt man an die Inhaltsbereiche? Mit Templavoila wurden diese als “Content Elements” gemapped. Jetzt benötigt man hier ein wenig Typoscript. (Ich gehe davon aus, dass CSS Styled Content benutzt wird.)

lib.field_content < styles.content.get
lib.field_content.select.where = colPos = 2

Hier auf die korrekte Angabe der colPos achten. Je nach Anzahl der Inhaltsbereiche, muss diese Anweisung natürlich “vervielfältigt” werden.

5. Die Template-Datei

Die Template-Datei, die im “fileadmin” liegt, beinhaltet dann vom Prinzip nur noch den Inhalt des <body> Bereichs. Den Rest baut TYPO3 ja automatisch drum herum. Das HTML-Template könnte dann z. B. so aussehen:

<div id=”header”>
<f:cObject typoscriptObjectPath=”lib.field_navmain” />
</div>
<div id=”content”>
<f:cObject typoscriptObjectPath=”lib.field_content” />
</div>

In diesem Beispiel benutze ich nur den <f:cObject> View-Helper von Fluid, um direkt auf die im Typoscript angelegten Content-Objekte zuzugreifen. Fluid aber auch Fluidtemplate bieten natürlich noch viele weitere Möglichkeiten, mit denen man sein Template anreichern kann.

Und hier sind wir schon am Ende. Mehr ist nicht nötig.

Fazit

Im Vergleich zu Templavoila bin ich mit dieser Template-Methode um einiges schneller, da das aufwändige Mapping wegfällt. Und das Anlegen der extra Backend-Layouts für Templavoila-Templates spart man sich dadurch auch.

------------------------------------------------------
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!

Genauso wie der Hook besteht das Signal/Slot Pattern aus zwei Bausteinen. Auf der einen Seite sind die Slots (Connector, Listener) und auf der anderen Seite die Signale (Dispatcher). Beide Funktionalität sind über die Klasse “Tx_Extbase_SignalSlot_Dispatcher” erreichbar, welche wir uns zuerst erstellen müssen. Dies geht entweder über Dependency Injection (z.B. im Controller):

/** 
 * @var Tx_Extbase_SignalSlot_Dispatcher
 */  
protected $signalSlotDispatcher;  
 
/** 
 * @param Tx_Extbase_SignalSlot_Dispatcher $signalSlotDispatcher 
 */  
public function injectSignalSlotDispatcher(Tx_Extbase_SignalSlot_Dispatcher $signalSlotDispatcher) {  
    $this->signalSlotDispatcher = $signalSlotDispatcher;  
}

oder aber auch über einfaches erstellen der Instanz:

$this->signalSlotDispatcher = t3lib_div::makeInstance('Tx_Extbase_Object_Manager')->get('Tx_Extbase_SignalSlot_Dispatcher');

Im Anschluss verfügt ihr über ein “Tx_Extbase_SignalSlot_Dispatcher” Objekt mit dem ihr nun Signale senden oder Slots registrieren könnte. Im Folgenden nun die beiden Sichten, welche möglich sind.

Dispatch / Signal

Beispiel: Am Ende eurer Action stellt ihr alle nötigen Variablen der View bereit. Nun befindet ihr euch an einer Stelle, welcher gern erweitert wird, weshalb ihr euch für ein “Signal” entscheidet. Das Signal wird über den Signal/Slot-Dispatcher getriggert und kann von anderen Extensions benutzt werden, um die eigene Action zu ergänzen. Hier der Beispielcode:

$this->signalSlotDispatcher->dispatch(__CLASS__, 'beforeRenderView', array($data, $this));

Die Funktion hat drei Parameter “Klassenname”, “Signalname” und “Parameter”. Der Klassennamen ist ähnlich einem Namespace zu betrachten. “__CLASS__” macht hier meistens Sinn – möglich wäre aber auch “get_class($this)”. Achtung/Tipp: Letzteres hat einen interessanten Vererbungseffekt, sodass eine vererbte Klasse automatisch andere Signale schickt als die Klasse von der geerbt wurde. Evtl. Tricky, deshalb empfehle ich anfangs “__CLASS__”.
Der Signalname ist frei wählbar und sollte die Position und Funktion beschreiben. Bei den Parametern sollten alle nötigen Parameter übergeben werden, sodass diese von einem Externen gut verarbeitet werden können.

Connect / Slot

Beispiel: Wir haben die Action (oben) gesehen und wollen die von außen (aber auch in der selben Extension wäre es möglich!) bearbeiten. Dazu erstellen wir uns ebenfalls den Signal/Slog-Dispatcher und registrieren eine Callback-Function (Slot / Listener) für das Signal. Hierzu gibt es verschiedene Möglichkeiten:

Anonym mit einem Closure,

$this->signalSlotDispatcher->connect(  
      'Tx_Extension_Controller_NameController', 'beforeRenderView', function($data, $obj) { /* ... */ }, NULL, FALSE  
);

eine Methode aus dem aktuellen Objekt oder

$this->signalSlotDispatcher->connect(  
     'Tx_Extension_Controller_NameController', 'beforeRenderView', $this, 'addInformation', FALSE  
);

eine Methode aus einem anderen Objekt.

$this->signalSlotDispatcher->connect(  
     'Tx_Extension_Controller_NameController', 'beforeRenderView', 'Tx_OtherExtension_Controller_NameController', 'addOtherInformation', FALSE  
);

Wie ihr seht sind die ersten beiden Parameter identisch zu dem “Signal-Aufruf”. Diese diesen der Identifikation des Signals. Über die beiden folgenden Parameter wird die Callback-Funktion gesteuert. Der letzte Parameter (welcher hier auf FALSE steht) kann auf TRUE gesetzt werden, wenn ihr in der Slot-Klasse zusätzliche Informationen über das Signal benötigt. Diese stehen dann als erster Parameter in der Zielfunktion zur Verfügung.

Fazit

Ein wirklich schönes Pattern – sauberer und einheitlicher als die “üblichen” Hooks. Gerade bei den Hooks war störend, das viele mit “User”-Functions benutzt werden mussten, weshalb die Klassen mit “user_” beginnen mussten. Das neue Pattern ist leicht zu bedienen und schlank im Einsatz. Felix, Vielen Dank dafür. Weitere Informationen bekommt ihr in der API.

Vielen Dank für die Inspiration: blog.tolleiv.de und blog.foertel.com

------------------------------------------------------
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!

Die Google Wetter API ist leider nicht dokumentiert, ist eigentlich auch nur für die Weather-Widgets in iGoogle gedacht. Die Standard-API liefert zudem nicht unbedingt hübsche Icons. Vorteil ist allerdings, dass Sie eine Wetter-Vorhersage über mehrere Tage liefert. Glücklicherweise ist es nicht so schwer die Wetter-Vorhersage auf der eigenen TYPO3-Website anzuzeigen und dazu eigene Symbole zu verwenden.

Man kann natürlich extra eine kleine TYPO3-Extension schreiben, ist aber unnötig, da ja keine Daten (in der Datenbank) gespeichert werden müssen. Es genügt, wenn man eine sogenannte User-Function schreibt und diese per Marker in die Website einfügt. Unsere User-Function ist auch schon so vorbereitet, dass man eigene Wetter-Icon verwenden und die Location einfach im TYPOscript editieren kann, aber dazu später mehr.

Schritt 1: Marker in HTML-Template einfügen

An die Stelle wo später das Wetter-Modul ausgegeben werden soll, wird ein Marker im Template angelegt, z.B.:

<div>###WETTER###</div>

Schritt 2: Marker im TYPOscript enbinden

In dem Tutorial verwenden wir ein klassisches TYPO3 Marker-Template und fügen den Marker im page-Objekt hinzu, in meinem Fall:

page.10 = TEMPLATE
page.10 {
  ...
  marks {
    WETTER < lib.weather
    ...
  }
}

Schritt 3: Die PHP User-Funktion für die Google-Wetter API Abfrage

Zwingend notwendig für das Einbinden einer eigenen PHP-Datei über eine User-Function in TYPO3 sind folgende 3 Punkte:

•    Dateiname beginnt mit “user_”
•    Die PHP-Datei enthält eine Klasse die mit “user_” beginnt
•    die PHP-Funktion übergibt mit “return” die Inhalte an TYPO3

Schritt 4: User-Function in TYPO3 einbinden

Die User-Function wird jetzt in TYPO3 eingebunden und über die Variablen konfiguriert

/**
* lib.weather
* @description:    wetter ausgabe in html
*/
includeLibs.weather = fileadmin/scripts/user_weather.php
 
lib.weather = USER
lib.weather {
  userFunc = user_weather->get
  poi = Hamburg
  path = /fileadmin/templates/img/wetter-icons/
  png = 1
}

Im cObject USER können wie schon erwähnt Variablen definiert werden. Für die Location, für den das Wetter über die Weather-API abgerufen werden soll, füllt man die Variable “poi” mit dem Ort, in unserem Fall “Hamburg”. Zudem kann man in “path” den Pfad zu den eigenen Wetter-Symbolen angeben. Ist die Variable nicht gefüllt, werden die Standard Wetter-Symbole von Google verwendet.

Folgende Wetter-Zustände kennt die Google Wetter API (Quelle: www.web-spirit.de):

chance_of_rain
sunny
mostly_sunny
partly_cloudy
mostly_cloudy
chance_of_storm
showers
rain
chance_of_snow
cloudy
mist
storm
thunderstorm
chance_of_tstorm
sleet
snow
icy
dust
fog
smoke
haze
flurries

Wir haben unsere eigenen Wetter-Icons als PNG-Grafiken mit Alpha-Transparenz abgespeichert. In diesem Fall muss die Variable “png” auf 1 gesetzt werden, weil dann die Wetter-Dateiendungen von GIF auf PNG in der user_weather.php umgeschrieben wird.

Ein schönes Wetter-Icon Set findet man bei graphicriver.net.

Demo-Screenshot

Nachdem das fertige Wetter-Modul mit CSS gestaltet wurde, sieht es so aus:

Download

PHP-Datei als TXT-Version zum Download: user_weather.php.txt

Hinweis

Da es keine offizielle Google API ist, ist es nicht sicher wie lange die API noch zur Verfügung steht und ob die Verwendung für die eigene Website erlaubt ist. Bisher sind im Web dazu weder positive noch negative Meinungen zu finden. Wer dazu mehr weiß, kann gerne einen Kommentar posten. Habt ihr die Google Weather API schon in Projekten eingesetzt? Wer Verbesserungsvorschläge für die PHP-Userfunc hat, bitte kommentieren! Ich hatte dabei Unterstützung von Anja, danke dafür!

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

Das TypoScript trennt dann mit dem “substring” den alten Pfad ab und setzt mit dem “innerWrap” einen neuen Pfad vor das Bild. Mit dem HTMLParser werden dann die “height” und “width” Attribute gelöscht, sodass die Größe durch die Datei selbst bestimmt wird. Auch wenn das Auseinanderschneiden des HTML nicht sauber ist, war es die einzig funktionierende Möglichkeiten eigene Icons für verschiedene Datei-Typen bereitzustellen (nur für tt_news).

plugin.tt_news.newsFiles {
  target = _blank
  size.wrap = <span>|</span>
  stdWrap {
    substring = 49
    innerWrap = <img src="fileadmin/images/icons/ |
    HTMLparser = 1
    HTMLparser {
      allowTags = a,img,span
      tags.img.fixAttrib.width.unset = 1
      tags.img.fixAttrib.height.unset = 1
    }
  }
}

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

Dieser Artikel soll einen kurzen Einblick geben, wie leicht sich das Modul um eigene Berichte erweitern lässt.

Die System Extension reports liefert zwei Interfaces mit, je nach dem, was man tun möchte.

interface tx_reports_StatusProvider { }

tx_reports_StatusProvider wird verwendet, wenn man sich in den bestehenden Statusbericht einklinken möchte und diesen um einen eigenen Test erweitern möchte.

interface tx_reports_Report { }

Mit tx_reports_Report kann ein komplett eigenständiger Bericht erstellt werden.

Statusbericht erweitern

In der eigenen Extension wird eine Datei class.tx_myext_report_mystatus.php angelegt, der Ordnung halber idealerweise in einem Unterordner “reports”. Die Grundstuktur kann so aussehen:

class tx_myext_report_MyStatus implements tx_reports_StatusProvider {
	/**
	 * Constructor for class tx_myext_report_MyStatus
	 */
	public function __construct() {
		$GLOBALS['LANG']->includeLLFile('EXT:myext/report/locallang.xml');
	}
 
	/**
	 * do custom check
	 *
	 * @see typo3/sysext/reports/interfaces/tx_reports_StatusProvider::getStatus()
	 * @return array
	 */
	public function getStatus() {
		$reports = array();
 
		$status = t3lib_div::makeInstance('tx_reports_reports_status_Status',
			$GLOBALS['LANG']->getLL('title'),
			$GLOBALS['LANG']->getLL('value'),
			$GLOBALS['LANG']->getLL('message'),
			tx_reports_reports_status_Status::OK
		);
 
		$reports[] = $status;
 
		return $reports;
	}
}

Außer der im Beispiel verwendeten Severity OK gibt es noch WARNING, ERROR, INFO und NOTICE.
Damit die neue Klasse von TYPO3 erkannt wird, muss noch eine ext_autoload.php erstellt werden. Über die Extension extdeveval kann man das auch automatisch erledigen lassen.

Zum Schluss muss nur noch in ext_tables.php der neue Status Provider registriert werden:

if (TYPO3_MODE == 'BE') {
	$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']['tx_reports']['status']['providers']['myext'] = array('tx_myext_report_MyStatus');
}

eigenständiger Bericht

Für einen neuen Bericht muss ext_tables.php wie folgt erweitert werden:

if (TYPO3_MODE == 'BE') {
	$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']['tx_myext']['myreport'] = array(
		'title'       => 'LLL:EXT:myext/locallang.xml:report_myreport_title',
		'description' => 'LLL:EXT:myext/locallang.xml:report_myreport_description',
		'report'      => 'tx_myext_report_MyReport',
		'icon'        => 'EXT:myext/reports/tx_myext_report.gif'
	);
}

Die dazugehörige class.tx_myext_report_myreport.php sieht dann so aus:

class tx_myext_report_MyReport implements tx_reports_Report {
 
	protected $reportsModule;
 
	/**
	 * constructor for class tx_myext_report_MyReport
	 */
	public function __construct(tx_reports_Module $reportsModule) {
		$this->reportsModule = $reportsModule;
 
		$this->reportsModule->doc->addStyleSheet(
			'tx_myext',
			'../' . t3lib_extMgm::siteRelPath('myext') . 'resources/css/reports/myreport.css'
		);
	}
 
	public function getReport() {
		$content = 'Content of my report';
 
		return $content;
	}
}

Auch hier muss die ext_autoload.php entsprechend angepasst werden.

Fazit

Mit wenigen Zeilen Code können der Statusbericht erweitert oder eigenständige Berichte erstellt werden. Für die Admins von TYPO3 Webseiten bieten die Berichte einen großen Mehrwert, da sie so schnell neue oder geänderte Zustände erkennen können.

Die eingangs genannten Extensions bieten Inspirationen, was man alles machen kann. Viel Spaß beim ausprobieren!

(Achtung: in meinen Code Beispielen hat es die Pfeile zerlegt. &gt; muss entsprechend durch einen Pfeil nach rechts ersetzt werden!)

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

Habt ihr vielleicht Ideen für die Ergänzung oder weitere Ideen für ähnliche Funktionalitäten?!

<?php
 
class Tx_ExtensionName_Utility_Helper {
    /**
     * Call this function at the end of your ext_tables.php to autoregister the flexforms
     * of the extension to the given plugins.
     */
    public static function flexFormAutoLoader() {
        global $TCA, $_EXTKEY;
        $FlexFormPath = t3lib_extMgm::extPath($_EXTKEY) . 'Configuration/FlexForms/';
        $extensionName = t3lib_div::underscoredToUpperCamelCase($_EXTKEY);
 
        $FlexForms = t3lib_div::getFilesInDir($FlexFormPath, 'xml');
        foreach ($FlexForms as $FlexForm) {
            $fileKey = str_replace('.xml', '', $FlexForm);
 
            $pluginSignature = strtolower($extensionName . '_' . $fileKey);
            $TCA['tt_content']['types']['list']['subtypes_excludelist'][$pluginSignature] = 'layout,select_key,recursive';
            $TCA['tt_content']['types']['list']['subtypes_addlist'][$pluginSignature] = 'pi_flexform';
            t3lib_extMgm::addPiFlexFormValue($pluginSignature, 'FILE:EXT:' . $_EXTKEY . '/Configuration/FlexForms/' . $fileKey . '.xml');
        }
    }
 
}

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

Variablen

Man definiert einen Wert, welcher dann an entsprechender Stelle im Code immer wieder eingefügt werden kann.

$black:       #222222;
$blue:        #083672;
$white:       #fff;
$arrow_white: url('../img/arrow_white.png');
$arrow_blue:  url('../img/arrow_blue.png');
body {
  font-family: Arial, Verdana, sans-serif;
  font-size:   0.8em;
  color:       $black;
  text-align:  center;
  background:  $white;
}
 
a {
  display: block;
  background: $blue $arrow_white no-repeat 205px 13px;
}

Nesting

Mit dieser Methode kann man sich super viel Schreibarbeit ersparen. Es werden einfach die Elemente ineinander verschachtelt.

nav {
  position: relative; 
  padding: 0 0  0 240px;
  width: 710px;
 
  li {
    display: inline;
    float: left;
 
    a {
     display: block; 
     float: left;
     margin: 0 10px 0 0;
     font-size: 0.85em;
     }
 
   } /* li */
 
 } /* nav */

Mixins

Mit dieser Methode ist es möglich mehrere CSS-Definitionen einzufügen. Sehr hilfreich z.B. bei den CSS3 Definitionen, die für jeden Browser speziell definiert werden müssen.
Definition Mixin

@mixin verlaufZweiFarben($hauptfarbe, $farbe1) { 
  background: $hauptfarbe; /* Old browsers */
  background: -moz-linear-gradient(top, $hauptfarbe 0%, $farbe1 100%); /* FF3.6+ */
  background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,$hauptfarbe), color-stop(100%,$farbe1)); /* Chrome,Safari4+ */
  background: -webkit-linear-gradient(top, $hauptfarbe 0%,$farbe1 100%); /* Chrome10+,Safari5.1+ */
  background: -o-linear-gradient(top, $hauptfarbe 0%,$farbe1 100%); /* Opera11.10+ */
  background: -ms-linear-gradient(top, $hauptfarbe 0%,$farbe1 100%); /* IE10+ */
  filter: "progid:DXImageTransform.Microsoft.gradient( startColorstr='$hauptfarbe', endColorstr='$farbe1',GradientType=0 )"; /* IE6-9 */
  background: linear-gradient(top, $hauptfarbe 0%,$farbe1 100%); /* W3C */
}

Integration Mixin

article { 
  @include verlaufZweiFarben;
}

Selector Inheritance

Mit dieser Methode ist es möglich Stile zu kopieren, ohne die CSS Eigenschaften zu duplizieren.

.infobox { 
  border: 1px solid #000;
  background: #dddddd;
  color: #000;
  width: 100px;
}

Hier werden jetzt alle Styles, die bereits in “.infobox” definiert wurden integriert.

.teaser { 
  @extend .infobox;
  font-size: 1em;
}

Funktionen

$color: #777777;
#content {
  background:-color: darken($color,20%);
  color: lighten($color,50%);
}
 
Definition als CSS
#content {
  background-color: #444444;
  color: #f6f6f6;
}

Weitere Informationen sind auf der offiziellen SASS Homepage zu finden unter sass-lang.com. Für alle, die die Firebug Extension für den Firefox nutzen, gibt es zudem die Erweiterung FireSass.

SASS in TYPO3

Die Extension sassify unterstützt die Integration von SASS in TYPO3. Einfach herunter laden, installieren, Include static Template einbinden und Ts Code definieren. z.B.:

plugin.tx_sassify_plugin {  
  debugInfo = 0
  showExceptions = 1
  cache = 0
  stylesheets {    
    10 = reset.scss
    10 {
      filenameWrap.wrap = fileadmin/templates/scss/|    
      media = screen    
    }
    20 = screen.scss
    20 {
      filenameWrap.wrap = fileadmin/templates/scss/|    
      media = screen    
    }
    50 = print.scss
    50 {
      filenameWrap.wrap = fileadmin/templates/scss/|    
      media = print    
    }
 
  }
}

Seitenspezifische CSS können einfach mittels Conditions definiert werden

[PIDinRootline = 2]
  plugin.tx_sassify_plugin.stylesheets.21 = home.scss
  plugin.tx_sassify_plugin.stylesheets.21.filenameWrap.wrap = fileadmin/templates/scss/|
[end]

Wer von euch auf den Geschmack gekommen ist und SASS ausprobieren möchte, kann auch ganz einfach seine bisherigen css Dateien umbenennen in .scss und die neuen Sachen Stück für Stück integrieren. Man kann klein anfangen – z.B. erst einmal nur die Farben als Variablen definieren und sich dann allmählich weiter entwickeln. Ich habe mich super schnell dran gewöhnt und mag SASS absolut nicht mehr missen.

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

Dieser neue Seitenbaum bringt einige Vorteile, die aber zum Teil nicht auf den ersten Blick ersichtlich sind. Auf die vielen neuen Features will ich im ersten Adventskalender Türchen eingehen.

Neue Seiten per Drag & Drop anlegen

Die wohl nützlichste Neuerung dürfte das Drag & Drop Feature sein, mit dem sich Seiten anlegen, verschieben, löschen und kopieren lassen. Nach einem Klick auf das Icon mit dem grünen Plus links oben im Seitenbaum erscheint ein Toolbar mit Icons für die verschiedenen Seitentypen. Mit klicken und ziehen kann man das Icon dann an die Stelle im Seitenbaum ziehen, wo eine neue Seite oder ein neuer Ordner angelegt werden soll. Eine dünne grau Linie zeigt die Stelle, an der die neue Seite eingefügt wird. Direkt nach dem Einfügen der Seite in den Seitenbaum wird der Seitenbaum aktualisiert und es erscheint die neue Seite, per Default versteckt. Außerdem hat man direkt im Seitenbaum die Möglichkeit, den Titel der Seite zu setzen, da automatisch ein editierbares Textfeld erscheint.

Seitentitel direkt im Seitenbaum ändern

Auch die Titel von bestehenden Seiten lassen sich im Seitenbaum ganz fix ändern. Dazu muss nur doppelt auf den Seitentitel geklickt werden und voilà, wieder erscheint das Textfeld zum Ändern des Titels. Mit Enter wird die Änderung des Titels bestätigt, mit Escape kann man den Bearbeitungsmodus ohne Änderung verlassen.

Seiten verschieben und kopieren

Um eine Seite an eine andere Stelle im Seitenbaum zu verschieben, zieht man den Seitentitel einfach an die gewünschte neue Stelle und lässt die Seite dort los. Wenn die Seite kopiert werden soll, muss während des Ziehens nur ein Mal die Strg Taste gedrückt werden.

Der Drag & Drop Vorgang kann jederzeit mit der Escape Taste abgebrochen werden.

Löschen von Seiten

Per Drag & Drop können auch Seiten aus dem Seitenbaum gelöscht werden. Während eine Seite gezogen wird, erscheint unterhalb des Seitenbaums eine dunkelgraue Fläche. Dort abgelegte Seiten werden gelöscht. Falls eine Seite dort versehentlich abgelegt wurde, kann der Löschvorgang noch einige Sekunden lang rückgängig gemacht werden. Danach muss der Papierkorb von TYPO3 bemüht werden.

TYPO3 merkt sich den Zustand des Seitenbaums

Wie auch schon in früheren Versionen von TYPO3 merkt sich der Seitenbaum den aktuellen Zustand, also welche Teilbäume ausgeklappt sind. Zusätzlich merkt sich TYPO3 jetzt auch die zuletzt angeklickte Seite und öffnete diese auch nach einem erneuten Login als erstes.

Filtern des Seitenbaums

Ein großartiges neues Feature sind die Möglichkeiten, die Seiten im Seitenbaum zu filtern. Bislang funktionierte die Filterung nur für Seiten, die auch ausgeklappt und somit sichtbar waren. Jetzt wird wirklich der gesamte Seitenbaum durchsucht.

Die Filterfunktion wird über das Filter Icon über dem Seitenbaum gestartet. Sobald mehr als drei Zeichen eingegeben wurden, wird der Filter Modus gestartet und es werden nur noch Seiten im Seitenbaum angezeigt, die die gesuchte Zeichenkette enthalten bzw. der Klickpfad zu diesen Seiten. Die genauen Treffer werden farblich hervorgehoben. Anstelle von Buchstaben können auch Seiten IDs direkt eingegeben werden. In diesem Fall entfällt das drei Zeichen Limit zum Starten des Filter Modus.

Kontext Menü

Zusätzlich zum eigentlichen Seitenbaum wurde auch das Kontext Menü überarbeitet. Es ist über einen Links- oder Rechtsklick auf das Icon oder den Seitentitel aufrufbar. Sofort sichtbar sind die Funktionen, die nicht über die Drag & Drop Funktionalität abgedeckt sind. Dazu gehören die Vorschau, das Aktivieren oder Deaktivieren von Seiten und andere Funktionen. Im Bereich “Seitenaktionen” befinden sich die Funktionen, die auch per Drag & Drop genutzt werden können. Unter “Teilbereichsaktionen” verbergen sich noch nützliche weitere Funktionen wie das Ein- und Ausblenden gesamter Teilbäume inklusiver aller Unterbäume und der Import und Export als t3d Datei.

Das Kontext Menü kann durch eigene Aktionen erweitert werden. Im TYPO3Wiki findet sich ein Artikel mit einer Demo Extension und Beispielcode.

Temporäre Datenbankfreigabe

Wer oft mit umfangreichen Seitenbäumen zu tun hat, wird sich über eine weitere Funktion aus dem Untermenü “Teilbereichsaktionen” freuen. Über den Menüpunkt “Als Startpunkt für den Seitenbaum festlegen” kann eine beliebige Unterseite als Startseite festgelegt werden. Der restliche Seitenbaum wird dann ausgeblendet. Der Zustand der temporären Datenbankfreigabe bleibt natürlich auch nach einem erneuten Login erhalten.

Datenbankfreigaben für Redakteure

Bei Datenbankfreigaben für Redakteure funktionieren alle oben beschriebenen Funktionen genauso.

Eine kleine Verbesserung bietet die Benutzer TypoScript Option “options.pageTree.showPathAboveMounts = 1″. Sie kann sowohl auf Benutzer- als auch auf Gruppenebene benutzt werden und sorgt dafür, dass der Pfad zur jeweiligen Startseite der Datenbankfreigabe über dem Teilbaum angezeigt wird.

Weitere Anpassungsmöglichkeiten über Seiten TS

Bereits beim letzten Adventskalender wurden Möglichkeiten vorgestellt, die Darstellung des Seitenbaums zu beeinflussen (Türchen 3 & Türchen 10). Diese Möglichkeiten funktionieren auch weiterhin (im TS Config Feld der Gruppe oder des Benutzers).

Folgende Optionen gibt es:

• options.pageTree.showPathAboveMounts = 1
  Zeigt wie bereits oben beschrieben den den Pfad einer Datenbankfreigabe an
• options.pageTree.showPageIdWithTitle = 1
  Zeigt die Seiten ID in eckigen Klammern vor dem Seitentitel an
• options.pageTree.showNavTitle = 1
  Zeigt den Navigationstitel statt dem Seitentitel im Seitenbaum an
• options.pageTree.disableIconLinkToContextmenu = 1
  Schaltet die Aktivierung des Kontext Menüs mit der linken Maustaste aus
• options.pageTree.hideFilter = 1
  Versteckt die Filter Funktion
• options.pageTree.showDomainNameWithTitle = 1
  Zeigt den Namen des Domain Datensatzes im Seitentitel an (siehe Screenshot)
• options.contextMenu.table.pages.disableItems =
  Kommaseparierte Liste von Elementen, die nicht im Kontext Menü verfügbar sein sollen (view, disable, enable, edit, info, history, new, cut, copy, pasteInto, pasteAfter, delete, mountAsTreeroot, expandBranch, collapseBranch)
• options.pageTree.doktypesToShowInNewPageDragArea =
  Kommaseparierte Liste von Doktype IDs, die in dem Toolbar mit Icons für neue Seiten angezeigt werden sollen. Default Werte sind 1, 6, 4, 7, 3, 254, 255, 199

Preloading des Seitenbaums

Damit sich der Seitenbaum ohne große Verzögerungen benutzen lässt, wird er zum Teil voraus geladen. Per default sind das 50 Seiten. Der Wert kann über einen Eintrag in der localconf.php verändert werden:

$GLOBALS['TYPO3_CONF_VARS']['BE']['pageTree']['preloadLimit']

Beim Ändern dieses Wertes ist aber Vorsicht geboten, da sich die Anzahl der Datenbankabfragen entsprechend erhöht.

Weiterentwicklung des Seitenbaums

Mit Version 4.6 wurden Bugs behoben und die Performance verbessert. Für TYPO3 4.7 ist die Portierung auf ExtJS 4 geplant.

Sehr praktisch fände ich es, wenn es möglich wäre, die Technologie, die hinter dem neuen Seitenbaum steckt, auch für eigene Bäume nutzen zu können. Dies ist momentan aber leider noch nicht möglich.

Ein großes Dankeschön geht auf jeden Fall an alle Entwickler, die an der Implementierung des neuen Seitenbaums beteiligt waren! Super Arbeit!

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

Vorüberlegungen

Als erstes müssen die Systemvoraussetzungen und die Möglichkeiten des Hosting Pakets geprüft werden. FLOW3 stellt folgende Mindestanforderungen:

• Webserver (Apache mit aktiviertem mod_rewrite Modul wird empfohlen)
• PHP 5.3.2 oder höher (mit den Einstellungen memory_limit >= 128M und magic_quotes_gpc = Off)
• Zugriff auf die Kommandozeile (Shell mit SSH Zugang)
• Eine PDO kompatible Datenbank wie z.B. MySQL

Der Webserver dürfte in den wenigsten Fällen ein Problem darstellen, da nahezu alle Hoster auf Apache setzen und mod_rewrite in den meisten Fällen aktiviert ist. Allerdings muss der Hoster es erlauben, den Document Root für eine (Sub-)Domain frei zu setzen.

Schwieriger wird es bei der PHP Version. Noch nicht jeder Hoster bietet seinen Kunden PHP 5.3 an obwohl es PHP 5.3 jetzt schon seit einiger Zeit in einer stabilen Version gibt.

Nach diesen Vorüberlegungen kann jetzt mit der eigentlichen Installation von FLOW3 gestartet werden.

Download von FLOW

Nach dem Download wird FLOW3 auf dem Webserver entpackt. Am schnellsten geht das über die Shell:
wget http://sourceforge.net/projects/flow3/files/FLOW3/1.0.0/FLOW3-1.0.0.tar.bz2/download -O FLOW3-1.0.0.tar.bz2
tar xjf FLOW3-1.0.0.tar.bz2

Man erhält dann folgende Dateistruktur:

Dateirechte setzen

Das Quickstart Tutorial von FLOW3 schlägt als nächsten Schritt die Anpassung der Dateirechte vor.
In Managed Hosting Umgebungen wird das in der Regel nicht funktionieren, da man keine root Rechte hat und den sudo Befehl nicht nutzen kann.
Bei domainfactory laufen der SSH User und der Webserver unter der gleichen Benutzergruppe, wodurch das Anpassen der Dateirechte in diesem Fall entfallen kann.

Einstellungen über das Kundenmenü

Danach wird der Document Root der (Sub-)Domain auf das Unterverzeichnis Web gesetzt. Bei domainfactory können über das Kundenmenü auch die PHP Version eingestellt sowie PHP.ini Einstellungen verändert werden. Wie schon oben geschrieben sollte das memory_limit auf einen Wert größer 128M gesetzt und magic_quotes_gpc deaktiviert werden. Als PHP Version sollte 5-53LATEST-STANDARD (derzeit v5.3.8) genommen werden.

Zurück auf der Shell

Da domainfactory zum einen mehrere verschiedene PHP Versionen anbieten und zum zweiten auch einen anderen Pfad nutzt, ist eine kleine Anpassung des FLOW3 Shellscripts nötig.
Die erste Zeile in der Datei flow3 muss gegen diese ausgetauscht werden:
#!/usr/local/bin/php5-53LATEST-CLI
Als nächstes muss im Verzeichnis Configuration die Datei Settings.yaml.example nach Settings.yaml kopiert werden. In der Datei werden dann die letzten beiden Zeilen (“core:” und “phpBinaryPathAndFilename”) einkommentiert. phpBinaryPathAndFilename wird dann auf “/usr/local/bin/php5-53LATEST-CLI” gesetzt.

Möglicherweise erhält man später beim Aufruf von FLOW3 über die Shell diese Fehlermeldung:
FLOW3 requires the PHP setting "magic_quotes_gpc" set to Off. (Error #1224003190)
Bei meinen Tests hatte ich dieses Problem. Nach Rückspsrache mit dem domainfactory Support konnte das Problem aber gelöst werden, da magic_quotes_gpc in der neuesten PHP Version bei domainfactory gar nicht mehr enthalten ist, die PHP.ini dies aber behauptet. Die entsprechende Konfigurationsänderung sollte aber jetzt bei allen domainfactory Kunden greifen, so dass es nicht mehr zu dieser Fehlermeldung kommt.

Falls doch, kann man sich mit diesem Workaround behelfen: An den beiden oben genannten Stellen, wo der Pfad zu PHP geändert wird, trägt man folgendes ein:
/usr/local/bin/php5-53LATEST-CLI -d magic_quotes_gpc=Off
Damit wird magic_quotes_gpc explizit abgeschaltet.

Erste Tests

Wenn man alle genannten Schritte ausgeführt hat, kann man FLOW3 das erste Mal über die Shell aufrufen:
./flow3 help
Achtung: der erste Aufruf kann einige Zeit dauern!

Dafür wird man dann mit diesem Ergebnis belohnt:

Danach kann das erste Package mit dem Kickstarter angelegt werden:

./flow3 kickstart:package MyCompany.MyPackage

FLOW3 im Browser

Beim Aufruf von FLOW 3 über den Browser sollte dann diese Seite angezeigt werden:

Nachdem jetzt alle Hürden der Installation von FLOW3 hoffentlich genommen sind, kann man mit der Programmierung des ersten eigenen FLOW3 Pakets starten.

FLOW3 bei anderen Providern

Die Firma jweiland.net bietet ein angepasstes FLOW3 Paket und eine Kurzanleitung an. Auch Mittwald bietet FLOW3 Hosting an. FLOW3 kann über den Softwaremanager (Bereich Frameworks) installiert werden.

Fazit

Mit ein wenig Handarbeit und wenn die Provider PHP 5.3 unterstützen lässt sich FLOW3 auch in Managed Hosting Umgebungen nutzen.

Mich würde jetzt interessieren, welche Erfahrungen ihr bei der Installation und Nutzung von FLOW3 in Managed Hosting Umgebungen gemacht habt. Über Feedback und eure Kommentare freue ich mich.

------------------------------------------------------
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!