TYPO3@lisardo

Allgemein wird er ja hoch gelobt, der App-Store von Apple. OK, wenn man den Namen einer App weiß, findet man sie wirklich sofort. Der Store ist performant, und man gibt sein Geld nirgends sonst so komfortabel und schnell in andere Hände als dort. Das ist mehr als vergleichbare Shops können. 

Aber wehe, man möchte sich einen Überblick verschaffen, was es dort so alles gibt. Zum Beispiel einfach ein bisschen Schmökern, wie in einer Buchhandlung. Dann wird man von einer unsortierten Fülle an unbrauchbaren Apps regelrecht erschlagen. Beispiel die Rubrik Referenz: Klick auf  «Alle anzeigen» ergibt momentan 5243 Apps für das iPad. Toll? Nein, ganz im Gegenteil: Referenzen sind Lexika, Nachschlagewerke, Sammlungen und ähnliches - da interessieren mich einfach keine arabischen, chinesischen, japanischen, kyrillischen oder aramäischen Titel. Nicht mal spanische, portugiesische, französische, polnische, tschechische oder italienische. Ich suche welche, die mit meiner Lebenswirklichkeit hier in Deutschland zu tun haben, und die finde ich nicht - bzw. ich finde 2-3 pro Seite, versteckt unter fast 100 anderen Apps, mit denen ich nicht das geringste anfangen kann, weil ich nicht mal ihre Titel lesen kann. 

Offensichtlich ist es unmöglich, diesen schier endlosen Haufen nach der eigenen Sprache zu sortieren. 

Ich komme mit dem Store nur auf eine Art klar: ich suche bei Google oder über einige Portale nach sinnvollen Apps und lade sie mir dann aus dem Store runter, über die Textsuche. Alles andere ist Zeitverschwendung. 

Von wegen, eine App über den Store vermarkten: das kann man stecken. Ohne gute Präsenz bei Google, ohne Werbung bei App-Portalen und im Social Web geht man in dem chaotischen digitalen Müll im Apple-Store schlicht unter. 

dokuwiki ist eine feine Sache: einfach und schnell installiert, flott angepasst und dann simpel im täglichen Umgang. Wenn da nicht die (ziemlich zahlreichen) Updates wären. Diese Update-Beschreibung hier lehrt mir wirklich das Gruseln. Ich kann nur jedem raten sich das vorher ganz genau durchzulesen, damit er weiß, worauf er sich einlässt. Und unbedingt beachten, dass der data-Ordner (der logischerweise alle Daten enthält) im Update mit drin ist und bei einem Fehler auch ersetzt wird. Durch einen leeren data-Ordner, versteht sich. 

Jedenfalls ein dickes Lob an das Core-Team von TYPO3. Erst wenn man so was liest (und noch schlimmer: regelmäßig durchziehen muss) dann weiß man richtig zu schätzen, welch verdammt gute Arbeit das Install-Tool von TYPO3 darstellt. 

Ich hatte die letzten Tage wieder lausige Probleme mit einer TYPO3-Installation, deren Datenbank-Tabellen in latin1 kodiert waren (DEFAULT CHARSET=latin und Kollation latin1_swedish_ci), in denen sich aber utf8-Daten befinden. Wenn man den Dump auf die übliche Art erstellt - oder auch z. B. über phpMyAdmin - erhält man beim Wiedereinspielen Umlautprobleme dieser Art: Ã¶ für ö. Das passiert, weil utf8-Daten beim Dumpen nochmals nach utf8 kodiert werden ... 

Dieser Müll passiert immer dann, wenn die Tabellen in MySQL als latin angelegt wurden (DEFAULT CHARSET=latin, meist noch in MySQL 3.x) und auch über eine Datenverbindung mit SET NAMES latin1 beschickt wurden (weil das der Standard in php war), in TYPO3 aber forceCharset =utf-8 eingestellt wurde (eben ohne gleichzeitig setDBinit auf "SET NAMES utf8" zu setzen).

Damit konnte man mit einem normal installierten MySQL 3.x sehr einfach erreichen, dass TYPO3 die Daten auf der Webseite selbst als utf8 präsentiert und sie auch so in den Tabellen abspeichert - leider aber in latin-kodierten Tabellen und über eine latin-Verbindung. Die Konsequenz ist, dass MySQL der Meinung ist, dass es latin-Daten in den Tabellen hat, und deshalb beim Erstellen eines Dumps die Daten dann ganz folgerichtig nach utf8 kodiert. Da die Daten aber leider schon in utf8 sind erhalten wir Datenmüll. 

