Von den 19 betroffenen Extensions wurden lediglich vier Extensions gefixt:

• aba_watchdog
• car
• dr_blob
• nl_listman

Bei den anderen 15 Extensions wurden keine Patches zur Behebung eingereicht oder der Autor konnte oder wollte nicht erreicht werden. Diese Verhältnis gibt mir ein wenig zu denken. Jeder Entwickler macht einmal Fehler, auch in einer meiner Extensions gab es bereits einmal ein Sicherheits-Leck. Selbstverständlich wurde umgehend das Problem behoben und ein Updates ins TER gestellt. Wie seht Ihr das? Warum werden so wenig Extensions nach der Veröffentlichung noch betreut? Auch wenn man keine Zeit mehr für eine Weiterentwicklung hat, so sollte meiner Meinung der Autor doch wenigstens sicherheitsrelevante Fixes durchführen. Oder sehe ich das einfach nur zu eng?

Die Extension "prowl" ist in erster Linie ein neuer TYPO3 Service. Aber was ist Prowl überhaupt? Fangen wir mal von vorne an. Auf dem Mac gibt es Growl, Growl ist ein systemweiter Notification-Service. Jede App kann Nachrichten an Growl übergeben und der User bekommt diese dann in einem einheitlichen Design zu sehen. Prowl ist nun genau dieser Service, jedoch für das iPhone. Alle Nachrichten können von Growl an einen Prowl Account geschickt werden und der Service von Prowl übermittelt diese dann per Push-Message ans iPhone. Prowl bietet aber auch eine öffentliche API, und genau diese API verwendet die neue Extension "prowl".

Alles was man braucht um diese Extension zu nutzen ist ein kostenloser Prowl-Account, die Prowl-App fürs iPhone (aktuell im App-Store für 2,99 EUR) und natürlich ein iPhone.

Was kann diese Extension nun genau? Wie schon berichtet, bietet die Extension in erster Linie einen TYPO3-Service an. Mit diesem Service kann jeder Extensionentwickler in seine Extension einen Prowl-Support integrieren. Wie einfach dies ist, zeigt das folgende Beispiel:

$prowlAPI = t3lib_div::makeInstanceService('prowl_api');
$prowlAPI->sendProwlMessage($message);

Zur Sicherheit, sollte vorher noch geprüft werden, ob die Extension überhaupt installiert ist:

if (t3lib_extMgm.isLoaded('prowl')) {
    $prowlAPI = t3lib_div::makeInstanceService('prowl_api');
    $prowlAPI->sendProwlMessage($message);
}

Die Methode sendProwlMessage kennt diverse weitere Parameter, welche in der Docu komplett erfasst sind.

Zusätlzich zum Service bringt die Extension auch noch die Möglichkeit mit, sich per Prowl über jede Veränderung im Backend informieren zulassen. Dazu muss auf einer Seite nur ein wenig TSconfig hinterlegt werden. Damit ist es zum Beispiel möglich sich informieren zulassen, wenn jemand einen tt_news Artikel anlegt, verändert oder löscht. Auch dies ist in der Docu ausführlich beschrieben, aber auch dazu hier ein kurzes Beispiel:

mod.prowl.tables.tt_news {
    update = 1
    update.message = Die News: ###TITLE### auf der Seite ###PID### wurde verändert
    new = 1
    new.message = Eine neue News mit dem Titel: ###TITLE### auf der Seite ###PID### wurde erstellt
    delete = 1
    delete.message = Die News mit dem Titel ###TITLE### wurde gelöscht
}

Für die Message stehen automatisch alle Felder der Tabelle als Marker zur Verfügung.

Als letztes bringt die Extension noch ein einfaches Frontend Plugin als Beispiel mit. Dieses erzeugt eine einfache Textbox auf der Website, in der ein Besucher eine Nachricht eintragen kann. Diese Nachricht wird dann auf das iPhone geschickt.

Feedback, Ideen und Anregungen für weitere Einsatzzwecke und mögliche Implementierungen sind ausdrücklich erwünscht. Schreibt einfach in die Kommentare, welche Ideen ihr habt.

Nach ein paar Startproblemen läuft nun der webservice in einer Installation und auch die Verbindung zum webservice funktioniert. Da die App noch nicht im App-Store freigeschaltet ist, blieb nur die Möglichkeit die App im Emulator laufen zu lassen. Die App und der Service sind als "proof of concept" entstanden und aktuell kann man über die App nur tt_news Artikel bearbeiten, aber dies funktioniert dafür echt super.

Alle nötigen Informationen um es selber auszutesten, findet man hier. Außerdem liegt dem webservice eine Doku bei, die einem beim einrichten hilft. Wer nur die App testen will, kann auch den Demo-Server benutzen.

Hier noch ein paar erste Eindrücke von der App:

1. realurl über den ExtManager installiert
2. TypoScript angepasst
3. .htaccess Datei aktiviert
4. tt_news config für realurl aus anderem Projekt kopiert

Dann einmal Cache löschen und ins Frontend geschaut. Nix! Die URLs wurden scheinbar umgeschrieben. Jedoch leider nicht richtig. Der Pfad zu einer einzelnen News sah jetzt so aus: /news/einzelansicht/1/
Hmm, was hab ich falsch gemacht? Eigentlich hatte ich ein Ergebnis erwartet, welches in etwa so aussieht: /news/einzelansicht/datum/2009/06/20/test-artikel-nummer-1/

