Mit ein paar Tricks und einer handvoll Wissen wir dieses Zusammenspiel ein Hort der Freude! Dieser Artikel beschreibt das Zusammenspiel zwischen Versionsverwaltung und Framework.

Das Repository

Auf unserem Entwicklungsserver liegt das zentrale Coderepository. Hier wird es zum Projektstart angelegt und jeder beteiligte Entwickler kriegt bei bedarf Zugriff darauf. Zum starten wird nur eine leere Datei versionisiert, der Projektleiter legt dann alle benötigten Grundlagen von seinem Rechner aus an.

# Auf dem Server

$ mkdir PROJEKT.git

$ cd PROJEKT.git

$ touch init.txt

$ git init

$ git add .

$ git commit -m "Init"

Auf dem eigenen Rechner wird vom Projekt (eventuell per VPN von zuhause) eine Arbeitskopie erstellt.

# Zuhause

$ cd Ordner_fuer_alle_Projekte

$ git clone gitosis@SERVER:git/PROJEKT.git

Beim clonen legt git einen neuen Ordner mit dem Namen des Projektes an.

CakePHP

Im ersten Schritt werden alle Cake Dateien in den Ordner kopiert. Anschließend werden die benötigten Tabellen in der Datenbank angelegt. Über die Cake Console werden dann alle benötigten Dateien gebacken.

$ cd cake/console/

$ ./cake bake

Jetzt kommt der Trick! Um in Zukunft jeden Stress mit der Datenbank zu vermeiden, backt man das Datenbankschema mit in die Cake Applikation.

$ ./cake schema generate

Mit diesem Befehl liest Cake die Datenbank aus und legt die Struktur in der PHP Datei unter /config/schema/schema.php ab. Ändert ein Entwickler eine Tabelle auf seinem Rechner, muss er das Schema neu erstellen und in Git bekannt machen.

$ ./cake schema generate

$ cd ../..

$ git add .

$ git commit -m "Einiges ist passiert, inkl. neuer Datenbank"

Der Kollege oder alternativ der gleiche Entwickler zuhause holt sich die neuste Version vom Server und aktualisert mit Cake Magie seine Datenbank.

$ git pull

$ cd cake/console

$ ./cake schema update

Fertig ist die Datenbank!

Dateien ignorieren

Beim initialen anlegen macht es Sinn, Git einige Dateien und Ordner zu entziehen, die nicht versioniert werden müssen, da sie bei jedem Entwickler individuell vorhanden sind. Dafür legt man im Root Verzeichnis vom Projekt eine Datei Names .gitignore an.

Hier werden Dateien und Ordner festgehalten, die nicht eingebunden werden:

app/tmp/

config/database.php

Cache Dateien anlegen

Das Problem ist bei der oben verwendeten .gitignore Datei, dass die Caches leer sind und keine Zugriffsrechte darauf bestehen. Deshalb muss man beim erstellen des Projekts die nötigen Ordner anlegen und die entprechenden Zugriffsrechte vergeben.

# cd app/

# mkdir tmp

# mkdir tmp/cache/

# mkdir tmp/cache/models/

# mkdir tmp/cache/persistent/

# sudo chmod -R 777 tmp/

Nach dem das Administratorpasswort eingegeben wurde, wird eine sehr freundliche Berechtigung gesetzt (die zum testen okay ist, auf dem Liveserver aber tabu!) und Cake kann in die Order schreibenn. Da der Ordner aus der Versionisierung ausgeschlossen wurde, muss man diesen Schritt zum Glück nur ein einziges mal durchführen.

Die Datenbank

Weil ein frisch geclontes Cake Projekt noch keine Datenbankverbindung besitzt, muss man als erstes eine neue Datenbank über phpMyAdmin o.ä. erstellen. Anschließend wechselt man in die Konsole und erstellt anhand des Schemas alle benötigten Tabellen.

$ cd cake/console

$ ./cake bake

Da keine Datenbankverbindung besteht, werden die Zugangsdaten abgefragt. Anschließend

$ ./cake schema create

Jetzt noch die zwei Fragen mit y bestätigen und schon liegen alle Tabellen ordentlich in der frisch angelegten Datenbank.

Fazit

Was benutzt ihr um Demoinhalte zu übertragen? Im Schema gibt es zwei Callbacks: before() und after(); ich fürchte die werden beim neugenerieren überschrieben.

Ansonsten bleibt nur noch frohes Entwickeln zu wünschen übrig. Frohes entwickeln!

echo Configure::read('Hello.World');

Das funktioniert vom Model, über den Controller bis zum View. Wäre es nicht wunderbar auf die gleiche Art und Weise auf den angemeldeten Benutzer zugreifen zu können? Ich denke da an:

echo User::get('name');

Ja, wäre es und funktioniert ganz einfach. Die Idee stammt von Matt Curry und ist in seinem kostenlosen Cake Buch auf englisch beschrieben. Im Laufe der Zeit hab ich die Funktionen erweitert und angepasst.

Das User Model

Hier beginnt die Arbeit. Die Grundlage ist die Funktion getInstance() mit deren Hilfe die Daten gespeichert werden und sicher gestellt wird, dass immer die richtigen Daten zurück gegeben werden:

function &getInstance($user = null) {

  static $instance = array();

  if ($user) {

  [tab]$instance[0] =& $user;

  }

  return $instance[0];

}

Um neue Daten hinzuzufügen habe ich die Funktion store() erstellt. Diese kann beliebig oft aus dem Controller aufgerufen werden. Neue Daten ersetzen alte Inhalte. Mit Hilfe dieser Funktion kann man nachträglich noch einzelne Daten hinzufügen.

