typo3

Die Einträge für die Felder "Frontend Layout" und "Backend Layout" lassen sich, wie alle anderen BE Felder auch, leicht über den TS-Config Editor im Bereich Resourcen der Root Page (Weltkugel) editieren:

TCEFORM.pages{
  # remove "Frontend Layout"
  layout.disabled = 1
  # optionally: remove "Backend Layout (subpages of this page)" 
  backend_layout_next_level.disabled = 1
  # rename "Backend Layout (this page only)" 
  backend_layout.label = Layout
} 

To enable a typo3 backend user (or even a whole user group) to delete the typo3 cache is quite simple.
A simple entry in the user's oder the user group's TS config is sufficient:

options.clearCache.pages = 1 
options.clearCache.all = 1

Wer unter Typo3 schon einmal eine eigene Extension entwickelt hat, wird wohl die Extension "Kickstarter" kennen, mit der sich hervorragend ein Grundgerüst für ein eigenes Typo3 Plugin erzeugen lässt und mit dem man sich nicht mehr um die langweilige und stupide Erzeugung eines Rahmengerüstes für ein internationalisierbares Plugin kümmern muss.

Ein einmal erzeugtes Plugin lässt sich zu einem späteren Zeitpunkt erneut in den Kickstarter laden und weiter verfeinern. Leider kommt hier aber auch die Warnung "Kickstarter is not an editor." zu tragen: Nach dem Editieren werden alle selbst getätigten Änderungen am Code verworfen. Die Gründe dafür klären ich weiter unten auf. Im Grunde ist dies aber nur eine unwesentliche Einschränkung: Während der Entwicklung werden die wesentlichen Änderung am Code der Plugins und Module vorgenommen - diese Dateien (wie alle anderen auch ) lassen sich aber gezielt vom Überschreiben durch den Kickstarter ausschließen (und die zugehörigen Einstellungen werden selber auch gesichert).

Leider gestaltet sich das Erzeugen von Tabellen mit vielen Feldern sehr mühsam und zeitraubend: Man kann pro Aktion immer nur ein Feld in der Datenbank anlegen, danach muss man einen Seitenreload abwarten. Auf der dann erscheinenden Seite müssen dann noch die "Erweiterten Eigenschaften" des zuletzt angelegten Feldes definiert werden und man hat die Möglichkeit ein weiteres neues Feld anzulegen. Diese Aktion muss wiederum durch drücken eines Buttons gefolgt von einem Seitenreload bestätigt werden...

Alles in allem also eine ziemlich zeitraubende Angelegenheit.

Das Verhalten der Extension erklärt sich, wenn man sich die Funktionsweise des Kickstarters näher anschaut:

Die während der Plugin-Erzeugung gesammelten Informationen werden in der Datei doc/wizard_form.dat gespeichert. Aus dieser kleinen Datei lässt sich der gesamte vom Kickstarter erzeugte Code ableiten. Die bereits durch die Extension erzeugten Dateien werden vom Kickstarter nicht angefasst. (Die Dateien werden höchstens im weiteren Verlauf vom Kickstarter durch neue Exemplare ersetzt. )

Der Inhalt von 'wizard_form.dat' besteht aus einer einzigen langen Textzeile. Unsachgemäße Änderungen quittiert die Kickstarter Extension mit einem ignorieren der Datei.

Wenn man sich einmal die Mühe macht und hinter die Kulissen der Kickstarter Extension schaut, erkennt man, dass an der Datei nicht viel besonderes ist: Es handelt sich schlicht um eine serialisiertes PHP-Array, dass in eine Datei geschrieben wurde. Wenn man das Array deserialisiert kann man es aus PHP heraus beliebig anpassen. Wichtig ist nur, dass die Struktur gültig und durch Kickstarter erkennbar bleibt. Jede Datenbank-Tabelle wird durch einen eigenen Array-Eintrag repräsentiert. Dieser Eintrag widerum hat für jedes Tabellen-Feld ein eigenes Subarray. Durch Kopieren (und späterem Ändern des Feldnames) eines solchen Eintrages kann man leicht neue Felder (und sogar Datenbanken) in die Konfiguration einfügen. (Tipp: Eine zusätzliche Datenbank-Tabelle mit alle relevanten Datentypen im Plugin anlegen; dann hat man eine prima Kopiervorlage).

