Schnellnavigation:

Kategorien

« März 2024»
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            

Letzte Nachrichten

DSGVO
26.05.2018 18:39
Trackingtools und Datenschutzerklärung
14.03.2014 23:07
1:n und n:1 Relationen in Extbase
06.12.2013 12:04
Erste Abmahnungen wegen Google Analytics
04.10.2013 12:11

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 ... 

Zur Zeit wird gefiltert nach: Tipps
Filter zurücksetzen

26Mai2018

DSGVO

Um diese - mittlerweile reichlich veraltete - Seite noch etwas weiter betreiben zu können, habe ich einige Änderungen vorgenommen, um sie an die DSGVO anzupassen. 

Neue Datenschutzerklärung

Ich habe meine Datenschutzerklärung an die Richtlinien der DSGVO angepasst. Sie finden Sie an der alten Stelle, nämlich hier: Datenschutzerklärung

Social Media

ich habe die Social Media Leiste mit den Like und Share-Buttons aus dem Footer entfernt. Grund war allerdings nicht nur die umständliche Anpassung an die DSGVO sondern auch die Tatsache, dass Like- und Sharebuttons so gut wie nicht genutzt wurden. 

Kommentare

Ich habe die Kommentarmöglichkeit entfernt. Da ich kaum mehr neue Artikel schreibe, bestanden praktisch alle Kommentare in den letzten zwei Jahren nur noch aus Spam. 

Google Analytics und Cookies

ich habe festgestellt, dass ich Google Analytics eigentlich nicht nutze, und habe es deshalb entfernt. Diese Seite führt also keinerlei Besuchertracking mehr durch und setzt somit auch keine Cookies mehr. 

Demos

Einige meiner Demos (z. B. Gästebuch und Warenkorb) waren schwierig an die DSGVO anzupassen - zumal sie ja nur Demos sein sollten, keine ernsthaften Installationen. Da sie ausserdem reichlich veraltet waren, und den Bsuchern somit keinen Nutzen merhr bringen, habe ich Demos, die Formulare enthalten, einfach entfernt. 

SSL

SSL ist generell eine gute Idee, und mittlerweile kein großer Aufwand mehr, deshalb läuft diese Seite jetzt unter https. Damit sollte auch das Kontaktformular ausreichend abgesichert sein. 

Eine dringende Bitte an alle, die E-Mails beruflich verwenden: verschlüsseln Sie Ihre Mails. 

Damit beziehe ich mich nicht nur auf PRISM & Co., obwohl ich gerne zugebe, dass es der Anlass ist, das Thema zu forcieren. Aber leider erhalte ich immer wieder E-Mails mit Zugängen und Passwörtern in Klartext. Niemand muss sich wundern, wenn er Opfer von Hackern wird, wenn er Zugänge und Passwörter in unverschlüsselten E-Mails versendet. 

E-Mail wird gerne mit einer Postkarte verglichen, die jeder lesen kann. Das ist aber nur teilweise richtig. E-Mail ist nämlich sehr viel öffentlicher als eine Postkarte: E-Mail ist wie eine bereits digitalisierte, perfekt maschinenlesbare Postkarte, die jemand ins Internet geworfen hat. E-Mails mit Passwörtern oder gar kompletten Logins sind Einladungen zu einem Hacker-Festival. 

Es ist nicht schwierig und kostet nur eine Viertelstunde. 

Wer weitere einfache und übersichtliche Anleitungen kennt, möge mir bitte den Link senden, oder in einem Kommentar drauf hinweisen. Ich nehme den Link dann hier auf. 

 

 

Kategorien: Developer/Tipps  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. 

Es ist prinzipiell möglich, den RTE in Flexforms – und damit auch in FCEs – zu konfigurieren. Wie das geht, wird  im Wiki auf typo3.org beschrieben, oder in der API-Dokumentation (nach »defaultExtras« suchen). Mit diesem Eintrag in den defaultExtras wird der RTE z. B. beschränkt auf fett, kursiv und Links:

  1. <defaultExtras>richtext[bold|italic|link]:rte_transform[mode=css]</defaultExtras>

Oder vielmehr sollte ... es funktioniert nämlich nicht mehr. Es gibt einen Bug-Report dazu, dem auch ein Patch für die Core-Klasse class.t3lib_tceforms beiliegt. Nach dem Einspielen des Patch funktioniert es wieder. 

Kategorien: API/Tipps  Kommentare 0
Tags: rte, fce

Im RTE kann man horizontale Linien einfach mittels Blockstilen zur Verfügung stellen, die einem Absatz zugewiesen werden können. Diese Stile müssen allerdings vom Entwickler zur Verfügung gestellt werden. 

Dieser Absatz hat z. B. eine Linie oberhalb, die auf diese Art eingefügt wurde. 

Der RTE kann allerdings auch das HTML-Element <hr /> einsetzen, das unabhängig ist von den Blockelementen bzw. Absätzen.

Standardmäßig macht der RTE dabei leider einen Fehler: er packt die Linie in einen Absatz: <p><hr /></p>, was beim Validieren der Seite zu einem Fehler führt. Dieser Fehler stört allerdings die optische Darstellung nicht, wer also mit einem Validierungsfehler leben kann, muss nichts weiter unternehmen. 

Der Fehler kann eleminiert werden, wenn in das TypoScript-Template der Seite diese Zeilen eingefügt werden:

  1. lib.parseFunc_RTE.externalBlocks := addToList (hr)
  2. lib.parseFunc_RTE.externalBlocks.hr.stripNL = 1

Leider hat das aber andere negative Konsequenzen. Wenn ich z. B. hier so eine Linie einfüge:


werden die folgenden Absätze nicht mehr richtig geparst. So werden z. B. in meinen Code-Snippets der <pre>-Tag nicht mehr korrekt von  tx-vjrtecodesnippets erkannt und geparst: 

lib.parseFunc_RTE.externalBlocks := addToList (hr)
lib.parseFunc_RTE.externalBlocks.hr.stripNL = 1


Ausserdem werden offensichtlich Links nicht mehr geparst. Das ganze ist ein Problem, das offenbar seit 2007 im Bugtracker steht, aber bis heute nicht wirklich gelöst wurde (hier sollte eigentlich ein Link stehen, der aber nicht geparst wird. Er folgt im nächsten Absatz, den ich in ein neues Inhaltselement packe.) 

Fazit:

Ich empfehle die Verwendung von Blockstilen wie ganz oben beschrieben. Wenn man unbedingt <hr /> verwenden muss, so sollte der Workaround gründlich getestet werden. Wenn – wie bei mir hier – die Fehler nicht gefixt werden können, dann muss man wohl oder übel mit dem Syntaxfehler des RTE leben. Wie gesagt: die Darstellung ist ja korrekt, es gefällt nur den Validatoren nicht.

Und hier ist der Link in den Bugtracker nochmals ...

[Update]
Für den Bug gibt es seit kurzem einen Fix im Bugtracker von Stanislas Rolland, der das Problem behebt. (Vielen Dank an Stanislas!)

Also Patch einspielen, oder aufs nächste Update von TYPO3 warten, dann wirds wohl dabei sein. 

[Update 2]

In Version 4.4.6 funktioniert es jetzt. 

Kategorien: Tipps/Typoscript  Kommentare 0
Tags: rte