function store($data) {

  $user = User::getInstance();

  $user = Set::merge($user, $data);

  User::getInstance($user);

}

Und natürlich die Funktion um Daten auszulesen:

function get($path = '') {

  $_user =& User::getInstance();

  if(empty($path)) {

  [tab]return $_user;

  }

  $path = str_replace('.', '/', $path);

  if (strpos($path, 'User') !== 0) {

  [tab]$path = sprintf('User/%s', $path);

  }

  if (strpos($path, '/') !== 0) {

  [tab]$path = sprintf('/%s', $path);

  }

  $value = Set::extract($path, $_user);

  if (!$value) {

  [tab]return false;

  }

  return $value[0];

}

Wie man sieht wird mit der Funktion Set::extract() aus den gespeicherten Daten gelesen. Die Core Utilities sind einfach großartig. Unbedingt durchstöbern!

Im App Controller

Hier werden die Daten vom angemeldeten Benutzer gesetzt. Als erstes muss natürlich das Model importiert werden, unabhängig von einer Anmeldung. Damit alle Controller mit den Daten arbeiten können, gehört der folgende Code in die Funktion beforeFilter().

App::import('Model', 'User');

$User = new User;

Als nächstes wird geprüft ob der Benutzer angemeldet ist. Wenn das der Fall ist, werden die Benutzerdaten aus der Session ins Model geschrieben:

if($this->Session->check('Auth.User')) {

  $User->store($this->Session->read('Auth'));

}

Hat man im Laufe der Abarbeitung der Anfrage noch weitere Informationen vom Benutzer gesammelt oder errechnet, kann man die einfach hinzufügen:

$User->store(array('is_cool' => true));

Überall

Überall, im View, im Controller oder im Model kann jetzt auf die Benutzerdaten zugegriffen werden:

echo User::get('User.name');

echo User::get('email');

Ich mag diese Form sehr! Sie ist schön, kurz und einprägsam. Man kann sie auch noch vielfältig erweitern.

Sehr schöne Erweiterung

Kaum können sich Benutzer anmelden, sollen sie verschiedene Rechte auf einer Plattform haben. Mit den oben beschriebenen Grundlagen erreicht man schon sehr viel. Noch besser wird es, wenn man eine Funktion check() im Model hinzufügt um auf das vorhanden sein von Feldern zu prüfen.

function check($path) {

  $value = User::get($path);

  if (!$value || empty($value) || $value === false) {

  [tab]return false;

  }

  return true;

}

Damit kann man schon gut lesbare Abfragen schreiben.

if(User::check('is_cool')) { /* usw. */ }

Aber so richtig sauber sieht das nicht aus. Und was passiert wenn es mehrere Rollen gibt die der Nutzer einnehmen kann? Dann wäre eine is() Funktion wesentlich schöner.

if(User::is('cool')) //ist der benutzer cool?

if(User::is('cool', 'okay')) //ist der benutzer cool oder okay?

Das sieht nett aus! Und der Schlüssel/die Funktion ist einfach implementiert. Im User Model einfach folgendes hinzufügen:

function is() {

  $roles = func_get_args();

  foreach($roles as $role) {

  [tab]if(User::check('User.is_'.$role)) {

  [tab]  return true;

  [tab]}

  }

  return false;

}

Die Rechte werden im Benutzerarray erwartet in der Form is_Rechtename. Im Controller also schnell hinzugefügt:

$User->store(array('is_cool' => 1, 'is_okay' => 1, 'is_bloede' => 0));

Die Funktion is() nimmt den übergebenen Namen, setzt ein is_ davor und prüft ob die Variable in den Benutzerdaten gesetzt ist.

Fazit

Ich finde dieses Pattern einfach großartig und arbeite nur noch damit! Ich hab versucht das ganze in ein Plugin zu packen um nicht jedes mal aus einem alten Projekt die Funktionen rüber zu kopieren, aber es daran gescheitert, dass das Benutzer Model, wenn es statisch aufgerufen wird natürlich nicht mehr seine Behaviors (UserStorage) beinhaltet. Jemand eine Idee?

Passend zum Wetter präsentiert sich das neue Backend ganz in grau.

Und weil Bilder mehr als tausend Worte sagen, besteht dieser Beitrag nur noch aus ein paar Screenshots.

Das neue Installations Tool ist sehr schick geworden.

Die Listenansicht sieht sehr aufgeräumt aus.

Die Icons blenden sich nur noch bei Mouseover ein.

Das Bearbeiten von Inhaltselementen ist übersichtlicher.

Die Kiwi Extensions sind auch verfügbar und funktionieren anscheinend ganz gut.

Benutzer lassen sich jetzt vielfältig filtern und sortieren.

Soviel zu ein paar Eindrücken aus dem neuen, schönen Backend. Den Download gibt es auf den offiziellen Downloadseiten. Ich bin gespannt auf eure Meinung.

Welche das sind, wie sie eingebaut und verwendet werden, ist das Thema dieses Artikels.

Im App Controller

Alles fängt im Controller an. Meine erste Tat ist jetzt stets einen App Controller anzulegen. Der liegt im Verzeichnis /app/ und definiert eine Reihe von Grundlagen.

class AppController extends Controller {

  var $components = array('Auth', 'Session', 'RequestHandler');

  var $helpers = array('Form', 'Html', 'Javascript', 'Time', 'Text', 'Layout');

}

Die Components Auth und Session sind wahrscheinlich schon hinreichend bekannt. Der RequestHandler ist mein bester Freund, denn er beinhaltet alle Informationen über den aktuellen Aufruf. Mit seiner Hilfe ist es zum Beispiel möglich zu erkennen ob es sich um einen asynchronen Aufruf handelt oder um ein mobiles Endgerät.

