Schnellnavigation:

Kategorien

« August 2014»
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 ... 

Vor ein paar Wochen hat das Landgericht Frankfurt bestätigt, dass eine fehlende Datenschutzerklärung abmahnfähig ist. Es ging dabei um den Einsatz des Tracking-Tools »Piwik«, das eigentlich zu den datenschutzrechtlich unbedenklicheren Tools gehört. 

Eine genauere Beschreibung des Urteils findet sich bei hier: »LG Frankfurt & Piwik: Abmahnbarkeit fehlerhafter Datenschutzerklärung erneut bestätigt.«

Das Urteil kurz zusammengefasst: 

  • Datenschutzverstöße sind generell abmahnbar (das war bisher nicht ganz klar)
  • Jede Webseite muss über eine Datenschutzerklärung verfügen, und 
  • diese muss über einen direkten Link erreichbar sein (wie das Impressum), also zum Beispiel nicht auf der Seite »Impressum« oder als Unterseite in der Rubrik »Über uns«. 

Für den Einsatz von Tracking-Tools gilt zusätzlich: 

  • Die Tools müssen »pseudonym« arbeiten, das bedeteutet, dass die die IP-Nummer anonymisiert werden muss. 
  • Die Statistik-Daten dürfen gemäß des Safe-Harbour-Abkommens nicht den Geltungsbereich der EU-Gesetzgebung verlassen. Für Google Analytics benötigt man deshalb einen Vertrag mit Google. 
  • Es muss möglich sein, das Tracking zu verhindern, z. B. über ein Cookie oder über eine Browsererweiterung. 

Weitere Infos zum korrekten Einsatz von Google Analytics sind hier zu finden: Google Analytics datenschutzkonform einsetzen

Google Analytics auf diesem Blog

Ich setze hier auf meinen Seiten seit kurzem auch Google Analytics ein. Sie können das Tracking verhindern, indem Sie hier ein Browser-Plugin herunterladen, oder indem Sie diesen Link hier klicken: Google Analytics deaktivieren. Damit wird ein Cookie gesetzt, mit dem das Tracking von Google Analytics für Sie ausgeschaltet wird. Wenn Sie Ihre Cookies löschen, müssen Sie diesen Link erneut klicken. 

Meine Datenschutzerklärung finden Sie hier – oder oben im Menü. Auffällig genug, hoffe ich. 

 

 

Kategorien: Sonstiges  Kommentare 0

Mit dem Extensionbuilder können Datenbank-Relationen für Extbase-Extensions leicht angelegt werden. Das wirklich schöne Interface hat aber zumindest in meinem Fall dazu geführt, dass ich mich anfangs nicht darum gekümmert habe, was genau denn dabei passiert. Und dann stand ich plötzlich vor dem Problem, dass die 1:n-Relation doch bitte ohne IRRE funktionieren soll. Das Problem ist an sich leicht zu lösen, aber eben nicht mehr allein über den Extensionbuilder. 

Worin liegt das Problem? 

Model A (Location) soll eine 1:n-Verbindung erhalten zu Model B (Image). Ziel ist die Präsentation von Orten mit Adresse, Beschreibung und beliebig vielen Bilder. Wird die Relation über den Extensionmanager angelegt (was sehr einfach geht), dann bekomme ich im Location-Datensatz im Backend ein IRRE-Feld für die Bilder. Soweit wunderbar einfach für den Redakteur, wenn es sich um ein paar Bilder handelt. Was aber, wenn es mehrere hundert Bilder sind? IRRE mit hunderten von Datensätzen macht keinen Spaß. 

Nun liegt der Gedanke nahe, einfach anders herum zu gehen: Wir legen einfach eine n:1-Verbindung von Model B (Image) zu Model A (Location) an. Im Backend ist das Ergebnis perfekt: Im Location-Datensatz sind die IRRE-Relationen zu den Bildern weg, während jetzt ein DropDown im Image-Datensatz erscheint, in dem die Location ausgewählt werden kann. Aber leider wird jetzt das Objekt auch anders herum gemappt: Model A (Location) enthält keinen Bezug mehr zu Modul B (Image) und die Locationliste zeigt somit keine Bilder mehr. Dagegen funktioniert es jetzt anders herum: die Bildliste enthält jetzt die Locations, was ich nicht brauche. 

Was ich erreichen will: 

Das Backend soll sich verhalten wie oben beschrieben, es soll also ein DropDown in den Bilderdatensätzen erscheinen, in dem ich die Location auswähle. Im Extensionbuilder erhalte ich das über eine n:1-Relation in Model B (Image). Für die Frontendausgabe brauche ich jedoch eine Liste der Locations mit den Bildern, was ich bekomme, wenn ich im Extensionbuilder eine 1:n-Relation in Model A (Locations) anlege. 

Wie bekomme ich das aufeinander? 

Datenbank

