TYPO3weblog.de

Heute erschien ein neues TYPO3 Security Bulletin.

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?

Heute Abend habe ich ein neues Feature eingebaut und die Version 0.2.0 von timtab_twitter veröffentlicht. Ab jetzt werden per default URLs in den Messages auch als klickbare Links dargestellt. Die URLs müssen nicht einmal mit http beginnen. Das ganze kann man natürlich per TypoScript abschalten. Wenn Ihr weitere Ideen für timtab_twitter habt, dann immer her damit.

Nachdem Tim gestern das zweite Türchen geöffnet hat kommt nun Türchen 3 dran.

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.

[caption id="" align="alignnone" width="250" caption="Formular-Wizard im Backend"][/caption]Und hier noch ein Screenshot vom Query-Wizard für die Listen-Ansicht, jedes nur erdenkliche SQL-Query lässt sich damit erstellen.

[caption id="" align="alignnone" width="250" caption="Query-Wizard im Backend"][/caption]Die Dokumentation ist sehr umfangreich und bietet einen schnellen Einstieg in die Extension.

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!

Patrick hat heute in seinem Blog eine sehr schöne Anleitung veröffentlicht, wie man mit TYPO3 per Zufall verschiedene Bilder anzeigt.

Mir gefällt die Lösung deshalb sehr gut, weil sie auch sehr einfach für einen Redakteur zu handhaben ist. Neben der Lösung von Patrick gibt es jedoch auch noch ein paar Alternativen in Form von Extension, wie z.B. cc_random_image, maag_randomimage, wag_randomimage, ck_fortune, dam_pages, onet_imagerotation, sirr,  und, und, und….

Allein diese Auswahl ist – wie ich ich finde – ein negatives Beispiel, denn wozu braucht man 10 Extensions, die mehr oder weniger das gleiche tun? Naja, auf jeden Fall kann man viel ausprobieren und irgendwann findet man dann auch die, die für einen das beste Ergebnis liefert.

Das wäre doch mal wieder ein Testfall für unsere ExtensionComparison-Team, wie wäre es damit Gina?

Was meinst Ihr? Ist es besser so viele Extensions zu haben oder wäre doch eine beschränkte Auswahl besser?

Heute habe ich einen Tip für Extension Entwickler. Manchmal muss man die Größe von Dateien ausgeben, jedoch speichert TYPO3 diese Dateigrößen in der Regel in Bytes. Um nun eine für den normalen Menschen lesbare Ausgabe zu bekommen, bietet die Klasse t3lib_div eine nette Funktion zur Formatierung:

t3lib_div::formatSize($sizeInBytes, $labels='');

Während sich der erste Parameter wie ich denke von selbst erklärt, bedarf der zweite eine kurze Erläuterung. Der zweite Parameter ist eine durch “|”-Zeichen separierte Liste von Labels für Bytes, Kilobytes, Megabytes und Gigabytes. Der Standard ist ” | K| M| G”. In Deutschland zumindest ist man eine andere Schreibweise gewohnt, also gleich mal ein Beispiel:

$fileSize1 = 370
$fileSize2 = 378880
$fileSize3 = 387973120
$fileSize4 = 397284474880

echo  t3lib_div::formatSize($fileSize1, $labels=' Bytes | KB | MB | GB');
// Ausgabe: 370 Bytes
echo  t3lib_div::formatSize($fileSize2, $labels=' Bytes | KB | MB | GB');
// Ausgabe: 370 KB
echo  t3lib_div::formatSize($fileSize3, $labels=' Bytes | KB | MB | GB');
// Ausgabe: 370 MB
echo  t3lib_div::formatSize($fileSize4, $labels=' Bytes | KB | MB | GB');
// Ausgabe: 370 GB

Warum also kompliziert, wenn es auch einfach geht ;-)