Ich habe mehrere Stunden mit diesem Problem gekämpft. RealURL komplett entfernt und neu installiert, Configs angepasst, und, und, und.
Ich war schon kurz davor eine neue frische TYPO3 Installation aufzusetzen. Dann kam ich auf die Idee einmal die extList in der localconf.php mit der von einem anderen System zu vergleichen. Der Extkey realurl stand sehr weit hinten, ich habe den extkey also mal weiter nach vorne geschoben, und dies war die Lösung. Leider habe ich immer noch nicht verstanden, warum dies zur Lösung führte. Solltet ihr aber mal das gleichen Problem haben, testet das mal aus ;-)

Hat jemand von Euch eine Idee, was hier das Problem ist? Auch wenn es jetzt läuft, lässt es mir irgendwie keine Ruhe.

Den Podcast findet man direkt hier.

Diesmal geht es um die Benutzung der Session in TYPO3. In der Regel genügt nur eine Zeile Code um einen Wert in die Session zu schreiben oder wieder heraus zu holen. Schauen wir uns erstmal an, wie man etwas in die Session schreibt:

$GLOBALS["TSFE"]->fe_user->setKey("ses", "tx_myext", $data);

Die Funktion setKey() erwartet drei Parameter:

1. Type: Dieser kann "ses" oder "user" sein.
2. Key: Eindeutiger Ident für eine Session Variable
3. Data: Die Daten die gespeichert werden sollen.

Die beiden Typen "ses" und "user" unterscheiden sich wesentlich. Während der Typ "ses" nur temporär die Daten speichert, also genau so lange, wie die Session besteht (Session-Cookie), ist es mit dem Key "user" möglich, die Daten auch über mehrere Sessions hinweg zu speichern, wobei diese an den FE-User gekoppelt werden.

Der Key sollte so gewählt werden, dass man nicht in Konflikt mit anderen Extensions kommt. Am besten benutzt man seinen Extension-Key dafür.

Die Daten die man speichern will kann jede beliebige PHP Variable sein, sogar komplette Objekte kann man ablegen.

So, nun wollen wir uns den Wert mal wieder raus holen, auch dies geht sehr schnell und einfach:

$data = $GLOBALS["TSFE"]->fe_user->getKey("ses", "tx_myext");

Die Methode getKey erwartet nur zwei Parameter, die Bedeutung ist die gleiche wie bei setKey().

Das Leben kann so einfach sein, wenn es nicht ab und an diese kleinen fiesen Sonderfälle gibt ;)

Nehmen wir mal an, man erzeugt ein PDF oder eine AJAX-Antwort, dann gibt man das PDF aus und steigt mit einem exit() oder die() aus. In diesen Fällen, reicht ein einfacher Aufruf von setKey() nicht aus. Denn TYPO3 kann dann die Daten nicht automatisch speichern. Aber hier schafft der folgende Code Abhilfe:

$GLOBALS["TSFE"]->fe_user->setKey("ses", "tx_myext", $data);
$GLOBALS["TSFE"]->fe_user->storeSessionData();

Mit storeSessionData() sorgen wir dafür, dass TYPO3 umgehend die Werte speichert. Sehr häufig wird gerade auf die letzte Zeile verzichtet, was in der Regel auch funktioniert, jedoch nur so lange, wie kein Fehler auftritt oder das Script vorzeitig beendet wird.

Fröhliches Session-Handling Euch allen :)

Ich möchte Euch heute eine Extension vorstellen, welche ich erst vor kurzem entdeckt habe, dabei ist diese gar nicht so neu. Es geht um die Extension "DB Integration".

Die Extension ermöglicht es auf eine sehr schnelle und einfach Art jede beliebige Tabelle im Frontend zu bearbeiten. Dazu gibt es eine Listenansicht, Insert & Edit Ansicht sowie einen Wizard. Ich habe den Wizard noch nicht testen können, aber die Listen und Edit-Ansichten funktionieren einwandfrei. Über Hooks kann man die Querys noch verändern um z.B. die Tabelle tt_address mit einem FE-User zu verknüpfen. So kann man in nur wenigen Minuten ein Adressbuch erzeugen, welches für jeden FE-User getrennt verwaltet wird.

Hier ein Screenshot von dem Wizard im Backend, mit dem man sehr bequem ein Formular definieren kann, welches später im Frontend automatisch erzeugt wird.

Formular-Wizard im Backend

Query-Wizard im Backend

In fast jedem Projekt braucht man Frontend-Editing für eigene Tabellen, diese Extension nimmt einen massig viel Arbeit ab. Von meiner Seite her gibt es ein fettes Lob an die Entwickler, tolle Arbeit!

• feature 1261: Fileupload and categorisation: Now a frontend user can upload files to the dam
• feature 1297: Static category selection in pi1 (thanks to Frank Nägler)
• feature 1319: Counter feature in filelist in pi1 (thanks to Tom Ruether)

Leider gibt es auch etwas negatives an der neuen Version: Bei der Installation musste ich realurl deaktivieren, weil dam_frontend und realurl zusammen zu einem Konflikt führen. Ich werde da mal bei Stefan nachfragen, wo genau das Problem liegt.

Ein weiteres neues Feature ist das neue Link-Menu: Mit der Version 1.1.0 ist es nun möglich die einzelnen Untermenüs ein- und auszuklappen.  Außerdem wurden die APIDocs erweitert.

Wie immer freue ich mich über Feedback. Die neue Version ist im TER, im SVN und hier als T3X-Export zu haben.