Jetzt noch ein kleines Code-Beispiel:

$content = file_get_contents("wizard_form.dat");
$content = unserialize($content);

print_r($content);

// an dieser Stelle kann man das Array beliebig verändern

$content_ser = serialize($content);
print $content_ser;

Source: 10-change_wizard_form.php.html

Wer seine Projekte versioniert, steht bei Typo3 Projekten über kurz oder lang immer wieder vor dem selben Dilemma: Was mit den Passworten machen, die sich z.B. in der localconf.php und möglicherweise diversen ext_localconf.php befinden?

Eine mögliche Lösung besteht aus einem kleinen Helper-Skript (zusammen mit einer - jeweils für das System lokalen - zentralen credentials Datei) , mit dem man die Passworte leicht austauschen kann.

Zuerst legt man eine 'typo3-credentials' Datei für die gewünschten Zugangsdaten an:

export TYPO3_DB=meine_typo3_datenbank
export TYPO3_DB_USER=mein_typo3_db_user
export TYPO3_DB_PW=mein_typo3_db_password

Source: 5-typo3-credentials

Mit einem Hilfsskript 'replace.sh' lässt sich nun das alte Typo3-Passwort beliebig und einfach neu setzen. Für weitere Passwortersetzungen kann man das Skript leicht erweitern.

#!/bin/bash

source typo3-credentials

echo "setting credentials for typo3..."
sed -i -e "s/\$typo_db\s=\s'\w*'.*$/\$typo_db = '$TYPO3_DB'; /g" htdocs/typo3conf/localconf.php
sed -i -e "s/\$typo_db_username\s=\s'\w*'.*$/\$typo_db_username = '$TYPO3_DB_USER'; /g" htdocs/typo3conf/localconf.php
sed -i -e "s/\$typo_db_password\s=\s'\w*'.*$/\$typo_db_password = '$TYPO3_DB_PW'; /g" htdocs/typo3conf/localconf.php
echo "...done"
echo

Source: 5-replace.sh

Achtung: Leider baut das dpsyntaxhighlighter Plugin, welches die netten, buten Skriptings anzeigt Mist; da fehlt leider ein Stück in der Anzeige. Ich habe die vollständigen Sourcen jeweils unter dem Skript verlinkt. Ich schaue mal, ob ich das Problem gefixt bekomme...

Mit dem Apronym AJAX, welches für "Asynchronous JavaScript and XML" steht, bezeichnet man eine Technik, mit der Nutzdaten zwischen einer Webseite und eine Webserver ausgetauscht werden, ohne dass die ganze Webseite an sich neu geladen werden muss. Client-seitig wird dabei massiv von JavaScript Gebrauch gemacht, um den asynchronen Datentransfer zu regeln und Manipulationen am DOM-Baum der Webseite vorzunehmen.

Im CMS Typo3 kann man für eigene Extensions recht leicht AJAX-Support implementieren:

Dazu bedient man sich der eID-Schnittstelle von Typo3. Ich gehe an dieser Stelle davon aus, dass eine Extension, der AJAX Support hinzugefügt werden soll vorhanden ist. Zu Testzwecken lässt sich ein brauchbares Grundgerüst aber auch leicht über die Kickstarter Extension erstellen (dazu muss man lediglich eine neue Extension mit mindestens einem Frontend-Plugin erzeugen).

Die Grundidee des eID-Mechanismus ist ganz einfach: Man registriert unter einem Namen '$bezeichner' einen Hook, auf den alle Aufrufe umgeleitet werden, die in ihrer URL ein entsprechendes eID-Tag haben (z.B. /index.php?eID=bezeichner). Passende Aufrufe werden an das angegebene Skript weitergereicht und der normale Rendering Prozess wird (noch bevor überhaupt eine Ausgabe passiert ist) abgebrochen. Anstatt eine eigene Renderengine anzubinden, kann man ganz hervorragend einen AJAX-Request auswerten und eine passende JSON-Response als Antwort generieren.

Wie geht man konkret vor?

Parallel zu den bestehenden Verzeichnissen im Pluginordner erzeugt man nun ein Verzeichnis für die benötigten AJAX/JSON Skripte.

Nun müssen die notwendigen Skripte anlegt werden:

Als erstes gilt es, eine PHP Klasse mit einer Datenstruktur für die gewünschten JSON-Operationen zu generieren. Der Einfachhalt halber hat has Beispiel nur drei Felder: Ein Flag mit Namen 'isSuccess', das kennzeichnet ob die letzte Aktion (bzw. der AJAX Auruf ansich) erfolgreich war. Ein Feld für Nachrichten( Fehlercodes o.Ä.) und einen generischen Data-Bereich.

messages[] = $message;
  }
}
?>
]]>

Source: 4-json_response.php

Damit man während der AJAX-Requests seine Antworten im gewohnten Typo3-Kontext (leider werden auf diese Weise nicht alle bekannten Typo3 Umgebungsvariablen gesetzt) erzeugen kann, empfiehlt es sich als Basis für eine eigene Klasse tslib_pibase zu wählen:
Während der Abarbeitung des Skriptes wird eine Instanz der Datenklasse erzeugt, gefüllt und nachher als JSON-Antwort zurück gegeben.

request = $this->getRequest();
    $this->response = new tx_json_response();

    $content = $this->processRequest();

    header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');
    header('Last-Modified: ' . gmdate( "D, d M Y H:i:s" ) . 'GMT');
    header('Cache-Control: no-cache, must-revalidate');
    header('Pragma: no-cache');
    $charset = $GLOBALS["cfgApplCharset"]."";
    header('Content-Type: text/javascript; charset='.$charset.'');
    header('Content-Disposition: inline; filename=json.js');
    header('Content-Length: '.strlen($content));
    echo $content;
  }

  function getRequest()
  {
    $input = fopen("php://input", 'r');
    $content = fread($input, $this->MAX_REQUEST_LENGTH);

    return json_decode($content, true);
  }


  function processRequest()
  {
    // prepare a demo response
    $this->response->isSuccess = true;
    $this->response->addMessage("Request successful");
    $this->response->data = Array();
    $this->response->data["stringValue"] = "my string value";
    $this->response->data["num"] = 42;
    return $this->response->asString();
  }
}

$output = t3lib_div::makeInstance("json_test");
$output->main($action);
?>
]]>

Source: 4-json_test.txt

Alternativ kann man natürlich auch mit einem sehr abgespeckten Antwort Skript arbeiten - mit dem Nachteil, dass man sich alle benötigten Komponenten von Hand dazu laden muss:

$feUserObj = tslib_eidtools::initFeUser(); // Initialize FE user object
tslib_eidtools::connectDB(); //Connect to database

Damit Typo3 zukünftig die Richtige Klasse instantiiert, muss man noch den Notwendigen Hook/Handler fuer die AJAX-Aufrufe registrieren. Dies geschieht durch einen kleinen Eintrag in der ext_localconf.php:

// json handler configuration
$TYPO3_CONF_VARS['FE']['eID_include']['bezeichner'] = 'EXT:myExtensionName/json/class.ajaxhandler.php';

Wenn man nun einen entsprechenden Aufruf startet (z.B. /index.php?eID=bezeichner) wird unser Skript gestartet.
Der String 'bezeichner' kann natürlich durch jedes eigene Schlüsselwort ersetzt werden, welches aber in der weiteren Typo3 Installation nicht anderweitig genutzt werden darf (hier biete sich evtl. an, den Extension Key mit einzucodieren).

Client-Seitig kann man JSON-Requests durch passende asynchrone JavaScript-Aufrufe triggern und verarbeiten. Der Einsatz eines JavaScript-Frameworks drängt sich hier natürlich gerade zu auf. Ich empfehle an dieser Stelle natürlich mal wieder JQuery.

Weiteres Vorgehen:
Die meisten Web-Applikationen werden nicht mit einem einzelnen AJAX-Handler auskommen:

Anstatt nun für jede Funktion einen eigenen Handler zu registrieren, könnte man eine zentrale Factory-Klasse schreiben, die abhängig von einem (bisher noch nicht vorhandener) Action-Parameter (z.B. /?eID=json&action=list) eine passende Klasse instantiiert, ausführt und dessen Ergebnis zurück liefert.

Eine kleine Beispiel-Extension habe ich auch noch parat: Download hier: 4-T3X_ajaxdemo.t3x