Die Helper sollten auch soweit klar sein, bis auf Layout. Der ist nicht im Core enthalten sondern in der Bakery verfügbar. Mit diesem Helper im Projekt ist  Template Inheritance möglich. Das heißt man definiert im Layout (/app/views/layouts/default.ctp) einen Block, zum Beispiel den Footer.

<div id="footer">

  <? $this->Layout->output($footer_for_layout, $this->element('default_footer')); ?>

</div>

Im Element default_footer (/app/views/elements/default_footer.ctp) befindet sich der Standardfooter. Und den überschreibt man im Bedarf einfach in einem View:

<?=$layout->blockStart('footer');?>

Ein <strong>neuer</strong> Footer!

<?=$layout->blockEnd();?>

Grandios oder? Der im View definierte Inhalt wird dann im entsprechenden Block im Layout ausgegeben. Das Prinzip habe ich bei Django gesehen und jetzt zum Glück auch in Cake zur Verfügung.

Noch ein Wort zum RequestHandler. In der Funktion AppController::beforeFilter() benutze ich folgende Abfrage um auf einen asynchronen Aufruf zu reagieren:

if($this->RequestHandler->isAjax()) {

  Configure::write('debug', 0);

  if($this->RequestHandler->prefers() == 'json') {

     die(json_encode($this->viewVars));

  }

  else {

     $this->layout = 'ajax';

  }

}

Wenn es sich um einen Ajaxaufruf handelt $this->RequestHandler->isAjax() dann wird als erstes eine Debugausgabe verhindert Configure::write('debug', 0); (das sollte man sich merken!!) und dann überprüft, was für ein Datentyp zurück erwartet wird.

Wenn JSON Code angefordert wird, werden alle Variablen für den View in einem JSON Objekt zurück gegeben, andernfalls wird das Ajax Layout verwendet, welches einfach den View zurück gibt ohne das ganze HTML Gerüst.

Wichtig ist bei der Verwendung dieser Abfrage daran zu denken keine sensiblen Daten an den View zu übergeben und dort zu prüfen ob der Nutzer die Daten sehen darf oder nicht. Aber da wir ja alle strikt dem MVC Pattern folgen, ist das ja auch gar nicht möglich.

Das Layout

Okay, jQuery keine Frage:

echo $this->Javascript->link(array(

  'jquery.min'

));

Die Endung .js kann man sich sparen, Cake sucht die angegebenen Dateien automatisch im Ordner /app/webroot/js/.

Zur angenehmen Verteilung des Inhalts benutze ich jetzt immer das 960.gs CSS Framework. Es gibt einen grandiosen Konfigurator mit dessen Hilfe man sich sehr schnell ein passendes Grid zusammenstellt. Die erzeugte CSS Datei legt man im Ordner /app/webroot/css/ ab und bindet sie mit Hilfe des HTML Helpers ein.

Außerdem benutze ich den CSS Reset von Eric Meyer um eine einheitliche Ausgangslage in allen Browsern zu erreichen. In der Datei layout.css binde ich dann je nach Komplexibilität weitere CSS Dateien über import url() ein.

echo $this->Html->link(array(

  '960',

  'reset',

  'layout'

));

Um in jQuery immer die richtige Baseurl für Ajaxanfragen zur Verfügung zu haben, nutze ich das Base Tag:

<base href="http://<?=env('HTTP_HOST').$this->base?>/" />

HTML Gerüst

Das 960.gs verlangt einen umfassenden Container mit der Klasse container_XX, wobei das XX für die Anzahl der Spalten steht. Was sich außerdem bewäht hat ist, Controller und Action als Klasse auszugeben um per CSS einzelne Ansichten individuell gestallten zu können. In meinem Layout führt das zur folgenden Monsterzeile:

<div id="wrap" class="container_16 <?=$this->params['controller']?> <?=$this->params['action']?> <?=$this->params['controller']?><?=ucfirst($this->params['action'])?>">

Alle Views des Controllers Blogs haben jetzt die Klasse #wrap.blogs. Und jede einzelne View lässt sich mit #wrap.blogsAdd gezielt ansprechen. Außerdem können auch alle Formular zum hinzufügen von neuen Einträgen angesprochen werden: #wrap.add form.

Damit ist man schon sehr flexibel.

Noch ein Satz zu 960.gs: die Aufteilung des Inhalts in Spalten erfolgt über das verteilen von Klassen. Diese haben immer das Format grid_XX, darauf folgt immer ein Container mit der Klasse clear.

<div class="grid_8">Linke Hälfte</div>

<div class="grid_8">Rechte Hälfte</div>

<div class="clear"></div>

Das teilt den Inhalt in zwei gleiche Teile. Es ist über die Klassen pull_XX und push_XX auch möglich Abstände einzufügen. Einfach ein bisschen rumspielen.

Hilfe und Informationen

Alle Core Components und Helper liegen bestens dokumentiert in eurem Projekt! Um schnell zu erfahren wie die verdammte Funktion im RequestHandler heißt, öffnet man einfach die entsprechende Datei in /cake/libs/controller/components/.

Im Verzeichnis /cake/libs/ ist Cake genau so aufgebaut wie im eigenen Ordner /app/. Daran muss man unbedingt denken und diese wertvolle Quelle nutzen. Aber: niemals Änderungen vornehmen!!! NIEMALS. Absolut verboten, denn damit verliert man die Updatefähigkeit. Alle Dateien die man anpacken darf liegen im /app/ Ordner. Wenn man jetzt wirklich nicht drum rum kommt und zum Beispiel im Time Helper etwas ändern muss, dann kopiert man die komplette Datei und legt sie in den Ordner /app/views/helpers/. Jetzt darf man sie verändern wenn es unbedingt sein muss.

