Contao CMS upgraden: Typische Probleme – und wie man sie löst

Contao Release Plan 2012-2017
Contao Release Plan 2012-2017

Das Open Source CMS Contao wird kontinuierlich weiterentwickelt. Der Relase Plan sieht vor, alle sechs Monate ein neues Release zu veröffentlichen. Das ist erfreulich für diejenigen, die sich auf neue Features freuen; es bedeutet aber auch eine Menge Arbeit für all jene, die für eine Contao-Installation verantwortlich sind, denn eine normale Contao-Version wird nur ein halbes Jahr lang gepflegt und muss dann aktualisiert werden. Lediglich die Versionen mit Long Term Support (LTS) werden zwei Jahre lang mit Bugfixes und sicherheitsrelevanten Patches versorgt.

Ende Juli 2014 läuft der Support für Contao 2.11 aus, und somit wird vielerorts das Upgrade auf Contao 3.2 LTS oder Contao 3.3 anstehen. Ich habe in den letzten Monaten eine ganze Reihe von Websites aktualisieren müssen und fasse in diesem Artikel meine wichtigsten Erfahrungen zusammen.

Weiterlesen …

TYPOlight auf Contao upgraden

Contao Backend Login

Dinge, die kompliziert erscheinen, schiebt man gerne vor sich her. So habe ich lange damit zugewartet, meine diversen TYPOlight-Installationen der Version 2.8 auf Contao 2.9 zu aktualisieren, denn ein Namenswechsel einer Software ist meist mit wechselnden Pfaden verbunden, und das kann ein Update tricky machen.

TYPOlight – Verzeihung: Contao – ist aber auch in dieser Situation eine positive Ausnahme. Das Update verläuft trotz des neuen Namens exakt wie bisher, und das obwohl das Backend nun statt unter www.beispiel.com/typlight/ neu unter www.beispiel.com/contao/ liegt. Also:

  1. Komplett-Backup von Dateien und Datenbank erstellen
  2. Dateien der aktuellen Contao-Version per FTP auf den Server laden
  3. Konfigurationsdateien aus dem Backup nach /system/config/ zurückspielen
  4. Installer ausführen

Detailliertere Informationen zum manuellen Update findet man im Contao-Benutzerhandbuch.

xnewsletterlog: Newsletter-Versandprotokoll für TYPOlight / Contao

Contao mit Backend-Modul 'Newsletter-Versandlog'

Von Haus aus verfügt das Open Source Content Management System Contao (ehem. TYPOlight) über  ein System-Log, in dem man die wichtigsten Ereignisse nachvollziehen kann. Was dort jedoch nicht auftaucht sind Informationen über den Versand von Newsletters, obwohl die Newsletter-Engine zur Grundausstattung dieses CMS gehört.

Um herauszufinden, ob bzw. wann ein Newsletter-Versand stattgefunden hat, ist eine Erweiterung wie z.B. xnewsletterlog erforderlich. Dadurch steht dann das Backend-Modul “Newsletter-Versandlog” zur Verfügung, und dort kann man jede einzelne verschickte E-Mail mit Zeitstempel und Empfänger nachvollziehen, wie der nachfolgende (nachträglich anonymisierte) Screenshot zeigt:

Das Newsletter-Versandlog listet jede einzelne verschickte E-Mail auf

Interessant ist dabei, dass die Extension xnewsletterlog nicht etwa einen Protokollierungsmechanismus in die Newsletter-Engine einbaut, sondern lediglich ein Log darstellt, das die Newsletter-Engine sowieso anlegt. Warum Contao also nicht standardmässig ein Newsletter-Versandprotokoll im Backend anzeigt, ist mir ehrlich gesagt schleierhaft, da der Aufwand minim wäre.

Wachsendes Fachbuch-Angebot zu Contao

Leo Feyer: Das offizielle Contao-Buch

Gerade mal ein halbes Jahr ist es her, seit das Open Source CMS TYPOlight in Contao umbenannt wurde – und schon sind vier Fachbücher sowie ein Video-Training dazu verfügbar:

  • Peter Müller: Websites erstellen mit Contao (Galileo Computing)
  • Thomas Weitzel: Mit Contao Webseiten erfolgreich gestalten: Konzeption, Umsetzung, Beispielprojekte (dpi / Addison-Wesley)
  • Nina Gerling: Contao für Redakteure: Inhalte editieren und verwalten mit dem Open-Source-CMS (Addison-Wesley)
  • Anne-Kathrin Merz: Contao – Das umfassende Praxisbuch (mitp)
  • video2brain Contao: Dynamische Websites mit dem Open Source CMS(Addison-Wesley)