ich lege in der Datenbank zwei Felder an: in der Location-Tabelle das Feld "images" und in der Image-Tabelle das Feld "locations". Beide bekommen int(11) als Format. 

TCA

Im TCA der Location-Tabelle erstelle ich eine Definition für das Feld "images" in dieser Art: 

'type' => 'inline'
'foreign_table' => '….…._image',
'foreign_field' => 'locations',

damit erhalte ich das IRRE-Feld im Location-Datensatz. Im TCA der Image-Tabelle wird das Feld "locations" so definiert: 

'type' => 'select',
'foreign_table' => 'tx_camplist_domain_model_location',

wobei ich als Typ angeben kann, was ich benötige, hier ein Select, also je nach den weiteren Definitionen entweder ein Auswahlfeld oder ein DropDown. 

Objektmapping in beiden Models

Beide Models erweitere ich nun um die Objekt-Attribute $images im Location-Model (die Kommentare nicht vergessen!) und $locations im Image-Model. Dazu natürlich in beiden Models die passenden Getter und Setter ergänzen. 

Abschluss

Man kann jetzt im Backend die Bilder auf zwei Arten hinzufügen: entweder direkt als Datensatz und dort die Location in einem Dropdown auswählen, oder über IRRE im Location-Datensatz. Wenn ich die IRRE-Felder im Location-Datensatz verstecken will, so lösche ich im TCA der Location-Tabelle unter "types.1.showitem" den Eintrag "images". 

Kategorien: API  Kommentare 0

Bisher war das Risiko relativ gering, wenn man Google Analytics nicht datenschutzkonform eingesetzt hat. Die einzige Konsequenz, die man fürchten musste, waren bisher Bußgeldverfahren seitens der Datenschutzbeauftragten. Mittlerweile scheint es aber häufiger Abmahnungen in diesem Bereich zu geben: 

Abmahnung: 1.200 Euro wegen Fehlern beim Einsatz von Google Analytics?

Die Abmahnungen sind offenbar nicht unproblematisch, da der Abmahngrund (Verstoß gegen das allgemeine Persönlichkeitsrechtes) in dem Zusammenhang umstritten ist. Aber auch umstrittene oder problematische Abmahnungen dürfen nicht einfach ignoriert werden, sondern man muss sich juristisch dagegen wehren, was mindestens lästig und oft auch teuer ist. 

ich möchte deshalb nochmals ausdrücklich empfehlen, Google Analytics korrekt einzusetzen, und die datenschutzrechtlichen Auflagen zu befolgen. Das wären: 

  • Beschneiden der IP-Adressen um das letzte Triplet
  • Vertrag mit Google über die Datenverarbeitung
  • Datenschutzerklärung und Widerrufhinweis
  • Löschen der bereits vorhandenen Daten

Eine gute Zusammenfassung ist bei datenschutzbeauftragter.info zu finden. 

Alternativ kann auch PIWIK eingesetzt werden, aber Achtung: auch hier gelten die obigen Punkte, lediglich der Vertrag mit Google entfällt, eine Anleitung dazu gibt es zum Besipiel hier: Piwik datenschutzkonform einsetzbar, oder wieder bei datenschutzbeauftragter.info

 

 

In den neueren Versionen von TYPO3 kann man recht einfach beliebige Lightboxen einbauen, ohne dafür spezielle Extensions zu benötigen. Ich möchte möglichst wenig Extensions verwenden, um Inkompatabilitäten zu verringern, Updates zu erleichtern und vor allem um das Risiko von Sicherheitslücken zu vermindern. Wie man dazu prinzipiell vorgeht, möchte ich kurz am Beispiel der Slimbox zeigen. 

(Kleiner Tipp: wie es TYPO3 4.x geht, steht in diesem älteren Artikel.)

Slimbox ist ein ganz nette Lightbox, die den großen Vorteil hat, sehr klein zu sein. Sie hat zwar wenig Features und ist nicht responsiv, aber zumindest das letztere ist nicht unbedingt ein Nachteil, weil auf einem Smartphone keine Lightbox gut funktioniert, auch keine responsive. Am Smartphone ist keine Lightbox immer noch die beste Lightbox. 

Nun, hier gehts auch nur ums Prinzip, man kann das mit beliebigen anderen Lightboxen auch umsetzen. 

Schritt 1: Lightbox korrekt einbinden

Praktisch alle Lightbox-Scripts sind so aufgebaut, dass man im Head zuerst jQuery laden muss, danach das Lightbox-Script sowie ein kleines JavaScript-Snippet als Autoloader oder Trigger. Ausserdem muss man natürlich das CSS einbinden. Also im Typoscript-Setup der Installation etwa so: 

  1. page.includeJSlibs {
  2.  # zuerst das aktuelle jQuery laden
  3.  10 = fileadmin/js/jquery.min.js
  4.  10 {
  5.   forceOnTop = 1
  6.  }  
  7.  # danach slimbox
  8.  20 = fileadmin/js/slimbox2.js
  9.  # und mein eigenes JavaScript
  10.  30 = fileadmin/js/main.js
  11. }