Unter http://www.cakephp.org findet man eine ganze Reihe nützlicher Links und Ressourcen, dass ist ja klar. Für deutschsprachige Cake Entwickler bietet sich außerdem noch das CakeForum an, da bin ich auch ab und zu unterwegs.

Fazit

CakePHP ist ein grandioses Framework, die aktuelle Version 1.3 macht großen Spaß und ich kann es kaum erwarten das unsere Projekte endlich das digitale Licht des Internets erblicken.

Infohäppchen gibt es in meinem Twitter Account, richtig gute Hilfe und Unterstüztung leistet die Ape Unit GmbH gegen Bares oder Mitarbeit und wenn du einen Job suchst, dann freue ich mich auf einen Besuch auf unserer Seite der offenen Stellen!

Frohes backen!

Es geht natürlich um den heißen Scheiß: Ajax. Mit aktiviertem JavaScript soll bei einem Klick auf einen Eintrag der Eintrag dynamisch nachgeladen werden anstatt auf die Einzelansicht zu verlinken. Mit TYPO3 und Typoscript baut man sich dafür ein weiteres Page Objekt und passt die Ausgabe an, darüber hatte ich schon berichtet. Bei WordPress gibt es aber kein Typoscript.

Mein erster Gedanke war ein alternatives Template per URL Parameter zu laden in dem nur die Inhalte angezeigt werden. Die Anleitungen waren allerdings allesamt nicht besonders ergiebig. Der nächste Ansatz war den gesamten Inhalt abzufragen und per jQuery nur den entsprechenden Container mit den Inhalten auszugeben. Das finde ich aber irgendwie unelegant.

Und nach einmal drüber schlafen kam dann der rettende und sehr simple Einfall.

functions.php

Mit meinem CakePHP verwöhntem Blick würde ich die functions.php mal mit einer Art Controller vergleichen. Der Aufruf geht also durch diese Datei, in der Variablen gesetzt und Funktionen definiert werden können, die anschließend in den Views zur Verfügung stehen.

Und hier steckt schon das ganze Geheimnis, ist die Servervariable HTTP_X_REQUESTED_WITH gesetztz, handelt es sich um eine asynchrone Anfrage:

if(isset($_SERVER['HTTP_X_REQUESTED_WITH'])) {

  $ajax = true;

}

else {

  $ajax = false;

}

Die Views

In den üblichen Verdächtigen des Themes, damit meine ich die single.php, page.php, index.php usw. steht jetzt die Variable $ajax zur Verfügung. Bisher fand ich die Arbeitsweise von WordPress nicht sehr elegant in jeder Datei Header, Sidebar und Footer einbinden zu müssen, aber jetzt finde ich sie gut. Denn wenn bei einem Ajaxaufruf nur der Inhalt zurück gegeben werden soll, dann lässt man das überflüssige HTML Gerüst einfach draußen:

if(!$ajax) {

  get_header();

}

Fazit

Das war einfach. WordPress ist ein tolles System und ich kann es kaum erwarten endlich die neue Version 3.0 stable zu sehen. Wie das ganze drum herum mit jQuery funktioniert, steht im bereits oben erwähnten Eintrag zu TYPO3. Frohes bloggen!

Dadurch ist es möglich einen Teaserport direkt per Typoscript einzubinden und zum Beispiel einem Marker zuzuweisen. Außerdem kann man mit dieser praktischen Extension jede beliebige Tabelle auslesen!

Einbindung über Typoscript

Nach der Installation steht im Typoscript das Objekt plugin.tx_kiwiteaser_pi1 bereit. Das kann einem Marker zugewiesen werden und über die Eigenschaften content und ports mit Inhalt befüllt werden.

page.10.marks.CONTENT < plugin.tx_kiwiteaser_pi1

page.10.marks.CONTENT {

  content = pages_21, tt_content_123, pages_22, tx_kiwiteaser_content_2

  ports = 4

}

Und zack findet sich im Frontend statt ###CONTENT### ein cooler Kiwi Teaser mit vier Slots und den ausgelesenen Datensätzen, angegeben in content. Das Format ist simpel: Name der Datenbank - Unterstrich - UID des Datensatzes. Extra angelegten Teaserinhalte befinden sich in der Datenbank tx_kiwiteaser_content.

Ansprechen von beliebigen Datenbanken

Wenn man die Inhalte einfach per Typoscript beschreibt, lässt sich natürlich jede beliebige Datenbank ansprechen. Ja, das funktioniert! Damit die Extension weiß, welche Spalten sie auslesen soll, muss man diese per Typoscript bekannt geben. Zum Beispiel könnte man die besten Frontend Benutzer teasern:

plugin.tx_kiwiteaser_pi1 {

tables.fe_users {

  title = name

  content = address

  image = image

}

}

Das Format sollte eigentlich selbsterklärend werden. Der Inhalt aus der Spalte name landet im Marker ###TITLE### usw. Anschließend muss der Datensatz nur noch dem Teaser zugewiesen werden. Dem Beispiel von oben folgend so:

page.10.marks.CONTENT.content = fe_users_1, fe_users_3, pages_12, tt_content_21

Nett, oder?

Mehr Komfort für Redakteure

Um weitere Tabellen im Teaser zu erlauben, und diese vorallem im Backend auszuwählen muss man im Moment leider noch hart an den Quelltext ran. In der Datei typo3conf/ext/kiwi_teaser/ext_tables.php wird im Array $tempColumns ab Zeile 33 das Feld tx_kiwiteaser_teasers als Datenbankrelationsfeld definiert. In Zeile 41 werden unter dem Schlüssel allowed alle erlaubten Datenbanknamen aufgezählt. Um den Redakteuren die Auswahl von Benutzern zu erlauben, muss der Eintrag erweitert werden:

