Schnellnavigation:

Kategorien

« Januar 2018»
S M T W T F S
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Kopieren Sie diesen Link in Ihren RSS-Reader

RSS 0.91Nachrichten
RSS 2.0Nachrichten

In eigener Sache

Peter Linzenkirchner, Lisardo EDV Beratung in Augsburg. Freelance und Partner für Design- und Webagenturen in Augsburg und München. Pixelgenaue Templates, valides HTML, barrierearm. TYPO3-Projekte, Extension-Programmierung und mehr ... 

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: 

  1. mysqldump --default-character-set latin1 -uUser -pPassword -hHost DB-Name | sed -e's/SET NAMES latin1/SET NAMES utf8/' > datei.sql

Kategorien: Sonstiges  Kommentare 0

Ich habe gestern das Heise-Skript »socialshareprivacy« (siehe mehr dazu in meinem Artikel bzw. auf der Originalseite von Heise) in eine TYPO3-Extension eingebaut und ins TER hochgeladen (Downloadlink). Sie heißt einfach socialshareprivacy. Sie ist so aufgebaut, dass

  • bei Neuerungen im Heise-Skript das Skript einfach in der Extension ausgetauscht werden kann
  • notfalls auch über Typoscript eine externe Variante eingebunden werden kann
  • das verwendete jQuery entweder automatisch durch die Extension eingebunden wird (default) oder ein bereits vorhandenes verwendet wird (Konfiguration im Extension Manager). 
  • praktisch alle Konfigurationsmöglichkeiten des Originalskripts über Typoscript möglich sind. 

Zu beachten ist, dass das Skript von Heise nur eine Instanz pro Seite erlaubt, die Extension kann also nur einmal pro Seite eingebunden werden. 

Installation: 

Die Installation ist simpel: einfach im Extension Manager runterladen, installieren und danach zwei Einstellungen tätigen: die Facebook APP-ID eintragen und anklicken, ob jQuery aus der Extension geladen werden soll oder nicht. 

Facebook APP-Id: 

Eine Anleitung wie man an diese ID kommt ist hier zu finden: Hinweis zur Facebook App-ID

Einbinden in eine einzelne Seite: 

Das Plugin wird in die Seite eingebunden wie alle anderen Plugins: einfach als Inhaltselement. Es gibt nichts zu konfigurieren, einbinden reicht. 

Einbinden ins Template: 

Das geht am besten über Typoscript: 

Im klassischen Template-Stil: 

MARKER < plugin.tx_socialshareprivacy_pi1

oder über TemplaVoila: 

lib.myplaceholder < plugin.tx_socialshareprivacy_pi1

Typoscript-Konfiguration: 

In der Extension-Dokumentation ist keine genaue Beschreibung aller Optionen, aber man kann sich einfach die ext_typoscript_setup.txt vornehmen, dort sind alle Optionen mit Beispielinhalten drin. Eine genaue Beschreibung der einzelnen Optionen ist auch auf der Heise-Seite zu finden. Man kann sie sogar von dort entnehmen und nach folgenden Regeln in sein Setup schreiben: 

1. Allgemeine Optionen: 

plugin.tx_socialshareprivacy_pi1.info_link = 

etc. 

2. Facebook-Optionen: 

plugin.tx_socialshareprivacy_pi1.services.facebook.status = on

etc. 

3. Twitter und Google+: 

plugin.tx_socialshareprivacy_pi1.services.twitter.___

plugin.tx_socialshareprivacy_pi1.services.gplus.___

etc. 

Textausgaben

Ich habe die Textausgaben für die Popups nicht ins Typoscript verlegt sondern in eigene Language-Dateien, um eine einfache Mehrsprachigkeit zu ermöglichen (auch wenn das in dem Fall schlicht Quatsch ist ... sehr deutsch, diese Angelegenheit). So können die Texte aber auch einfach über Typoscript geändert werden:

plugin.tx_socialshareprivacy_pi1._LOCAL_LANG.de.txt_help = 

etc. 

Fehler und Verbesserungsvorschläge: 

Bitte nicht einfach behalten sondern an mich senden, entweder per E-Mail oder über das Kontatkformular

Update

Die Extension ist ab Montag, 24.12.2012 in Version 1.2.1 im TER und jetzt kompatibel zu TYPO3 4.5 bis 4.7 und 6.0. 