Auch Das offizielle TYPOlight-Handbuch des Entwicklers Leo Feyer wird demnächst neu aufgelegt und vollzieht dann den Namenswechsel: Das offizielle Contao-Buch: Der Leitfaden für Anwender, Administratoren und Entwickler (Addison-Wesley) heisst der Titel.

Das reichhaltige Angebot an deutschsprachiger Fachliteratur zeigt, dass Contao im Markt gut etabliert ist. Das ist ein schöner und verdienter Erfolg für Leo Feyer und sein kleines Team, das in konsequenter Aufbauarbeit ein übersichtliches, ästhetisches und doch leistungsfähiges CMS geschaffen hat.

TYPOlight User-Treffen, Essen

TYPOlight User-Treffen 2010

Die Anwender des Open Source CMS TYPOlight treffen sich am 14. und 15. Mai 2010 zum 3. TYPOlight User-Treffen in Essen. Das Treffen gliedert sich in den „Business-Day“ (der sich an professionelle TYPOlight-Nutzer, Agenturen und Partner richtet) und den „Community-Day“ (der für sämtliche Anwender gedacht ist). Für den “Community Day” konnten als Gastredner Guido Pelzer (Google Adwords Seminar Leader) sowie Peter Müller (Dozent und Autor von “Little Boxes: Webseiten gestalten mit CSS”) verpflichtet werden, welche Vorträge zu den Themen Suchmaschinenoptimierung und CSS halten werden.

Schwere Sicherheitslücke in TYPOlight

TYPOlight Logo

Gemäss TYPOlight-Entwickler Leo Feyer weist der TYPOlight Installer eine schwere Sicherheitslücke auf, die es jedem ermöglicht, die Passwort-Abfrage zu umgehen und die Datenbank-Zugangsdaten sowie – falls der Safe Mode Hack verwendet wird – FTP-Zugangsdaten auszulesen.

Abhilfe schafft ein Update auf die TYPOlight-Version 2.7.6. Wer aus bestimmten Gründen kein Komplett-Update durchführen möchte oder kann, installiert stattdessen einen Patch, der für die TYPOlight-Versionen 2.7, 2.6, 2.5 und 2.4 bereitsteht.

Newsletter-Abonnenten aus TYPOlight exportieren

Screenshot: Buttons für CSV-Import und CSV-Export im Newsletter-Verteiler

Kaum zu glauben: Mit TYPOlight kann man zwar sehr bequem E-Mail-Adressen in einen Newsletter-Verteiler importieren – der umgekehrte Weg des Exportierens ist dagegen nicht vorgesehen. Wie löst man dieses Problem, wenn man nicht die Datenbank direkt anzapfen will?

Der erste Schritt besteht darin, dass man die Extension newsletter_export installiert. Damit steht innerhalb des Newsletter-Verteilers neben dem Button “CSV-Import” neu auch der Button “CSV-Export” zur Verfügung. Klickt man nun diesen Button an, so wird eine CSV-Datei exportiert, deren Inhalt folgendermassen aussieht:

martha.muster@test.com,"1"
peter.mayer@best.com,"0"
usw.

Die Ziffer 1 bzw. 0 am Ende sagt aus, ob die Adresse per Double-Opt-in aktiviert wurde oder nicht. Falls diese Information nicht mehr benötigt wird und deshalb eliminiert werden soll, kann man dies in Excel sehr leicht mit der folgenden Formel erreichen (wobei A1 stellvertretend für die Tabellenzelle steht, in der sich der zu bearbeitende Text befindet):

=LINKS(A1;LÄNGE(A1)-4)

Die Formel bewirkt, dass die letzten vier Zeichen eliminiert werden, und damit erhält man die reinen E-Mail-Adressen.

Isotope E-Commerce: Neues Shop-Modul für TYPOlight

image