$tempColumns['tx_kiwiteaser_teasers']['allowed'] = 'tx_kiwiteaser_content,pages,tt_content,fe_users';

Ausblick und Weiterentwicklung

Der aufmerksame Betrachter wird die auskommentierte Zeile 40 bemerken, in der tt_news noch erlaubt war. Daran arbeiten wir im Moment. Verbessert werden muss die Verlinkung auf ausgewählte Inhalte.

Außerdem auf der Liste steht eine dynamische Darstellung von Teaserinhalten. Das bedeutet zum Beispiel das auslesen aller Seiten ab einem Einstiegspunkt, oder die Angabe von verschiedenen Bedingungen.

Wer diese Funktionen für sein Projekt gut gebrauchen kann oder mehr Ideen hat, ist natürlich herzlich eingeladen mit uns darüber zu reden.

Aber damit ist jetzt Schluss! Die neue Version legt ihre Container unabhängig von den Rahmen um den Inhalt. Zeitnah im Repository verfügbar. Auf meiner privaten Seite gibt es eine Demonstration und im folgenden Eintrag ein paar technische Erklärungen.

Für Redakteure

Die Funktionsweise für Redakteure ist sehr einfach. Über die Seiteneigenschaften lässt sich bestimmen, ob mehrere Panels gleichzeitig offen sein dürfen.

Jedes Inhaltselement wiederum hat zwei Eigenschaften, Aufklappbar und Offen.

Die erste Option initalisiert den Effekt, die zweite öffnet das Inhaltselement beim laden der Seite. Das wars! Eine Beispiel gibt es auf meiner privaten Seite.

Für Techniker

Der kleinere Teil der Arbeit wird vom mitgelieferten Typoscript übernommen. Über die Eigenschaft tt_content.stdWrap.innerWrap.prepend und append wird ein DIV Container um den Inhalt gelegt (div.ka-panel) und je nach gewählten Eigenschaften die Klasse open oder close hinzugefügt.

In Version 4.3 hat sich dieser Teil grundlegend geändert. Inhaltselemente werden jetzt immer innerhalb eines DIV Containers ausgegeben was ich wesentlich besser finde als die nervigen Links ala <a href="#c123"></a>. Das hat leider zur Folge, dass in älteren Versionen der tt_content.stdWrap.innerWrap nur ausgeführt wird, wenn ein Rahmen ausgewählt wurde. Um das zu verhindern fügt die Extension einen Standardwert hinzu, damit die Eigenschaft aufjedenfall greift. Möglich wird das über die Abfrage der eingestellten TYPO3 Version.

[compatVersion < 4.3]

tt_content.stdWrap.innerWrap.cObject.default = TEXT

tt_content.stdWrap.innerWrap.cObject.default.value = |

[end]

Der größere Teil der Arbeit erfolgt als jQuery Script. Das Kiwi Accordion arbeitet mit jQuery, bringt das Framework aber selbst nicht mit. Ich bin bei der Entwicklung davon ausgegangen, dass es in jedem Projekt integriert ist.

Im Script wird jeder Container mit der Klasse ka-panel untersucht und für die weitere Verwendung angepasst. Dabei wird mit $(':header:first', '.ka-panel') die erste Überschrift gesucht und als Handler benutzt. Alle Elemente nach der Überschrift werden mit einem Container umschlossen (div.ka-content) und bei Klick ein- oder ausgeblendet.

Bei Mauskontakt erhält das Panel zusätzlich die Klasse hover, damit lassen sich dann Pfeile anzeigen oder Farben ändern, je nach Vorgabe.

Wenn bei der Initialisierung etwas nicht funktioniert, gibt die Extension ein paar Hinweise in der Firebug Konsole aus. Ich hoffe das hilft weiter. Ansonsten sei auf die Demo auf meiner Seite verwiesen.

Getestet hab ich die Extension mit TYPO3 Version 4.3, 4.3.1 und 4.2.6. Über weitere Kompatibilitätshinweise, Fragen und Anregungen freue ich mich natürlich sehr.

• Kiwi Accordion im TYPO3 Repository
• Kiwi Accordion 1.6.0
• Demonstration auf paul-lunow.de

Danke für die ganzen Mails und die netten Worte! Frohes rumklappen.

Die Teaser sind entweder Teaserdatensätze (mit Titel, Inhalt, Bild und Link), ganze Seiten oder einzelne Inhaltselemente. Fertig! Auf der Startseite kann der Redakteur jetzt ganz genau bestimmen, auf welche Inhalte die Benutzer aufmerksam gemacht werden sollen und in welcher Reihenfolge.

Die Extension gibts im TYPO3 Repository oder auf GitHub - live im Einsatz bisher auf unserer Firmenpräsenz.

Berechtigung

Es liegt natürlich nahe tt_news einzusetzen. Aber erst sagt der Redakteur mir, ich soll das Datum ausblenden, denn regelmäßige News gibt es  gar nicht. Als nächstes will er die Reihenfolge ändern und ich sage, pass doch einfach das Datum entsprechend der Reihenfolge an. Klar, das geht aber so richtig genial ist das nicht.

Zumal die meisten Hinweise sich auf entsprechende Seiten in der Präsenz beziehen, auf externe Links oder einfach nur einen kurzen Hinweis darstellen. Das geht jetzt eleganter.

Inhalte

Es können verschiedene Inhalte vorgestellt werden. Die Extension bringt eigene Datensätze mit welche Titel, Inhalt, Bild und einen Link aufnehmen. Es können aber auch Seiten oder Seiteninhalte angeteast werden.