fUm die Vorschau von Bildern in einer eigenen Extension in einer der zahlreichen Lightboxen zu präsentieren sind ein paar Schritte nötig. Zuerst das Typoscript: 

  1. plugin.tx_myext_pi1 {
  2.   preview {
  3.    file.maxW=170
  4.    imageLinkWrap = 1
  5.    imageLinkWrap {
  6.     enable = 1
  7.     typolink {
  8.      ATagParams = class="lightbox" 
  9.      parameter.cObject = IMG_RESOURCE
  10.      parameter.cObject.file.import.data = TSFE:lastImageInfo|origFile
  11.      parameter.cObject.file.maxW = 700
  12.      parameter.cObject.file.maxH = 700
  13.     }
  14.    }
  15.   }
  16.  }

Dabei sorgt file.maxW für die Breite des Vorschaubildes und parameter.cObject.file.maxW für die Breite des Bildes in der Lightbox. Der Eintrag bei ATagParams variiert nach verwendeter Lightbox. Ich verwende hier die Colorbox, die eine Klasse mit dem Namen "lightbox" wünscht. 

Im PHP der Extension muss dieses Typoscript passend verwendet und ergänzt werden: 

  1. // $url = Pfad zur Bilddatei - aus der DB
  2. // $title = Titel / Kurzbeschreibung des Bildes, aus DB;
  3. $lConf = $this->conf['preview.'];
  4. $lConf['file'] = $url;
  5. $lConf['imageLinkWrap.']['typolink.']['title'] = $title;
  6. // Zuweisen zum Marker:
  7. $marker['###IMAGE###'] = $this->cObj->IMAGE($lConf);
  8. // etc.
  9.  

Kein großer Aufwand mehr im PHP ... Man übernimmt sinnvollerweise zuerst die Konfiguration in eine Variable ($lConf) und erweitert dann diese Konfiguration mit $lConf['file'] um den Pfad auf das Bild (in der Regel wohl aus der DB ausgelesen). Der Rest ist optional – wobei der title natürlich noch sinnvoll ist, da er in der Lightbox gezeigt wird. 

Damit ist sichergestellt, dass sowohl die direkt gezeigten Vorschaubilder wie auch die größeren Bilder in der Lightbox eine vorgegebene Maximalgröße bekommen. Weitere Attribute können natürlich nach Belieben entweder im Typoscript oder im PHP hinzugefügt werden. 

 

tt_news verwendet die Typoscript-Funktion filelink für die Ausgabe der Dateien, die mit einem News-Artikel verbunden werden. An sich ist das ziemlich leistungsfähig und auch gut zu konfigurieren. Kleines Beispiel: 

  1. plugin.tt_news.newsFiles {
  2.   icon = 1
  3.   icon.wrap = <span class="news-file-icon"> | </span>
  4.   size = 1
  5.   size.wrap = <span class="news-file-size"> | </span>
  6.   target = _blank
  7.   file.wrap = <span class="news-file-file"> | </span>
  8. }

Die verschiedenen Optionen sind im TSref zu finden. 

Leider fehlt eine entscheidende Möglichkeit, nämlich eigene Icons für die Dateien zu verwenden. In filelinks ist der Ordner, aus dem die Icons geladen werden, nämlich hart im PHP kodiert. Und zwar einschließlich der Pixelgröße der verwendeten Icons. 

ich habe viele Fragen dazu im Netz gefunden und auch ein paar Lösungsvorschläge, die aber alle nicht funktionieren - Kunststück, wenn der Ordner wirklich hart im PHP des Core drinsteht. Eine Möglichkeit gibt es aber doch: 

  1. plugin.tt_news.newsFiles {
  2.   stdWrap.substring = 78
  3.   stdWrap.innerWrap =<span class="news-file-icon"><img src="fileadmin/download-icons/ | "
  4.   stdWrap.HTMLparser = 1
  5.   stdWrap.HTMLparser.allowTags = a,img,span
  6.   stdWrap.HTMLparser.tags.img.fixAttrib.width.set = 32
  7.   stdWrap.HTMLparser.tags.img.fixAttrib.height.set = 32
  8. }

Das ist dreckig, funktioniert aber ... Habe ich hier gefunden: Changing appearance of tt_news file list icons (ganz unten). Die Zahl (78) muss angepasst werden an den wrap für das icon ... 

 

Kategorien: Typoscript  Kommentare 1

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. 

Besuchen Sie mich auf Google+