Im englischsprachigen TYPOlight-Forum wurde diese Woche die „informelle Ankündigung“ eines neuen Shop-Moduls für TYPOlight veröffentlicht. Ähnlich wie beim kürzlich vorgestellten TYPOlight webShop ist das Ziel eine möglichst nahtlose Integration von Shop- und CMS-Funktionalität.

Die Ankündigung betont, dass man möglichst wenig neu erfinden wollte und auf den bestehenden Konzepten aufbaut; so werden beispielsweise Produktkategorien ganz einfach durch Seiten abgebildet. Hervorgehoben werden ferner die Möglichkeiten zur Bildmanipulation auf dem Server, der im Backend integrierte E-Mail-Editor sowie die Mehrsprachigkeit. An Zahlungsoptionen stehen nebst der Basisversion von PayPal und Authorize.net auch der Schweizer Payment Provider Postfinance zur Verfügung.

Eine Beta-Version soll im September einem beschränkten Benutzerkreis zugänglich gemacht werden.

Mehrsprachige Websites mit TYPOlight – ein Überblick

Spracheinstellung im Browser (Firefox)

Als Bewohner eines offiziell viersprachigen Landes habe ich fast ausschliesslich mit mehrsprachigen Websites zu tun. Dieser Artikel bietet einen Überblick über die Mechanismen des CMS TYPOlight im Hinblick auf die Mehrsprachigkeit.

Backend

image

Wenn es um Mehrsprachigkeit geht, dann muss man immer unterscheiden, ob man vom Frontend oder vom Backend spricht. In der Regel denkt man nämlich nur ans Frontend (d.h. die Website, wie sie der Besucher sieht); für einen Content Manager ist jedoch die Frage, um er mit einem Backend in seiner Muttersprache arbeiten kann, oft genau so wichtig.

Das Backend von TYPOlight ist derzeit in gut 30 Sprachen übersetzt. Deutsch und Englisch werden standardmässig installiert, weitere Sprachpakete kann man einzeln herunterladen und per FTP installieren. Der einzelne Backend User kann seine bevorzugte Sprache entweder beim Login oder aber als Teil seiner Benutzereinstellungen individuell festlegen (unter “Benutzerfunktionen: Persönliche Daten”).

Da die Übersetzungen durch die Community erstellt werden, sind nicht alle Sprachpakete gleich aktuell. Auch werden Extensions unterschiedlich gut abgedeckt. TYPOlight bietet im Backend unter “System” die Funktion “Fehlende Labels” – dort sieht man auf einen Blick, wie vollständig ein Sprachpaket ist. Fehlende Übersetzungen kann man dort allerdings nicht ergänzen – dies geschieht zentral über ein Online-Tool, für das man sich separat registrieren muss. Das ist etwas umständlich, stellt aber sicher, dass Übersetzungen sämtlichen TYPOlight-Benutzern zu gute kommen.

Frontend

Auch im Frontend unterstützt TYPOlight Mehrsprachigkeit. Diesen Anspruch erheben allerdings fast alle CMS, und man muss deshalb genauer hinschauen und sich fragen, wie diese Mehrsprachigkeit im Detail umgesetzt ist. TYPOlight benutzt einen leicht verständlichen Ansatz, mit dem man aber auch an Grenzen stossen kann. Zudem sind gewisse Funktionen nur in Form von Extensions vorhanden.

Es gibt grundsätzlich zwei Prinzipien, wie man mit einem CMS mehrsprachige Websites aufbauen kann: Entweder basieren alle Sprachversionen auf der gleichen Website-Struktur, die Übersetzungen einer Seite sind dann direkt in der Originalseite hinterlegt und werden je nach Benutzersprache ein- oder ausgeblendet. Dieser Ansatz erlaubt den direkten Wechsel zwischen den Sprachversionen derselben Seite und ist oft die bessere Lösung, wenn man den Überblick behalten muss, welche Seiten schon übersetzt sind und welche nicht. Bei TYPO3 beispielsweise ist dieses Prinzip sehr schön realisiert.

image

Das zweite Prinzip arbeitet mit einer separaten Website-Struktur pro Sprache, d.h. der Seitenbaum wird für jede Frontend-Sprache individuell erstellt und gepflegt. Dadurch sind die Sprachversionen nicht miteinander verknüpft, was Vorteil wie Nachteil sein kann: Die Erfahrung zeigt, dass viele Websites ihren Anspruch, alle Inhalte zu übersetzen, in der Praxis doch nicht einlösen können – dann ist es einfacher, wenn die Sprachversionen wie individuelle Websites gehandhabt werden können. Auch im Hinblick auf suchmaschinenfreundliche URLs sind separate Seitenbäume sinnvoll, weil dann URL und Seiteninhalt immer in derselben Sprache verfasst sind. TYPOlight benutzt ausschliesslich diesen zweiten Ansatz.