Installation

Entweder man holt sich die stabile Version aus dem Repository oder die aktuellste, brandheiße aus meinem ersten Projekt auf GitHub. Ein großartiges Portal!

Die restliche Installation ist alt bekannt und ganz normal. Der Kiwi Teaser bindet standardmäßig jQuery ins Projekt ein um ein paar coole Extras zu ermöglichen.

Konfiguration

Über Typoscript hat man viele Einstellungsmöglichkeiten. Alles natürlich unter plugin.tx_kiwiteaser_pi1 im Template - das schreibe ich jetzt nicht jedesmal mit auf. Die angegebenen Typoscriptschnipsel stellen jeweils die Standardeinstellung dar.

include.css.standard = 1

Mit dieser Anweisung wird ein minimales Stylesheet geladen welches dafür sorgt das die Boxen nebeneinander stehen und einen Abstand zueinander haben.

include.javascript.jquery = 1

Bindet die aktuelle jQuery Version ein. Hat man diese schon im Projekt sollte man diese Eigenschaft unbedingt mit include.javascript.jquery > löschen (auf diese Art kann man jeden include verhindern).

include.javascript.clickbox = 1

Holt mein Plugin Clickbox ins Projekt, welches die komplette Teaserbox klickbar macht und nicht nur den kleinen Link. Mehr zur Clickbox gibts hier.

include.javascript.height = 1

Bindet ein Script ein, welches dafür sorgt das alle Teaserboxen die gleiche Höhe haben. Besonders praktisch wenn man einen Rahmen oder eine Hintergrundfarbe gesetzt hat.

template.file = EXT:kiwi_teaser/res/html/template.html

Der Pfad zum HTML Template. Das Standardtemplate sollte man sich unbedingt angucken und die Klassennamen beibehalten, denn sonst kriegen die oben erwähnten Scripte Schwierigkeiten.

stdWrap

Der StandardWrap ist eine richtig schöne Sache! Damit kann man jeden Inhalt mit Typoscript bearbeiten bevor er ausgegeben wird. Dieser kann auf alle Felder angewendet werden: title, image, link und content. Zum Beispiel:

stdWrap.title.wrap = <b>|</b>

Außerdem kann man für verschiedene Quellen verschiedene Optionen angeben. Seiten kommen aus der Tabelle pages, Seiteninhalte aus tt_content und die Standardinhalte aus tx_kiwiteaser_content. Mit diesem Wissen kann man die Ausgabe je nach Datenbank bestimmen. Möchte man also die Überschriften von Seiten nicht fett sondern kursiv darstellen, reicht folgende Anweisung:

stdWrap.title.pages.wrap = <i>|</i>

Besonders wichtig ist diese Möglichkeit für den Linktext. Dieser wird über die Eigenschaft link.value gesetzt.

stdWrap.link.value = Mehr...

Die Extension setzt den generierten oder angegebenen Wert vor der Verarbeitung in das Feld stdWrap.link.typolink.parameter. Das typolink Objekt lässt sich natürlich trotzdem noch erweitern. Will man alle Teaserlinks in einem neuen Fenster öffnen geht das ganz einfach:

stdWrap.link.typolink.target = _blank

Mapping der Inhalte

Um zu entscheiden, welche Daten aus einem Datensatz den Titel und welche z.B. den Inhalt darstellen, gibt es eine Mappingtabelle im Typoscript. In der Standardkonfiguration wird der Untertitel einer Seite als Inhalt benutzt. Das passiert über folgende Angabe:

tables.pages.content = subtitle

Dabei bezeichnet der Schlüssel das Feld im Teaser und der Wert das Feld in der Zieltabelle. Das lässt sich je nach Anforderung beliebig anpassen. Wenn die Eigenschaft link leer ist, erzeugt die Extension den Link je nach Tabelle automatisch.

Template

Im Template stehen verschiedene Marker zur Verfügung:

• ###TITLE### Ein Beispieltitel
• ###IMAGE### uplodas/media/picture.jpg
• ###CONTENT### Das ist je nach eingabe verschieden.
• ###LINK### <a href="index.php?id=123">Mehr...</a>
• ###CLASS### teaser-first port1

Image beinhaltet den originalen Inhalt aus der Datenbank, also im Idealfall den Pfad zum Bild, sollte also noch mit einem <img> Tag gewrappt oder per Javascript weiter verarbeitet werden.

Link ist ein kompletter <a> Tag - generiert über Typoscript.

Class wird automatisch gesetzt, je nach Position des Teasers steht da first-teaser oder last-teaser drin. Außerdem kriegt jeder Teaser die Klasse portX wobei das X für die aktuelle Position steht. So kann man also den zweiten Teaser gezielt ansprechen:

.tx-kiwiteaser-pi1 .port2 {

  font-size:200%;

}

Alpha

Heute, am 17.12.2009 habe ich die erste Version fertig gestellt und in meinem Projekt eingesetzt. Als nächstes wird sie in Kundenprojekt eingesetzt und die Redakteure darauf losgelassen. Dabei werde ich sicher noch die eine oder andere Erweiterung entwickeln, mit mehreren Updates ist also zu rechnen. Auf dem neusten Stand ist man natürlich bei Twitter.

Ausblick

Der wichtigeste Punkt auf meiner Liste ist die Unterstützung von tt_news. Damit ist es dann auch möglich eine schön ausgearbeitete Nachricht zu teasern. Natürlich muss sich das nicht auf tt_news beschränken, sondern kann im Prinzip jeden beliebigen Datensatz beinhalten!

Darüber hinaus sind die Pläne natürlich groß und die Möglichkeiten auch. Ich denke an jQuery Effekte wie das faden von Inhalten, die Integration vom Kiwi Slider oder das dynamische Anpassen der Inhalte.