Dabei natürlich die Pfade angeben, in denen die Dateien auch liegen. Und das CSS: 

  1. page.includeCSS { 
  2.  10 = fileadmin/css/slimbox2.css
  3.  10.media = screen
  4. }

Jetzt fehlt noch der Trigger bzw. Autoloader. Für die Slimbox kann der zum Beispiel so aussehen: 

  1. if (!/android|iphone|ipod|series60|symbian|windows ce|blackberry/i.test(navigator.userAgent)) {
  2. ­  jQuery(function($) {
  3. ­  ­  $("a[rel^='lightbox']").slimbox({
  4. ­  ­  ­  ­ // hier können weitere Optionen eingefügt werden
  5. ­  ­  ­  ­­ counterText: "Bild {x} von {y}"
  6. ­  ­  }, null, function(el) {
  7. ­  ­  return (this == el) || ((this.rel.length > 8) && (this.rel == el.rel))
  8. ­  ­  });
  9. ­  });
  10. }

Das "counterText" ist nicht unbedingt nötig, aber man kann damit den Text übersetzen. Im Original ist der Hinweistext sonst englisch.


[mehr]

Tipp: Dieser Artikel ist ein Update eines älteren Artikels zum gleichen Thema: Links im RTE auf Datensätze (News, t3blog) mit der Extension linkhandler. In den neuen Versionen von TYPO3 hat es einige Änderungen gegeben, so dass dieser Artikel nicht mehr genau stimmt. 

Zuerst haben wir das Problem, dass die Extension linkhandler unter TYPO3 6.x nicht mehr funktioniert und sogar das Backend unzugänglich macht, wenn sie über den Extensions-Manager installiert wird. Also mein Tipp: auf keinen Fall über den Extensionsmanager installieren, sondern diesen Fork von Github verwenden. Einfach herunterladen, das zip-Archiv auspacken und den entstehenden Ordner umbenennen in »linkhandler«. 

Danach gehts genau so weiter, wie in meinem Artikel beschrieben: es braucht zuerst eine Konfiguration des Linkbrowsers im TSconfig der Root-Seite. Diese kann für die neue News-Extension zum Beispiel so aussehen: 

  1. RTE.default.tx_linkhandler {
  2.   # beliebige Bezeichnung
  3.   tx_news {
  4.       # label / Karteikarte im Widget
  5.       label=News
  6.       # Tabellenname
  7.       listTables=tx_news_domain_model_news
  8.       # nur die Seiten im Seitenbaum zeigen, die auch die
  9.       # gewünschen Datensätze enthalten.
  10.       onlyPids=18
  11.   }
  12. }

Bei onlyPids müsst ihr natürlich die UID der Seite eintragen, auf der sich eure News-Datensätze befinden. Oder die Zeile auskommentieren, allerdings muss dann der ganze Baum nach News durchsucht werden, wenn man einen Link erstellen will. So ist es für den Redakteur bequemer.

Analog kann man den Linkhandler auch noch für die sonstigen Inhaltselement konfigurieren: 

  1. mod.tx_linkhandler {
  2.   # beliebige Bezeichnung
  3.   tx_news {
  4.       # label / Karteikarte im Widget
  5.       label=News
  6.       # Tabellenname
  7.       listTables=tx_news_domain_model_news
  8.       # nur die Seiten im Seitenbaum zeigen, die auch die
  9.       # gewünschen Datensätze enthalten.
  10.       onlyPids=18
  11.   }
  12. }

Danach muss im Typoscript-Setup der Link konfiguriert werden: 

  1. plugin.tx_linkhandler {
  2.   # Tabellenname
  3.   tx_news_domain_model_news {
  4.       # Link erzwingen, auch wenn die News versteckt ist
  5.       forceLink = 0
  6.       # typolink settings
  7.       parameter = 23
  8.       # alle nötigen Parameter
  9.     additionalParams = &tx_news_pi1[news]={field:uid}&tx_news_pi1[controller]=News&tx_news_pi1[action]=detail
  10.    additionalParams.insertData = 1
  11.       # use caching
  12.     useCacheHash = 1        
  13.  }
  14. }

Bei parameter muss die UID der Seite eingefügt werden, welche die Single-Darstellung der News enthält. Bei additionalParams müssen alle zusätzlichen Parameter rein, die für den Aufruf des richtigen Datensatzes nötig sind – hier dargestellt für die neue News-Extension. 

Die Unterschiede zur früheren Fassung sind also nicht gravierend, so dass ich für weitere Varianten einfach nochmals auf den alten Artikel verweisen möchte. Dort ist zum Beispiel noch beschrieben, wie man mit mehreren verschiedenen Ausgabeseiten arbeiten kann.  

Besuchen Sie mich auf Google+