Spracheinstellungen

Um mehrere Sprachversionen zu erstellen legt man in TYPOlight pro Sprache eine Seite vom Typ “Startpunkt einer neuen Website an”. In den Seiteneigenschaften wird dann die jeweilige Sprache eingetragen. Eine der Sprachversionen kann zudem als Fallback-Sprache definiert werden. Welche Sprachversion ein Website-Besucher zu sehen bekommt hängt von seinen Browser-Einstellungen ab. Existiert die bevorzugte Sprache nicht, dann wird die Fallback-Sprache angezeigt (oder, falls keine solche definiert wurde, die Fehlermeldung “Page not found” ausgegeben).

Sprachwahl

Dass TYPOlight aufgrund der Browser-Einstellung automatisch eine geeignete Sprachversion anzeigt, ist sehr angenehm. Trotzdem sollte man sich nicht ausschliesslich darauf verlassen, denn vielleicht sind die Browser-Einstellungen ja falsch, oder der Benutzer bevorzugt aus anderen Gründen eine andere Sprachversion als die von TYPOlight vorgeschlagene. Ein Sprachwechsler gehört deshalb zwingend zu einer mehrsprachigen Website.

Die einfache Variante besteht darin, dass man den Sprachwechsler hart codiert. Hierzu legt man ein Modul vom Typ “Eigener HTML-Code” an und fügt ein Code-Snippet der folgenden Art ein:

<a href=“{{env::path}}index.php/home.html“ title=“Zur deutschen Startseite“>Deutsch</a> | <a href=“{{env::path}}index.php/home-en.html“ title=“Go to English homepage“>English</a>

Anschliessend wird dieses Modul in allen Seitenlayouts an geeigneter Stelle integriert, und schon hat man einen Sprachwähler auf allen Seiten, der den Sprung auf die Homepages aller Sprachversionen erlaubt.

image

Komfortabler und flexibler ist der Einsatz der Extension changelanguage: Diese erstellt den Sprachwähler automatisch aufgrund aller existierenden Sprachversionen und bietet dabei einige Gestaltungsoptionen. Der Hauptvorteil der Extension liegt allerdings darin, dass man jeder Seite einer Zusatzsprache die entsprechende Seite in der Fallback-Sprache zuordnen kann. Dadurch kann man direkt zwischen den korrespondierenden Seiten der verschiedenen Sprachversionen wechseln – sofern sich der Content Manager die Mühe gemacht hat, jeder Seite die entsprechende Seite der Fallbacksprache manuell zuzuweisen. Die Extension changelanguage kompensiert also den wichtigsten Nachteil der getrennten Seitenbäume.

Obiges Prinzip funktioniert mit normalen Seiten, nicht aber für Nachrichten (News). Wenn man auch hier den Wechsel zwischen den verschiedenen Sprachversionen einer Newsmeldung ermöglichen will, muss man zusätzlich die Extension newslanguage installieren, welche auf changelanguage aufbaut.

Übersetzungsprozess

Eine mehrsprachige Website technisch zu implementieren ist eine Sache – den Übersetzungsprozess der Inhalte zu managen eine ganz andere. Von Haus aus bietet TYPOlight hier keine Unterstützung, weil es eben die Sprachversionen als separate Websites versteht. Hier empfiehlt sich die Extension translations, dank der man auf Ebene von Seiten, Artikeln und Inhaltselementen rasch zwischen den einzelnen Sprachversionen hin- und herwechseln kann. Diese Extension funktioniert nur, wenn man identisch strukturierte Sprachversionen hat – dann aber ist sie eine grosse Hilfe.

image

Übersetzung von Modulen

