Mit Typo3 ist es möglich tatsächlich auf einem “weißen Blatt Papier” mit dem Erstellen einer Seite anzufangen. Wo es bei WordPress für mich von Vorteil ist ein fertiges System ohne Konfigurationsaufwand einsetzen zu können, verhält es sich bei Typo3 genau umgekehrt.

Ich kann Typo3 von Grund auf genau auf meine Ansprüche anpassen. Das Alles dann auch noch ohne eine Zeile potentiell fehleranfälligen PHP-Code zu schreiben. Tatsächlich konnte ich bisher noch alles über TypoScript konfigurieren. Darauf das es bis dahin einiges an harten Erfahrungen gebraucht hat, gehe ich an dieser Stelle mal nicht weiter ein…

Mein Einsatzgebiet für Typo3-Seiten sind die typischen “Firmen-Seiten”. In der Regel Kunden-Seiten, welchen es um die Eigenpräsentation mit beliebig vielen Inhalten geht. Kontaktformular, Sitemap, Mehrsprachigkeit, gute Suchmaschinenoptimierung. Vielleicht mal ein Kalender oder ein interner Bereich. Typo3 kann dabei sehr gut wachsen. Auch Performance-Probleme sind mir bisher, sofern ich den Server nach meinem Belieben einrichten kann, nicht bekannt.

Gerade die überaus mächtigen Nutzer- und Workflow-Möglichkeiten sind für mich bei einer grundlegenden Entscheidung, wenn auch am Anfang meist nicht benötigt, ein wichtiger Grund zum Einsatz des CMS. Mit Typo3 kann ich komplexeste Redaktions-Abläufe abbilden. Bei wachsenden Angeboten, gerade wenn es sich, wie oft bei unseren Kunden, um Neugründungen handelt, ist das Gold wert. Anfangs muss ein CMS her. Eher früher als später kommen dann aber weitere Anforderungen und Typo3 gibt einem das wohlige Gefühlt darauf gefasst zu sein. Nicht nur wenn es um die Workflows geht.

Ein weiteres wichtiges Argument ist der Name. Zumindest in Deutschland hat Typo3 einen unglaublichen Bekanntheitsgrad. Potentielle Kunden haben in der Regel schon mal davon gehört. Manchmal auch schon damit gearbeitet. Selbst Regierung und Global-Player setzen auf das System, so etwas zieht. Das mitunter sperrige Backend ist das selten ein ausreichendes Gegenargument.

Wenn man mit Typo3 einmal die Hürden genommen hat, stehen entsprechende Seiten in kürzester Zeit. Es gibt dann aber doch auch immer wieder Anforderungen, bei denen ich nicht auf Typo3 setzen mag. Sobald es um die Extension-Entwicklung geht, mache ich derzeit noch einen Bogen um Typo3. Kleine Extensions sind mit dem Kickstarter zwar schnell erstellt, aber sobald es an die ernsthafte Entwicklung geht, wird es auf Grund des aktuellen Aufbaus von Typo3 aus meiner Sicht schnell “nervig” und ineffizient.

Mit der Entwicklung von Flow3 und den bereits jetzt verfügbaren Möglichkeiten der Template-Engine Fluid und des MVC-Frameworks Extbase ist hier mittlerweile wesentliche Besserung in Sicht. Spätestens mit der Fertigstellung von Typo3 5.0 werde ich daher meine Meinung zur Entwicklung auf Basis von Typo3 noch einmal überdenken. Bis dahin werde ich mich zur Entwicklung jedoch weiter auf andere System verlassen. Mehr dazu beim nächsten Mal.

Es gibt für beides Pro und Contras. Geht es einem darum mit dem Post direkte Klicks zu produzieren, ist man mit einem Anriss an sich besser beraten. Geht es jedoch um das Gewinnen von Lesern und den Ausbau von Links, ist die Full-Text-Variante die sinnvollere. Letztlich werden in der Voll-Text-Varianten auch alle weiteren Links angezeigt. Die dann wiederum auf weiterführende Beiträge innerhalb des Blog verlinken und schon hat man auch seinen neuen Besucher.