In etwa war mir schon klar, was passiert und warum, nur eine saubere Lösung wußte ich keine. Eine wirklich gute Beschreibung des Problems (und vor allem praktikable Lösungswege!!) habe ich gerade jetzt in einem richtig guten Artikel von Kristian Köhntopp gefunden: FAQ: Mein mysqldump zerstört meine Umlaute. 

Lesebefehl für alle, die sich mit derartig verkorksten TYPO3-Installationen rumschlagen müssen. Seine Regel am Schluss kann ich nur dringend unterstreichen: 

»Lüge die Datenbank nicht an. Wenn Du SET NAMES latin1 eingestellt hast, sende latin1. Wenn Du SET NAMES utf8 eingestellt hast, sende utf8.« 

Also: $TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8' erfordert zwingend auch $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;' sonst gibts Datenmüll.  

Nachtrag

Ich habe gerade wieder so eine Installation in den Fingern :-( Aber mit der Lösung von Köhntopp klappt es bei mir, etwa in der Art: 

Ich meine ja, dass die Kritik unserer Datenschützer an Facebook & Co. ein bisschen überzogen ist (siehe z. B. den Heise-Artikel »Facebooks "Like"-Button im Visier deutscher Datenschützer«), aber technisch möglich scheint mir so eine Totalüberwachung schon zu sein. Ausserdem bin ich prinzipiell für Datenschutz: Ich achte auch selbst darauf, dass – bei aller Präsenz in sozialen Netzen – bestimmte Bereiche meines Privatlebens nicht ins Web gelangen. Dazu gehören auch private Bilder, private Adressen und Telefonnummern und so weiter. Also habe ich angesichts der Diskussion über das Datamining von Facebook, Google+ und Twitter zunehmend Zweifel bekommen, ob ich auf meiner Seite die Like-Buttons überhaupt einbauen soll.

Es ist eine Sache, ob es mir persönlich egal ist, ob Facebook meine Bewegungen im Internet mitverfolgt (was über die Like-Buttons problemlos möglich ist, wenn ich in meinem Facebook-Account eingeloggt bin), aber eine ganz andere, wenn ich das Gleiche stillschweigend den Besuchern meiner Website zumute. Letzteres will ich eigentlich nicht, es soll schon eine bewußte Entscheidung sein. 

Heute bin ich über einen Artikel bei Heise gestolpert: »2 Klicks für mehr Datenschutz«. Darin wird ein kleines Script vorgestellt, das es ermöglicht, die Like-Buttons auf der eigenen Seite einzubauen, ohne dass diese sofort aktiv sind. Sie werden erst aktiv, wenn der Besucher das erstemal drauf klickt. Nachteil: damit der Like-Button tut was er soll, muss der Besucher ein zweites Mal klicken. Deshalb der Titel ...

Prinzipiell finde ich die Idee nicht schlecht, also teste ich es einfach mal. Ergo habe ich den Like-Teaser erst mal aus der Seitenleiste rausgenommen und statt dessen die Zwei-Klick-Like-Buttons aufgenommen. Mal sehen, ob das irgendwann mal jemand tatsächlich nutzt. 

Hier kann man das Script übrigens runterladen, es darf privat und kommerziell verwendet werden. 

PS: Facebook scheint den 2-Klick-Button nicht zu mögen (wen wunderts ...), macht aber gute Mine zum bösen Spiel: »Facebook beschwert sich über datenschutzfreundlichen 2-Klick-Button« (Siehe ganz unten »Update 2«)

Nachtrag: 

Ich habe mittlerweile eine kleine Extension für TYPO3 gebaut, mit der das Skript einfach eingebunden werden kann. Näheres ist in diesem Artikel zu lesen. 

Nach dem Update meines Laptops auf die neue Systemversion von Apple (MAC OS X Lion) musste ich feststellen, dass meine TYPO3-Entwickler-Installationen samt und sonders nicht mehr funktionierten. Vor allem mein etwas angejahrtes GraphicsMagick verweigerte den Dienst mit der Meldung, dass Programme für den PowerPC nicht mehr verwendet werden können . 

OK, das war überfällig ... Die fertigen Installerpakete von typo3.org funktonieren auch nicht, da gibts als aktuellste Version TYPO3 4.3 für Mac OS X 10.4 (Tiger). Keine Chance, das auf Lion zum Laufen zu bringen. 

Damit auch andere was von der Fummelei haben, hier kurz die wichtigsten Schritte. Zu beachten ist dabei, dass ich nicht die von Lion mitgelieferten Tools (Apache, PHP etc.) verwende, sondern MAMP und MAMP Pro, und ausserdem für weitere UNIX-Tools MacPorts einsetzen möchte, um das Problem dauerhaft zu lösen. 

Schritt 1: MAMP und MAMP Pro updaten

MAMP Pro ist nicht unbedingt erforderlich – das kostenlose MAMP alleine tut es auch – allerdings liebe ich den Komfort, den MAMP Pro bietet. Die neue Version gibts hier zum herunterladen. Achtung: bitte unbedingt die Update-Anleitung lesen!

Nächster Schritt wäre eigentlich die Installation von ImageMagick oder GraphicsMagick. Leider konnte ich kein fertiges Binary für Lion finden, und selbst kompilieren ist reichlich kompliziert. Also habe ich mir das MacPort-Projekt etwas angesehen, das für die UNIX-Standardprogramme fertige Skripte liefert, die selbst alle Abhängigkeiten testen und das Paket kompilieren. Wollte ich mir schon lange mal ansehen ... Dummerweise benötigt aber MacPort wiederum Xcode und zwar die neueste Version für Lion. So gibt eins das andere . Aber: Xcode brauche ich sowieso für iPhone-Apps, also lautet der nächste Schritt: 

Schritt 2: Xcode Vs. 4.x installieren

Das gibts nicht mehr auf den Developerseiten von Apple sondern nur noch im App-Store. Also App-Store von Lion öffnen, Xcode drin suchen und Download anstoßen. Achtung: Apple hat gepfuscht in der der Benutzerführung und der Ausführung. Es gibt Probleme, die mich ziemlich Nerven gekostet haben. 

• der Download ist 4 GB (!) groß, also Geduld. 
• wenn er ganz abbricht (was vorkommt), kann man ihn wieder anstoßen, indem man im App Store die Rubrik »Purchased" aufruft. Muss man erst mal drauf kommen 
• Danach sollte die Installation wie immer bei Programmen aus dem App Store automatisch anfangen, ist aber bei mir nicht passiert. Warum weiß niemand, aber da ich nicht der einzige bin, bei dem es nicht ging: hier ist die Lösung beschrieben. 

Schritt 3: MacPorts installieren

MacPorts für Lion gibts hier zum Download, eine dmg mit einem installer. Runterladen und wie üblich installieren. Wenn Xcode in aktueller Version läuft, funktioniert das einfach. 

Schritt 4: ImageMagick installieren

Ins Terminal wechseln und das hier ausführen: 

Achtung: das dauert ziemlich lange, da eine Unmenge von Abhängigkeiten ins Spiel kommen. Es wird Freetype, Phyton, Ghostscript und vieles mehr installiert. Das ist typisch für MacPorts, da MacPorts alle Abhängigkeiten selbst auflöst und alle Dateien in dieses Unterverzeichnis legt: 

/opt/local/

Der Installer installiert bei mir ca. 800 MB in das Verzeichnis. Der Vorteil liegt natürlich darin, dass MacPorts danach die Installation von anderen Tools erheblich vereinfacht. 

Schritt 5: MAMP und TYPO3 mitteilen, wo ImageMagick liegt

Zum Abschluss muss man beiden mitteilen, wo die Binaries von ImageMagick liegen. Bei MAMP geschieht das in der Datei /Applications/MAMP/Library/bin/envvars und bei TYPO3 natürlich im Install-Tool. Beides ist hier für Snow Leopard beschrieben, es funktioniert aber in Lion genauso. 

Bei mir funktioniert es jetzt einwandfrei und sogar besser als vorher. 

Fazit: 

Xcode und MacPorts belegen auf meinem Rechner jetzt fast 8 GB. Solche Datenmengen nur für eine TYPO3-Installation auf den Rechner zu schaufeln ist schlicht unsinnig. Bei mir macht es nur Sinn, weil ich Xcode sowieso brauche und in Zukunft auch MacPorts einsetzen möchte. 

[Update]

Wie in den Kommentaren beschrieben ein Screenshot meiner Einstellungen im Install-Tool. Keine Ahnung, ob es hilft ...