Beim Thema Mehrsprachigkeit darf man auch nicht vergessen, dass nicht ganz alle Texte, die im Frontend sichtbar sind, durch den Content Manager bearbeitet werden können. Nehmen wir als Beispiel das Suchformular: Die Beschriftung des Buttons “Suchen” kann man im Backend nicht ändern – diese ist im Quellcode als Variable $GLOBALS[‚TL_LANG‘][‚MSC‘][’searchLabel‘] hinterlegt und wird in der Datei /system/modules/frontend/languages/de/default.php ins Deutsche übersetzt. In welche Sprachen ein Modul übersetzt ist und wie vollständig diese Übersetzung ist, kann man mit der Extension translationhelper herausfinden.

Ein anderer Aspekt von Modulen ist der, dass man diese in der Regel nicht für jede Sprache separat definieren möchte. Für diesen Zweck gibt es seit TYPOlight 2.7 das Insert-Tag iflng, das eine Fallunterscheidung nach Sprache erlaubt. Ein Beispiel: Wenn Sie ein Modul vom Typ “Eigener HTML-Code” benutzen, um auf jeder Seite automatisch einen Footer mit den Copyright-Informationen auszugeben, dann können Sie dieses Modul wie folgt für die drei Sprachen Deutsch, Englisch und Französisch definieren:

© 2008-2009 Martin Sauter –
{{iflng::de}}Alle Rechte vorbehalten{{iflng}}
{{iflng::en}}All rights reserved{{iflng}}
{{iflng::fr}}Tous droits réservés{{iflng}}

Mit diesem Insert-Tag kann man beispielsweise auch die Feldbeschriftungen in Formularen sprachabhängig definieren und erspart sich so die Mühe, jedes Formular pro Sprache separat zu bauen.

Möchte man nicht nur reinen Text, sondern auch andere Insert-Tags in Abhängigkeit von der aktuellen Sprache nutzen, dann hilft die Extension fp_lngInsert weiter.

Extensions

Die pauschale Aussage “TYPOlight unterstützt Mehrsprachigkeit” ist insbesondere dort mit Vorsicht zu geniessen, wo Extensions zum Einsatz kommen. Hier muss man fallweise prüfen, ob und in welcher Weise Sprachversionen umgesetzt werden können. Ein gutes Beispiel ist der kürzlich veröffentlichte TYPOlight webShop: Dieser erlaubt zwar unterschiedliche Währungen, Liefergebiete und Steuerzonen, nicht aber unterschiedliche Sprachen. Dies hat zur Folge, dass man pro Sprache einen separaten Shop mit einem individuellen Produktkatalog erstellen muss. Bei einem grösseren Sortiment ist das sehr aufwändig, zudem schafft es Fehlerquellen (z.B. dass Produktdaten oder Preise in den Sprachversionen nicht übereinstimmen), und gewisse Funktionen wie die Lagerbestandsverwaltung sind bei separaten Shops schlicht nicht mehr sinnvoll nutzbar.

TYPOlight Community eröffnet

TYPOlight-Forum deutsch

In seinem Ausblick auf die zukünftige Entwicklung von TYPOlight hat der Entwickler Leo Feyer insbesondere die Verbesserung von Dokumentation und Support als strategische Ziele des Open-Source-Projekts bezeichnet. Ein Element dieser Strategie ist die Eröffnung eines neuen Forums, das den nicht-kommerziellen Support durch die Community sicherstellt. Es löst das bisherige Forum auf der TYPOlight-Website ab, dessen Inhalt zwar weiterhin verfügbar bleibt, das aber keine neuen Nachrichten mehr zulässt. Die Auslagerung unter der neuen Domain www.typolight-community.de hat primär haftungsrechtliche Gründe; die Gelegenheit wurde aber auch gleich genutzt, um mit vBulletin eine leistungsfähigere Forums-Software einzuführen (die beispielsweise auch beim TYPO3 Forum zum Einsatz kommt).

TYPOlight-Forum englisch

Für die englischsprachigen TYPOlight-Benutzer gibt es übrigens ein separates Forum unter der URL www.typolight-community.org. Dieses sieht nicht nur optisch leicht anders aus, sondern setzt auch eine andere Forums-Software ein (nämlich phpBB). Somit sind die beiden Foren vollständig getrennt, sie sind nicht gemeinsam durchsuchbar, erfordern separate Profile und sind nicht einmal über ein Single-Sign-on miteinander verknüpft. Diese Abspaltung halte ich persönlich für einen gravierenden Fehler – die Diskussion darüber im deutschsprachigen Forum findet man hier.

css.php