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: Developer
Filter zurücksetzen

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

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.  

Websites werden regelmäßig überarbeitet und Redesigns unterzogen. Die Gründe sind vielfältig: altbackenes Design muss dringend modernisiert werden, Verbesserungen in der Benutzerführung sind überfällig, die Kunden erwarten neue technische Möglichkeiten, oder es haben sich Geschäftsbereiche geändert. Redesigns sind nötig und können eine große Chance sein. 

Aber sie sind auch ein Risiko – nämlich wenn bei der aufwändigen Arbeit mit Design, Struktur und Usability die Suchmaschinen vergessen werden. Es reichen ein paar Fehler, und das Redesign führt zu einem massiven Absturz in den Suchmaschinen. Einem Absturz, von dem sich die Site monatelang nicht erholt. 

Der wichtigste Grund ist simpel: ein Redesign ist meist mit einer Änderung der technischen Basis und häufig mit einer internen Umstrukturierung der Inhalte verbunden. Das heißt, eine Seite die vorher über eine URL wie /index.php?id=123 erreicht wurde, ist jetzt vielleicht so zu erreichen: /produkte/kategorie/mein-tolles-produkt1/. Eigentlich ein Fortschritt, da die alten URLs mit Parametern durch sprechende URLs ausgetauscht wurden. Aber leider sind jetzt alle alten Links nicht mehr aufrufbar bzw. enden in einem 404-Fehler (Seite nicht gefunden). 

Und solche SEO-Fehler haben leider Konsequenzen: 

  • Alle externen (Back-)Links, die bisher auf unsere Site verlinkt haben, sind nicht mehr gültig. Damit landen potentielle Kunden, die auf solche Links klicken, auf einer Fehlerseite.
  • Backlinks sind aber essentiell für die Gewichtung der Site gegenüber der Konkurrenz.  Ohne Backlinks landet unsere Site in den Trefferlisten der Suchmaschinen eher weiter unten, nach der Konkurrenz mit Backlinks.  
  • Die Suchmaschinen nehmen die alten URLs nicht sofort aus dem Index, sondern senden noch monatelang Besucher auf die alten Seiten und damit auf die Fehlerseite. 
  • Aufgrund der Vielzahl von zerbrochenen Links wird unsere Site in den Suchmaschinen zusätzlich abgewertet. 

Das wollen wir vermeiden. 

1. Analyse des Ist-Zustands

Die URL-Struktur der alten Site muss analysiert werden: 

  • welche Seiten werden verschoben
  • welche Seiten fallen weg 
  • welche Backlinks gibt es, welche sind die wichtigsten
  • welche Backlinks fallen durch die Umstrukturierung evtl. weg

Ausserdem sollte der Prozess der Umstrukturierung durch Analyse-Tools überwacht werden. 

2. verschobene Inhalte

Wenn Inhalte verschoben werden (bzw. wenn sich ihre URL ändert) muss für jede URL eine 301-Weiterleitung eingerichtet werden. Die Suchmaschinen wissen dann, dass der alte Inhalt unter einer neuen URL erreichbar ist, und passen ihre Trefferlisten an. Je nach Größe der Site und Ausmaß der Umstrukturierung kann das Einrichten dieser Weiterleitungen sehr aufwändig werden, evtl. muss für jede geänderte URL manuell eine Weiterleitung eingerichtet werden. Die Umstrukturierung der Seiten sollte deshalb so vorgenommen werden, dass allgemeine Regeln für die Weiterleitungen eingerichtet werden können. 

3. zu entfernende Inhalte

Seiten, die nicht mehr benötigt oder nicht mehr erwünscht sind, sollten ebenfalls zuerst analysiert werden. Wenn sie keinen Traffic bringen (und keine Backlinks auf sie verweisen!), spricht nichts dagegen, sie auf eine 404-Seite zu leiten und damit aus dem Suchmaschinen-Index entfernen zu lassen. Wenn sie aber Traffic bringen – oder gar Ziel von wichtigen Backlinks sind –, ist es ratsam, die Seiten nicht zu löschen und statt dessen die Inhalte zu überarbeiten und auf die Traffic-bringenden Keywords zu optimieren. Diese Seiten sind Kapital, kein Ballast. 

4. On-Site-Optimierung

Grundsätzlich muss eine On-Site-Suchmaschinenoptimierung bereits in die Planung eines Redesigns  einbezogen werden. Es ist viel günstiger, die technische Optimierung von Anhang an zu berücksichtigen, als nach dem Relaunch Fehler oder Schwächen auszubessern. Alle technischen Aspekte des Redesigns sollten sich den SEO-Zielen unterordnen oder diesen zumindest nicht im Wege stehen.

Natürlich müssen diese Ziele vorab definiert werden: Wenn ich nicht weiß, wo die Reise hingeht, kann ich mich auch nicht darauf vorbereiten.  

Kategorien: Developer/SEO/Sonstiges  Kommentare 0
Tags: seo

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