Da wird noch einiges passieren!

Fazit

Ich möchte kein zweites tt_news programmieren, hier geht es wirklich nur um das Teasern von eigenen und fremden Inhalten. So bequem und einfach für die Redakteure wie möglich.

Ich hoffe ihr könnt die Extension gut einsetzen - über Ideen, Fragen und Anregungen in den Kommentaren freue ich mich natürlich. Und wenn jemand per GitHub mitarbeiten möchte, ist er hiermit herzlich eingeladen.

Ganz unauffällig sei auch noch auf meine Firma hingewiesen - wenn du die Extension oder ähnliches für dein Projekt brauchst, aber nicht selbst programmieren möchtest oder kannst, dann ist der Kiwi Service ein verantwortungsbewusster und kompetenter Partner!

Wenn dir der Artikel gefällt und du mit uns zusammen mehr solche Lösungen entwickeln möchtest, an das Internet und OpenSource glaubst und einen Job in Berlin suchst, dann bewirb dich bei uns. Wir suchen neue Freunde!

Danke fürs lesen, und fröhliches teasen!

Dieses Tutorial bezieht sich auf TYPO3 Version 4.3, aber ich vermute es funktioniert in allen neueren Versionen. Los gehts!

Vorbereitungen

Eine aktuelle TYPO3 Installation mit benötigten Extensions (RealURL vorallem) und ein paar Domains die alle in das gleiche Verzeichnis zeigen. Das reicht.

Die Seitenstruktur

Direkt unter die Weltkugel kommt die Root Seite. Diese beinhaltet ein grundlegendes Typoscript, dass sich alle Domains teilen. Es lohnt sich ein einfaches Layout aufzubauen und alle benötigten Marker anzulegen, dann kann man später schnell etwas zeigen. Auch tt_news, mailformplus, kiwi_slider oder was auch immer kann man hier schonmal gut Vorkonfigurieren.

Unter Root kriegt jede Domain eine eigene Seite. Die besitzen folgende Eigenschaften:

• Typ: Verweis - auf erste Unterseite
• Im Menü verbergen
• Seitentitel wie die Domain
• Nicht in sprechende URL aufnehmen

Jeder Seite müssen über Liste > Neuer Datensatz > System Records > Domäne die entsprechenden Domains zugewiesen werden. Am besten man legt als erstes die Hauptdomain an, zum Beispiel www.kiwi-service.de - ohne Umleitung.

Ein zweiter Datensatz kriegt dann die Domäne kiwi-service.de mit Umleitung auf www.kiwi-service.de. Die Checkbox Parameter zur Umleitungs-URL übertragen sollte man anschalten und speichern.

Typoscript

Auf der Root Seite lohnt es sich ein fertiges Template aufzubauen. Die wichtigesten Marker, wie Menü, Inhalt und Sidebar empfehle ich als COA Elemente anzulegen, wobei der Hauptinhalt immer auf Ebene 50 eingebunden wird. Damit kann man auf den Unterseiten einfach die Marker erweitern.

Über Konstanten lässt sich sehr viel steuern. Zum Beispiel die Start ID für das Menü. Dazu legt man in den Konstanten einen beliebigen Namen fest:

menu.special.value = 123

Im Typoscript kann man auf diese Eigenschaften dann über die Syntax {$NAME} zugreifen. Vereinfacht könnte das dann so aussehen:

MENU = COA

MENU.50 = TMENU

MENU.50.special.value = {$menu.special.value}

Mit diesem Vorgehen kann dann jede Seite grundlegend über Konstanten steuern. Man sollte es aber nicht übertreiben. Ideal sind die Grundeinstellungen damit man etwas sieht und klicken kann, alle Strukur- und Layoutanpassungen passieren dann gezielt im Extensiontemplate der Seite.

Am wichtigesten ist die Bekanntmachung der BaseURL. Entweder über Konstanten oder direkt im Template:

config.baseURL = http://www.kiwi-service.de

RealURL

Jetzt zum schönsten Teil (leichte Ironie), damit man sich über die netten Domains freuen kann: RealURL. Installiert, ohne automatische Konfiguration ist die wichtigste Aufgabe, für jede Domain die richtige rootpage_id zu setzen.

Um sowenig wie möglich doppelt zu schreiben, legt man dafür als erstes eine Standardkonfiguration an:

$tx_realurl_config = array(

'init' => array(

'enableCHashCache' => true,

'appendMissingSlash' => 'ifNotFile',

'enableUrlDecodeCache' => true,

'enableUrlEncodeCache' => true,

'emptyUrlReturnValue' => '/',

),

'preVars' => array(),

'postVarSets' => array(

'_DEFAULT' => array(),

),

'pagePath' => array(

'type' => 'user',

'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',

'spaceCharacter' => '_',

'languageGetVar' => 'L',

'expireDays' => 3,

),

);

Die ist für alle gleich und sollte auch Konfigurationen für tt_news und andere Extensions beinhalten. Diese wird jetzt jeder Hauptdomain zugewiesen.

$TYPO3_CONF_VARS['EXTCONF']['realurl'] = array(

  'www.alexandrepeschel.de' => $tx_realurl_config,

  'www.kiwi-service.de' => $tx_realurl_config,

);

Die Aufrufe ohne www kann man vernachlässigen, weil TYPO3 sie weiterleitet. Als nächstes wird für jede Domain die UID der entsprechenden TYPO3 Einstiegsseite angegeben. Damit versteht RealURL dann, welcher Teil des Seitenbaums zu welcher Domain gehört.