Aus Nutzersicht ist das natürlich auch das sinnvollste. Persönlich tendiere ich sogar dazu Feeds die nur Anrisse anzeigen aus meinem RSS-Reader zu verbannen. Am liebsten sind mir die mit Anriss und Werbung. Ich lese die Feeds in der Regel unterwegs, da nerven die Ladezeiten dann schon gewaltig. Ich muss jedoch auch gestehen, dass ich das Design vieler meiner Lieblingsblogs nicht einmal kenne :( Daher wohl auch die pure ignoranz gegenüber des Designs in meinem eigenen Blog.

Trotzdem, auch mein Standpunkt ist es die Posts komplett im Feed anzuzeigen. Das ist zu guter Letzt in jedem Fall nutzerorientiert und kann damit nicht schlecht sein. Das musste ich heute morgen nur nochmal aus Blogger-Sicht für mich abklären…

Man muss daran denken in der jeweiligen Seiten-Konfiguration im Reiter “Options” die Checkbox “Hide page if no translation for current language exists” zu aktivieren.

Ich finde das Verhalten nicht wirklich “sinnig”. Daher hier auch gleich ein Weg diese Checkbox generell zu aktivieren:

TCAdefaults.pages.l18n_cfg = 2

Um zukünftige Probleme zu vermieden bietet es sich dann noch an die Checkbox gleich ganz zu verstecken:

TCEFORM.pages.l18n_cfg.disabled = 1

Beide Zeilen müssen in die TSconfig und schon wundert der Andy sich beim schreiben dieser zeielen darüber wo diese verdammte Box hin ist…

Wenn das Kind bereits in den Brunnen gefallen ist, wie bei mir der Fall, hier eine kleine SQL-Zeile, die dafür sorgt das die Einstellung auch auf allen bereits angelegten Seiten gesetzt wird.

UPDATE pages SET l18n_cfg = '2'

Ich lege großen Wert auf guten Programmier-Stil und  durchdachte Programm-Architektur. Da ist mir das Funktions-OOP-Misch-Masch von WordPress eigentlich ein Kraus. Zugegeben, ich hätte mich auf Grund dieser Abneigung vor einiger Zeit auch noch gegen WordPress entschieden. Aber WordPress hat enorme Vorteile.

Ein neues WordPress-Blog aufzusetzen ist eine Sache von ein paar Minuten, vielleicht einer halben Stunde. Die Auswahl an Plugins ist gewaltig und ebenso schnell installiert und konfiguriert. Designs gibt es unzählige: Frei und mit einem Klick installiert. Dabei ist das Design aus meiner Sicht beim Einsatz von WordPress zweitrangig.

Ich setze WordPress ein, wenn es mir darum geht möglichst schnell Inhalte zu publizieren und diese der Welt (Google) mitzuteilen. Eine neue Idee, eine neue Domain und ich kann ohne Konfigurationsarie innerhalb kürzester Zeit damit anfangen mich auf das Wesentliche zu konzentrieren: Den Inhalt.

Zur ernsthaften Entwicklung auf WordPress-Basis kann ich mich jedoch nicht durchringen. Selbst für klassische kleine Unternehmens-Seiten scheue ich bisher noch vorm Einsatz von WordPress zurück. Sicher, WordPress ist heute weit mehr als ein einfaches Blog-System. Doch reicht es mir vorerst WordPress weiter für seine ursprüngliche Bestimmung zu nutzen: Blogs erstellen.

Klar, Antennen-Problem. Extra Pressekonferenz. Tausende Berichte. Aber hey, ich habe mein Handy noch keine 2 Jahre und da wird es per Software-Update zum alten Eisen deklariert. Quälend langsam. Ständige Abstürze. Alles flüssige und schöne ist seit dem Update weg. Es macht tatsächlich nicht mehr  so richtig Spaß. Das Schlimmste: Ich denke darüber nach nur deswegen bereits jetzt auf das iPhone 4 umzusteigen. Dadurch hasse ich letztlich mehr mich als Apple. Verschwörungstheorien liegen da nahe.

Apple, zu denen ich eine gewisse Abhängigkeit und Verehrung aufgebaut habe, die mir eigentlich so gar nicht passt. Apple, denen das Problem bisher scheinbar egal war. Jetzt kommt aber scheinbar Bewegung ins Spiel. Demnach plant Apple jetzt die Behebung des Problems mit dem nächsten Update.

Das gibt mir wieder Hoffnung. Aber meine Begeisterung hat einen Knacks weg… und wahrscheinlich ist das sogar gar nicht mal so schlecht.

Aufgebracht rufe ich einige Kollegen. Bin ich vielleicht nur blind? Auch sie benötigen geraume Zeit. Finden dann aber eine eigentlich offensichtliche Funktion, die es irgendwie so gar nicht in meinen Fokus geschafft hat. Wo diese ist darf jetzt jeder für sich selbst herausfinden.

Bei allem tollen Trash-Content wäre es aus meiner Sicht schön auf der Seite eines Fernsehsenders auf der Suche nach dem Programm etwas besser willkommen geheißen zu werden oder will man mich da bewusst in die Tiefen von Kurzartikeln und Werbung ziehen?!

symfony generate:plugin myPlugin

wird gleich eine ganze Symfony-Projekt-Struktur angelegt. Meine Vermutung, dass es mit der Testbarkeit des Plugins zusammenhängt, hat dann dieser sehr gute Artikel bestätigt.

Die Jungs machen sich Gedanken und so macht sogar das ausgiebige Testen richtig Spaß… und ab dafür!