$TYPO3_CONF_VARS['EXTCONF']['realurl']['www.kiwi-service.de']['pagePath']['rootpage_id'] = 12;

$TYPO3_CONF_VARS['EXTCONF']['realurl']['www.alexandrepeschel.de']['pagePath']['rootpage_id'] = 34;

Beim rumprobieren sollte man daran denken, dass man mit dem Leeren vom Frontend-Cache nicht den RealURL-Cache löscht! Das passiert über Info > Root Seite > RealURL-Verwaltung. Da sind sehr interessante Informationen drin versteckt!

Fazit

Das war schnell und effektiv! Wer sich das in Aktion ansehen will, geht auf unsere neue Firmenseite www.kiwi-service.de und auf www.alexandrepeschel.de, die Seite meines lieben Kollegen. Im Moment ist das zum Teil im Aufbau und demnächst wird meine persönliche Seite auch dahin umziehen. Aber erst wenn die Seite auf dem neuen Server liegt!

Wenn du Spaß an diesem Tutorial hattest, und Lust hast mit uns noch viel mehr geilen Scheiß zu entwickeln, dann bewirb dich bei uns! Wir suchen Webentwickler mit Ideen und Tatendrang!

Wenn aber das unbedingt nur von einer Lightbox kommt, dann sollte man sich kurz hinsetzen, einen geeigneten Klon aussuchen (hier ist die große Lightbox Matrix) und die Klickvergrößerung von TYPO3 damit ersetzen. Das ist schnell, effektiv und in diesem Beitrag erklärt.

Vorbereitungen

Für mein aktuelles Projekt habe ich mich für den Lightbox Clone TopUp entschieden. Sieht sehr vielversprechend aus. Also welcher Klone auch immer: Daten herunterladen und ins Projekt einbinden. Dazu gehören mind. jQuery und das entsprechende Plugin, in vielen Fällen auch noch eine CSS Datei. Firebug verrät im Script Reiter ob es funktioniert hat.

TopUp benötigt keine CSS Datei, dafür aber einen Bilder- und einen Players-Ordner in dem SWF Dateien gespeichert sind um verschiedene Medien wiederzugeben. Per JavaScript können die Pfade angepasst werden:

TopUp.host = 'http://www.kiwi-service.de/';

TopUp.images_path = 'fileadmin/template/img/topup/';

TopUp.players_path = 'fileadmin/template/flash/';

JavaScript einbinden

Eine Besonderheit bringt TopUp mit: Es lädt dynamisch die benötigten JavaScriptdateien nach. Dafür braucht er den kompletten javascripts/jquery Ordner. Dieser muss im gleichen Ordner liegen wie top_up-min.js.

fileadmin/template/js/top_up-min.js

fileadmin/template/js/jquery/...

Test

Alle benötigten Dateien sind eingebunden und in Firebug sichtbar. Um zu testen ob es funktioniert, füge ich ein Inhaltselement vom Typ HTML ein und schreibe mein eigenes Bild rein. Testbilder sind im Images Ordner vorhanden.

<a href="fileadmin/template/img/topup/photos/1.jpg" class="top_up">

  <img src="fileadmin/template/img/topup/thumbnails/1.jpg">

</a>

Funktioniert, wunderbar! Wenn nicht, dann die eigene Seite mit den Beispielen vergleichen.

Typoscript

Nun muss man TYPO3 noch das hässliche JavaScript PopUp austreiben. Hier mein Konfiguration für Version 4.3

temp.imageLinkWrap = 1

temp.imageLinkWrap {

enable = 1

typolink {

parameter.cObject = IMG_RESOURCE

parameter.cObject.file.import.data = TSFE:lastImageInfo|origFile

parameter.cObject.file.maxW = {$styles.content.imgtext.maxW}

parameter.override.listNum.stdWrap.data = register : IMAGE_NUM_CURRENT
title.field = imagecaption // title

title.split.token.char = 10

title.if.isTrue.field = imagecaption // header

title.split.token.char = 10

title.split.returnKey.data = register : IMAGE_NUM_CURRENT

parameter.cObject = IMG_RESOURCE

parameter.cObject.file.import.data = TSFE:lastImageInfo|origFile

ATagParams = target="_blank"

}

}
tt_content.image.20.1.imageLinkWrap >

tt_content.image.20.1.imageLinkWrap < temp.imageLinkWrap 

Als erstes wird das temporäre Objekt temp.imageLinkWrap erzeugt und konfiguriert. Interessant ist die letzte Angabe ATagParams - darüber gibt man jedem Link die Klasse top_up mit, damit das Plugin sich um die Bilder kümmert.

Anschließend wird die Standardvergrößerung in tt_content.image.20.1.imageLinkWrap überschrieben. Cache leeren und Seite neuladen, fertig!

TopUp Spezialitäten

Dieses TopUp ist wirklich ein schönes Teil. Mit der Funktion addPresets() lassen sich für Links in DOM Bereichen Voreinstellungen treffen. Zum Beispiel alle Bilder die über ein Inhaltselement eingestellt sind, zu einer Gruppe zusammenfassen:

TopUp.addPresets({

".csc-textpic-imagewrap a": {

group: "images"

}

});

Das bedeutet alle TopUp-Links im Div .csc-textpic-imagewrap werden der Gruppe images zugewiesen. Im Overlay gibts dann Vor- und Zurückpfeile.

Fazit

Die Initialisierung und Einstellungen einer Lightbox variieren natürlich. Es gibt aber ein paar schöne und elegante Tools deren Einsatz sich lohnen. Vorallem im Zusammenspiel mit der brand neuen TYPO3 Version 4.3 - ein großartiger Schritt mit schönen Verbesserungen. Unbedingt ansehen. Und TopUp einbinden!