Kategorie: Allgemein

Veröffentlicht am

CMS 2021 – die 3 wichtigsten CMS-Trends und Entwicklungen 2021

Der Markt für Web Content-Management-Systeme (CMS) ist 2021 im Wandel. Viele neue Entwicklungen und Schlagworte wie Headless und Content-Driven-Commerce verändern die Anbieter-Landschaft und die Ökosysteme rund um Open Source CMS und kommerzielle CMS-Hersteller. Wer sind die Gewinner dieser Entwicklung? Wer die Verlierer? Welche alten Spieler am CMS-Markt werden immer bedeutender? Welche Technologien treiben die Entwicklung voran?

Passendes CMS schnell finden

Wer jetzt gerade ein CMS für sein (neues oder altes) Projekt sucht, findet über den interaktiven Vergleich: „Welches CMS ist das beste für mein Projekt?“ am schnellste die richtige Antwort. Die aktuellen Analysen dieses Artikels sind in den Ratgeber eingeflossen. Für alle anderen gibt es hier den Überblick über die drei wichtigsten CMS-Entwicklungen 2021.

WordPress ist und bleibt King

Dutzende neue CMS und Technologien kommen jedes Jahr auf den Markt, Wettbewerber bauen ihr Feature-Set aus, aber dennoch schafft es keiner, Platzhirsch WordPress vom Thron zu stoßen.

Im Gegenteil: Im März 2021 konnte WordPress seinen sowieso schon überragenden Marktanteil unter den CMS auf über 40 % ausbauen! [1] Zum Vergleich: 2015 lag dieser Wert noch bei circa 23 %, 2011 noch bei 13 %. Gerade für kleinere und mittelgroße Projekte bleibt das Open Source CMS damit immer noch die erste Wahl und überholt dieses Jahr sogar die Zahl der Seiten, die ohne CMS gebaut werden. Bis 2025 könnte WordPress das Backend für die Hälfte aller Internet-Seiten werden. [2]

Mancher mag argumentieren, dass dies nur am bereits vorhandenen riesigen Ökosystem liegt, das mit über 50.000 Plugins, einer Armada an verfügbaren Freelancern und Agenturen, sowie Tutorials, Quellen und Marketing-Tools in der CMS-Welt ungeschlagen ist. Natürlich ist das ein gewichtiges Argument, das für WordPress spricht, aber man muss dem CMS auch zugutehalten, dass in den letzten Jahren auch massive Verbesserungen an der Software vorgenommen wurden.

Der neue Gutenberg-Editor zum Beispiel, wird zwar auch von vielen alteingesessenen WordPress-Fans kritisiert, verbessert für Einsteiger aber die Authoring-Experience, die bisher vielleicht nur ähnlich intuitive Block-Editoren, wie z.B. den bekannten Medium-Editor gewohnt waren. Seit der Version 5.7 „Esperanza“, gibt es sogar eine Drag-and-Drop-Funktion, mit der man Blöcke einfach an die passende Stelle ziehen kann.

Das Plugin-System hat immer noch seine Kehrseiten und auch 2021 sehen wir bereits erste Angriffsvektoren durch Plugins, die wieder Millionen von Webseiten betreffen. [3] Erinnerungen werden wach, an den Hack des Revolution-Slider-Plugins, der übrigens zum Leak der berüchtigten Panama-Papers führte.[4] Darin sieht man auch schon, dass WordPress zwar für jeden Einsteiger geeignet ist, aber ohne professionellen Support, die eigene Seite schnell zum Hacker-Ziel werden kann.

TLDR / Fazit

WordPress bleibt King und wer darauf setzt, kann sich sicher sein, die nächsten Jahre im größten und lebendigsten Web-Ökosystem der Welt zu agieren. Man sollte mit keinem anderen System schneller und einfacher Out-of-the-box-Lösungen finden. Sicherheit bleibt jedoch Problemthema Nr. 1 für WordPress. Gerade große Mittelständler und Enterprise sollten (im Bereich der traditionellen CMS) daher weiter bei den schweren Geschützen wie Drupal, TYPO3, Neos oder AEM bleiben.

Content und E-Commerce sind Eins

Personalisierte, Content-getriebene Kundenerlebnisse werden (auch aufgrund Covid) zum Pflichtprogramm für viele E-Commerce-Anbieter. Es reicht nicht mehr seine Produkte in einen Online-Shop zu packen und nebenher noch einen Blog zu betreiben.

Kunden, die bisher für Beratung vielleicht immer noch in ein lokales Geschäft gingen, sind jetzt auf integrierte Online-Informationen im Rahmen des Shopping-Erlebnisses angewiesen. Moderne CMS vereinen Content mit Produkten und Dienstleistungen und machen Content zum E-Commerce-Treiber. Dazu zählen Features wie:

  • Integrierte Chatsysteme und KI-basierte Chatbots, die direkte Beratung auf der Plattform ermöglichen, wie z.B. von HubSpot CMS Hub angeboten.
  • Enge Verzahnung von Content und E-Commerce-Modulen durch Anbindung des CMS an E-Commerce-Systeme, leistungsstarke E-Commerce-Plugins oder PIM-Systeme. Produktdaten sollten zum Beispiel für Autoren während der Content-Erstellung verfügbar sein und automatisch upgedatet werden.
  • Integrierte Personalisierungsfunktionen direkt im CMS, wie sie zum Beispiel AEM anbietet.
  • Integrierte Conversion-Optimierung wie A/B-Tests

TLDR / Fazit

E-Commerce muss 2021 noch Content-getriebener werden, um die wachsenden Herausforderungen – vor allem für beratungsintensive Produkte und Dienstleistungen – zu meistern. Dazu zählen: Integrierte Chatsysteme, Personalisierung, Conversion-Optimierung und die enge Verzahnung von Content und Produktdaten.

Headless und der JAMStack

Headless CMS schießen wie die Pilze aus dem Boden und Begriffe wie JAMStack, GraphQL, Markdown, React, Vue und Komponenten-basierte Entwicklung dominieren die „hippe“ Webszene. Die moderne Webentwicklung ist fest im Klammergriff der sich immer schneller drehenden JavaScript-Welt und wer hier nur Bahnhof versteht, dem dient dieser kurze Überblick über die aktuelle Entwicklung:

Headless

Headless ist ein CMS, das keine eigenen HTML-Webseiten generiert, die sich Nutzer ansehen könnten und daher auch keine Templates oder Designs bereitstellt. Stattdessen werden die Inhalte über eine API ausgeliefert. Die Idee dahinter ist, dass die Inhalte so von vielen verschiedenen Anwendungen konsumiert werden können, wie z.B. mehreren unterschiedlichen Webseiten, Single-Page-Anwendungen, aber auch mobilen Apps, oder gar IoT-Geräten und sprachgesteuerten Systemen wie Amazons Alexa. Oft sind die Webseiten, die Headless CMS nutzen, sogenannte JAMStack-Seiten.

JAMStack

Der Begriff steht für JavaScript, API und Markup. Die Grundidee ist recht einfach: Nicht ein monolithisches CMS mit Datenbank, Autoren-Backend und Frontend-Templates erzeugt die Webseiten, sondern ein Page-Builder wie Gatsby oder Next.js, der seine Daten aus einer API bezieht und mithilfe von Markup-Dateien (z.B. in Markdown oder HTML) daraus fertige Webseiten generiert. Diese Seiten werden nicht dynamisch zur Aufrufzeit generiert, sondern vorher in einem separaten Schritt gebildet und dann abgespeichert. Wenn sich Daten ändern, wird dieser Schritt wiederholt. Als API und Datenlieferant dient meist hauptsächlich ein Headless CMS.

Dieses Vorgehen erlaubt das Hosting der fertigen, zum Build-Zeitpunkt erstellten HTML-Seiten in einem globalen CDN und die blitzschnelle, weltweite und kosteneffiziente Auslieferung der Webseite an die Endkunden. In Zeiten, in denen die Ladezeit der Webseite die mobile User Experience, das SEO-Ranking und die eigene Conversion Rate massiv beeinflusst, wird dies zum obersten Verkaufsargument der JAMStack-Bewegung. Darüber hinaus gewinnt man natürlich große Sicherheitsvorteile, wenn man auf die dynamische Generierung von Webseiten verzichtet, weil SQL-Injections so gut wie unmöglich werden (Siehe WordPress oben…).

Zukunft

Headless CMS erfahren ein massives Wachstum und sind dabei den CMS-Markt 2021 und darüber hinaus massiv umzuwälzen. Mit einer prognostizierten jährlichen Wachstumsrate von über 22 % pro Jahr auf ein Marktvolumen von 1,6 Milliarden Dollar werden sie Zukunft eine bedeutende Rolle spielen und viele ältere Wettbewerber aus dem Markt verdrängen.[5] Gerade durch die zunehmende Bedeutung von Multi-Channel-Experiences, wie mobilen Apps und IoT-Geräten, wird ein zentraler Content Hub, wie ihn nur ein Headless CMS bietet, essenziell.

Dennoch hat sich 2019 und 2020 gezeigt, dass der JAMStack und Headless nicht die allein seligmachende Lösung sind und eigene Probleme mitbringen. Insbesondere die strikte Trennung von Authoring und Frontend-Entwicklung stellt für Design-orientierte Autoren-Teams ein großes Problem dar, das reine Headless-Anbieter wie zum Beispiel Contentful noch nicht gelöst haben. Hier bieten Alternativen wie Storyblok bereits Abhilfe, indem sie WYSIWYG und Inline-Editing ein Stück weit in die Headless Welt hineinbringen.

Auch Hybride CMS wie zum Beispiel Craft CMS im E-Commerce, FirstSpirit im Enterprise-Bereich und inzwischen auch WordPress können hier Vorteile gewinnen, weil sie zwar ein Frontend besitzen, aber eben auch eine API für den Headless-Einsatz. Außerdem können Redakteure so in ihrer gewohnten Umgebung bleiben und müssen sich nicht an neue User-Interfaces gewöhnen, wenn das bisher verwendete traditionelle CMS auch Headless verwendet werden kann.

Viele reine Headless CMS sind momentan auch nur als SaaS-Produkte der jeweiligen Hersteller verfügbar – Self-Hosted-Systeme und Open Source wie z.B. Strapi sind noch Mangelware. Das hat zwar einerseits den großen Vorteil, das man sich Hosting, Wartung und Konfiguration des Systems spart, aber auch den Nachteil, dass man an einen Anbieter gebunden ist und sich von diesem abhängig macht (Vendor-Lock-In). Gerade bei wachsenden Projekten kann einem dann doch das ein- oder andere Feature fehlen, das man dann nicht einfach schnell „nachrüsten“ kann. Selbst wenn der SaaS-Anbieter sehr viele Features und Leistungen im Angebot hat, muss man dazu oft auf sehr kostspielige Enterprise-Pakete umsteigen, die plötzlich in einer ganz anderen Preisliga spielen, als das ursprüngliche Einstiegspaket.

TLDR / Fazit

Headless CMS sind neben WordPress der am schnellsten wachsende Sektor im CMS-Bereich. Wer sie nicht auf dem Schirm hat, verpasst eine großartige Zukunftstechnologie für Multi-Channel-Anwendungen und den mobilen Markt. Die problematische Authoring-Experience vieler Headless CMS wird 2021 zum Key Differentiator für viele noch junge Headless-Systeme werden. Der Mangel an Open-Source und selbstgehosteten Projekten wird viele Unternehmen weiter zu hybriden CMS wie Craft, Drupal oder WordPress greifen lassen.

[1] https://w3techs.com/technologies/history_overview/content_management/all/y

[2] https://t3n.de/news/2025-50-prozent-wordpress-marktanteil-verbreitung-1341872/

[3] https://t3n.de/news/wordpress-sicherheitsluecken-1356976/

[4] https://www.wordfence.com/blog/2016/04/panama-papers-wordpress-email-connection/

[5] https://www.businesswire.com/news/home/20210219005435/en/1.62-Billion-Headless-CMS-Software-Market-Forecast-to-2027—Global-COVID-19-Impact-and-Analysis-by-Deployment-Type-and-Enterprise-Size—ResearchAndMarkets.com

Veröffentlicht am

Südwestfalenaward 2018

TL;DR: Gewinner in der Kategorie „Technik“ – fett!

 Der südwestfalenaward ist – laut eigener Aussage – für Unternehmen, Vereine, Verbände und Institutionen in der Region die Gelegenheit, über die eigene Internetpräsenz das unternehmerische und gestalterische Web-Know-how zu präsentieren und damit gegenüber der weborientierten Zielgruppe offensiv und innovativ aufzutreten.
Zudem können Web-Designer, Grafiker, PR- und Werbeagenturen – also im weitesten Sinne auch Digitalagenturen wie wir – zeigen, welche Möglichkeiten realisierbar sind. Für Kunden innerhalb und außerhalb der Region.

Heute am 06.12.2018 wurde er in der IHK Arnsberg vergeben. Dieser wurde in verschiedenen Kategorien vergeben:

Technik-Award

Kaum da, wurden auch die Nominierten dieser Kategorie bekannt gegeben:

Alle von uns, alle großartig! Den Preis haben wir – stellvertretend für unser atemberaubendes Team, einen leidenschaftlichen Betreiber Class Brothers GmbH und coolen Auftraggeber – für eines unser größten Projekte Louder.com angenommen. Somit sind dann auch „ein paar“ Überstunden, etliche Merge-Konflikte, Bugs und Schweiß irgendwie „ausgezahlt“. Danke an der Stelle an alle Juroren, die dieses Urteil teilen und die Seite mit diesem Preis ausgezeichnet haben!

Sonderpreis

Der Sonderpreis ging dieses Jahr an eine uns nur zu bekannte Agentur: David und Goliath! Dabei ist wohl die mitwirkende Rolle wie der Vision Lüdenscheid 2020, der Verbundenheit zu Südwestfalen und diverse andere Projekte nicht ganz unschuldig! Verdient bekommen, Gratulation auch hier noch mal: Weitermachen, ihr seid eine abgefahrene Flyer-, Bildchen-, Prospekte-, Reklame- und auch Internetfirma!

Veröffentlicht am

Google Fonts DSGVO-Konform auf dem eigenen Webserver nutzen

Warum ist Google Webfonts eigentlich nicht DSGVO-konform?

Bei der Nutzung von Typografie-Anbietern wie Adobe Typekit, Google Fonts o.ä. werden die Schriften für jeden Webbesucher von den Servern des jeweiligen Betreibers geladen. Damit diese Schriftarten geladen werden, wird jedoch von jedem einzelnen Nutzer auch eine Anfrage an den jeweiligen Dienst gerichtet. Das bedeutet, dass personenbezogene Daten durch die Nutzung der eigenen Webseite einen Dritten weitergegeben werden und das ohne Einverständnis des Benutzers der Webseite.

Mit dem entsprechenden Anbieter kann ich in der Regel auch keinen Vertrag zur Auftragsdatenverarbeitung (kurz ADV) schließen, sodass ich den rechtmäßigen Gebrauch der Daten nicht kontrollieren kann. Das führt zu einer rechtlichen Grauzone, in der man sich hier bewegt, weshalb man hier ggf. handeln möchte.

Im juristen-Deutsch heißt es: „Die Einbindung von Drittanbieter-Tools und Plugins ist mit datenschutzrechtlichen Risiken und rechtlichen Unsicherheiten verbunden, wenn diese ungefragt personenbezogene Daten von Website-Besuchern speichern/ übertragen.“. Bei Google Fonts im speziellen: „Ein bloßer Hinweis in der Datenschutzerklärung ist aus Sicht vieler Datenschutzbehörden und Gerichte in diesen Fällen dann nicht ausreichend. Prüfen Sie bitte, ob und unter welchen Voraussetzungen die von Ihnen eingesetzten Tools und sonstigen Funktionen datenschutzkonform einsetzbar sind. Viele Anbieter bieten DSGVO-konforme Lösungen für die Datenverarbeitung in der EU an. Fragen Sie bitte dazu bei dem betreffenden Anbieter an. Wenn der Anbieter keine datenschutzkonforme Lösung ermöglicht, müssen Sie eine ausdrückliche Einwilligung der Nutzer einholen. Andernfalls drohen Abmahnungen und Bußgelder.“. Da Google Fonts hier keine Lösung anbietet und man vermutlich auch keine Einwilligung hierüber hat (Ein Hinweis à la „Es werden Cookies eingesetzt…“, der im Nachgang angezeigt wird, zählt nicht als Einwilligung.).

Google Webfonts DSGVO-konform einbinden

Da die Einbindung wie oben erklärt nicht zweifelsfrei rechtskonform ist, ist eine Einbindung über die Google Server nicht rechtssicher möglich. Somit müssen die Schriften auf dem Webserver der Webseite gehostet werden, damit die Daten DSGVO-konform genutzt werden können.

Bisher wurden Schriftarten ungefähr wie folgt eingebunden:

<link href="https://fonts.googleapis.com/css?family=Roboto" rel="stylesheet">


Dieser CSS-Stylesheet hat hier in der Regel einen zusätzlichen Stylesheet für die einzelnen Schriftarten eingebunden, der wie folgt aussah:

@font-face {<br>
  font-family: 'Roboto';<br>
  font-style: normal;<br>
  font-weight: 400;<br>
  src: local('Roboto'), local('Roboto-Regular'), url(https://fonts.gstatic.com/s/roboto/v18/KFOmCnqEu92Fr1Mu4mxKKTU1Kg.woff2) format('woff2');<br>
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;<br>
}

So werden schon mal an zwei Datenquellen informationen gesendet, bei dem man nicht sagen, kann, was mit den Daten passiert:

  • fonts.googleapis.com
  • fonts.gstatic.com

Natürlich könnte man nun alle Schriftarten hier einzeln herunterladen und einzeln wieder neu einbinden. Bei 2-3 Webfonts mit je 3-4 Schnitten hat man so aber schnell 10 Schriften zusammen und man ist doch einige Minuten beschäftigt. Einen Arbeitshelfer hat hier Mario Ranftl geschrieben, mit dem man die Schriftarten auch noch schön gepackt bekommt und die CSS-Pfade auch schon direkt vorbereitet hat:

  1. Schriftart auswählen / suchen
  2. Zeichensatz auswählen (Select charsets)
  3. Schriftstil auswählen
  4. CSS-Code kopieren und in die eigenen CSS-Styles einfügen
  5. Dateien herunterladen und am gewünschten Ordner des Webservers bereitstellen.

Der ganze Prozess dauert so kaum 10 Minuten für alle Schriftarten auf einer Seite. Netter Nebeneffekt es müssen zwei DNS-Auflösungen weniger gemacht werden (min. 2 ms Ladezeit) und es wird eine CSS-Datei weniger eingebunden, was den gesamten Ladeprozess verkürzt (nominal min. 10 ms, da die Schriftarten i.d.R. auf dem kritischen Pfad des CSS liegen).

Veröffentlicht am

Änderungen des Preismodells von WPML

Im Monat Mai (genauer Termin noch nicht bekannt) wird der Verkauf von Accounts auf Lebenszeit („Lifetime Accounts“) von WPML gestoppt. Alle Besitzer eines Accounts auf Lebenszeit erhalten weiterhin den vollen Support und die Updates für eine unbegrenzte Anzahl an Webseiten und wer vor dem Verkaufsstop noch einen Account erwirbt, wird diesen auch weiterhin wie gewohnt Nutzen können.

Änderung des Preismodells

Zusätzlich zur Abschaffung der Möglichkeit zum Erwerb von Accounts auf Lebenszeit wird das übrige Preismodell zur gleichen Zeit umgestellt.So wird der „Starter“-Account WPML core enthalten und Updates und Support für eine Webseite. „Standard“ beinhaltet Unterstützung für 3 Seiten und alle WPML Komponenten. Das große Paket „Agency“ wird dann wie bisher der Account auf Lebenszeit eine unbegrenzte Anzahl an Seiten unterstützen. Alle Pakete werden jährlich Abgerechnet, wobei die Erweiterung um jeweils 1 Jahr zu einem vergünstigten Preis stattfinden wird. Besitzer des derzeitigen „Multilingual CMS“ Pakets können entweder auf „Standard“ oder „Agency“ wechseln, während Besitzer des Pakets „Blog“ auf Starter bleiben oder einmalig für ein Jahr ohne Mehrkosten auf „Standard“ Upgraden. Ab dem zweiten Jahr werden hier allerdings die üblichen Kosten fällig.

Neues Feature: Advanced Translation Editor

Im letzten Jahr wurde intensiv an einem neuen Editor zum editieren der Übersetzungen gearbeitet. Dieser beinhaltet die meisten Funktionen von modernen Übersetzungsprogrammen, unter anderem eine sehr genaue Segmentierung, ein Speicher für eigene Übersetzungen, eine eingebauten Rechtschreibprüfung und eine Funktion zur maschinellen Übersetzung von Abschnitten.Besitzer des „Standard“ oder des „Agency“ Pakets können den neuen Editor schon bald ausprobieren.

Umstellung auf Echtzeit-Support

Anstelle der üblichen Wartezeit bei Tickets soll es nun einen Echtzeit Kontakt mit dem Bearbeiter eines Tickets geben. So können schnell benötigte Informationen ausgetauscht werden ohne das lange Warten auf eine Antwort des Supports. Diese Änderung soll das bearbeiten von Tickets einfacher und flexibler gestalten und Wartezeiten drastisch verkürzen

Ein Blick in die Zukunft von WPML

Auch ein Blick auf die Zukunft wurde geworfen. So soll WPML bald eine Gutenberg Integration haben, eine bessere Erkennung der Wörteranzahl vor allem in „Page Buildern“ wie etwa WPBakery (früher Visual Composer) und eine Möglichkeit lokalisierte Bilder pro Sprache hochzuladen. Natürlich wird weiterhin an Verbesserungen der Sicherheit und Stabilität von WPML gearbeitet.Weitere Informationen und die Gründer der Umstellung finden sie im offiziellen Blogpost auf WPML.org.

Veröffentlicht am

7 Tipps zur erfolgreichen Multilingualen Seite mit WPML

Die Wahl eines Themes ist der erste Schritt zu einer erfolgreichen Webseite. Natürlich ist dieser Prozess ein sehr wichtiger Schritt, die Wahl eines Themes bestimmt maßgeblich wie die eigene Webseite von anderen wahrgenommen wird.Aus diesem Grund hat das WPML Team hunderte von Themes getestet und eine Datenbank mit den Ergebnissen auf ihrer Webseite veröffentlicht.

Das eigene Theme übersetzen

Bevor man das Theme mit Beiträgen füllt sollte sichergestellt werden, das alles korrekt übersetzt worden ist, um die beste Benutzererfahrung zu gewährleisten.Auf der Website von WPML sind 3 Möglichkeiten erklärt wie dies am besten zu bewerkstelligen ist. Weitere Informationen findet man hier.

Eigene Beiträge selbst übersetzen

Wer in der glücklichen Position ist mehrere Sprachen zu beherrschen, kann mit WPML sehr einfach die eigenen Beiträge übersetzen. Das Team rund um WPML hat einen Guide zur manuellen Übersetzung veröffentlich, die WPML Neulingen eine großartige Übersicht zu allen Funktionen bietet, die zur Erstellung einer multilingualen Webseite nötig sind.Diesen Guide und vieles mehr befindet sich auf der offiziellen Webseite.

WooCommerce Seiten übersetzen

Eine WooCommerce Seite zu übersetzen bedarf mehr als nur der simplen Übersetzung der Produktinformationen. WPML WooCommerce Multilingual ist eine Erweiterung zu WPML, die unter anderem lokalisierte Bestellprozesse, von der Sprache abhängige URLs, Lieferzonen und verschiedene Bezahloptionen, je nach Land, bietet.Der Hersteller dieser Erweiterung hat auf seiner Webseite ein Tutorial veröffentlich, was diesen komplizierten Prozess vereinfacht. Zu finden ist dieses Tutorial hier.

Page Builder und WPML

Page Builder sind eine exzellente Möglichkeit, schnell und effizient Beiträge zu gestalten. Sie erfordern nahezu keine Programmierkenntnisse und das beste ist, WPML bietet eine Unterstützung für die populärsten Page Builder.Eine Hilfe zur Erstellung von Webseiten mit Page Buildern befindet sich auf der WPML Webseite.

Benutzerdefinierte Taxonomien übersetzen

Eine gute Webseite hat neben den üblichen WordPress Kategorien und Tags noch eigene, benutzerdefinierte Taxonomien. Diese  zu übersetzen ist ebenfalls sehr leicht, wie dieses Tutorial zeigt.

SEO und mehrsprachige Webseiten

Selbst mit den besten Beiträgen und der schönsten Webseiten erreicht man niemanden, wenn es nicht zu finden ist. Search Engine Optimization ist schon seit Jahren ein großer Begriff im Bereich von WordPress und auch WPML bietet eine Integration für einige Plugins die einem damit helfen. Eines davon ist Yoast SEO, welches in Kombination genutzt werden kann, um mehrsprachige Beiträge bessere zu optimieren.Eine Hilfe zur Integration und Nutzung von Yoast SEO und WPML findet sich hier.

Veröffentlicht am

Neues zu Contractors in WPML

Erst vor kurzem erschienen, ist das neue Contractor System von WPML bereits ein großer Erfolg. Über 80 Entwickler wurden schon freigeschaltet und erste positive Rückmeldungen über die erfolgreiche Vermittlung von Aufträgen sind ebenfalls eingetroffen!Ein kleiner Wermutstropfen bleibt allerdings: Durch die große Anfrage und den sorgfältigen Prüfungsprozess kommt es derzeit zu einer Verzögerung von bis zu 2 Wochen, bis eine Bewerbung als WPML Contractor bearbeitet wurde. Das WPML Team bittet in diesem Fall um Verständnis und hofft, das sie sehr bald den ersten Ansturm bewältigt haben.In einem Blogpost auf WPML.org wurden einige Informationen, sowohl für Entwickler als auch für Kunden, zusammengefasst.

Revision der Admin Benachrichtigungen

Das WPML Team hat in einem Blogpost die Frage gestellt, wie die Benutzer das Admin Benachrichtigungs Verhalten von WPML finden. Dies ist ein System von WordPress, welches es Entwicklern erlaubt, wichtige Nachrichten direkt beim Login im Dashboard anzuzeigen.Das Ergebnis ist überraschend: Viele Benutzer finden die Benachrichtigungen von WPML sinnvoll, würden es aber vorziehen, wenn es nur absolut notwendige Nachrichten anzeigt. Viele Nutzer denken, das zu oft unnütze Informationen an sie weitergelietet werden, die sie zu diesem Zeitpunkt nicht benötigen. Über 55% aller Umfrageteilnehmer gaben sogar an, das sie einige Nachrichten ungelesen oder unbearbeitet einfach wegklicken, damit sie nicht das Admin Menü unübersichtlich zurücklassen.

Veröffentlicht am

Speicherfresser per Konsole und dem Befehl du feststellen

Irgend ein Script „ballert“ den Webspace oder den Server voll? Per FTP-Programm bekommt man nu nicht die Speicherauslastung je Verzeichnis raus, daher hier die Lösung per Konsole:

du -h --max-depth=1 .

Dabei habe ich mich vorher per SSH mit dem Server und dem entsprechendem Webspace verbunden und erhalte folgend eine Auslastund der Unterverzeichnisse und kann den Übeltäter schnell identifizieren.

Aber langsam: Was ist dieser Befehl du überhaupt? Der Befehl du (steht für „Disk Usage“) ist ein Standard-Befehl aller Unix/Linux-Systeme, er wird gebraucht um Informationen darüber zu erhalten, wie viel Festplattenplatz durch Dateien und Verzeichnisse genutzt wird.
Der Befehl du hat dabei viele mögliche Parameter, für diesen speziellen Fall nutze ich:

-h für eine schicke Ausgabe der Speicherverbräuche (human readable) in KB, MB und GB.

--max-depth=1 für eine Ausgabe aller Unterordner, die maximal einen Ordner unter dem aktuellen liegen.

.Der Punkt gibt nur noch den aktuellen Ordner an, an dem ich aktuell eh schon bin. Alternativ kann hier auch der vollqualifizierte Ordnerpfad angegeben werden, zu dem ich weitere Informationen haben möchte, bspw.: var/www/vhosts/coding-pioneers.com

Ich hoffe das hilft Dir nun ein wenig weiter und du verstehst den Linux/Unix-Befehl du für den hier genannten Fall!

Veröffentlicht am

Erstellen einer Accelerated Mobile Pages (AMP) HTML-Seite

1. Was ist AMP?

AMP steht für „Accelerated Mobile Pages“ und ist ein Open-Source-Projekt, das von einigen Unternehmen ins Leben gerufen wurde. Das Ziel ist, Web-Inhalte, vor allem im Hinblick auf die mobile Entwicklung, möglichst schnell zu laden. AMP ist eine Möglichkeit Webseiten schneller zu laden und für mobile Geräte weiter zu optimieren. Vor allem für Blogbeiträge, Newsartikel, die oft mobil abgerufen werden, bietet sich diese Technik an. AMP besteht aus drei wesentlichen Teilen:

  • AMP HTML
  • AMP JS
  • Google AMP Cache

AMP HTML ist größtenteils reguläres HTML, das um ein paar spezifische Ausdrücke erweitert wurde. AMP JS ist eine JavaScript-Bibliothek, über die alle Lösungen zum schnelleren Laden einer Webseite implementiert sind. Auf eine eigene JavaScript-Datei muss allerdings verzichtet werden. Google wiederum bietet einen Cache, der für alle zugänglich ist und in den alle AMPs geladen werden. Dadurch sind die Seiten für andere Nutzer schneller verfügbar. Ein weiterer Vorteil von AMP besteht darin, dass diese von Google in den SERPs (Search Engine Result Pages) weiter oben stehen, da es ein Rankingfaktor ist.

2. Vorbereitung

Um seine Seite mit Hilfe von AMP zu optimieren, müssen zunächst ein paar Änderungen im Head der Seite vorgenommen werden. Im Folgenden ist der Grundaufbau einer AMP-Datei zu sehen:

<html amp lang="de"> 
  <head>
    <meta charset="utf-8">
      <title>Hello, AMPs</title>
      <link rel="canonical" href="http://example.ampproject.org/article-metadata.html" />
      <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

      <script type="application/ld+json">
        {
          "@context": "http://schema.org",
          "@type": "NewsArticle",
          "headline": "Open-source framework for publishing content",

          "datePublished": "2015-10-07T12:02:41Z",
          "image": [
            "logo.jpg"
          ]
        }
      </script>

      <style amp-boilerplate>
        body {
          -webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;
          -moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;
          -ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;
          animation:-amp-start 8s steps(1,end) 0s 1 normal both
        }

        @-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
        @-moz-keyframe -amp-start{from{visibility:hidden}to{visibility:visible}}
        @-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}

        @-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}

        @keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
      </style>
      <noscript>
        <style amp-boilerplate>
          body{
            -webkit-animation:none;
            -moz-animation:none;
            -ms-animation:none;
            animation:none
          }
        </style>
      </noscript>

      <script async src="https://cdn.ampproject.org/v0.js"></script>
  </head>

  <body>
    <h1>Dies ist bereits eine AMP Seite!</h1>
  </body>

</html>

Im Head-Bereich benötigte Angaben

  • Zunächst muss das Dokument mit der Doctype-Description beginnen: <!doctype html>
  • Das HTML-Tag muss wie folgt ergänzt werden: <html ⚡ > oder alternativ <html amp>, um dem Browser mitzuteilen, dass es sich hierbei um eine AMP-HTML Seite handelt.
  • Die <head> und <body> -Tags dürfen nicht weggelassen werden.
  • Im Head muss mit diesem Tag
    <link rel="canonical" href="$EINE_URL" />
    der Link zu der normalen HTML Version der Seite angegeben sein. Ist diese nicht vorhanden, so muss die HTML AMP Seite auf sich selbst verlinken.
  • Das erste Element des <head>-Tags muss die Zeichenkodierung enthalten: 
    <meta charset="utf-8"><meta name="viewport" content="width=device-width,minimum-scale=1">
    muss vorhanden sein.
  • Für die AMP JS-Bibliothek muss das Tag 
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    als letztes Element des <head>-Tags enthalten sein. Das „async“ sorgt dafür, dass es asynchron geladen werden darf und so das onload-Event nicht verzögert
  • Ebenfalls darf auf das <style amp-boilerplate> Tag, wie oben angegeben, nicht verzichtet werden.

Alle übrigen Angaben, wie zum Beispiel die Schema.org Definition, sind für eine AMP HTML Seite optional. Um in anderen Diensten (z.B. Googles News) angezeigt zu werden, können diese benötigt werden.

Verbotene/Ersetzte Tags

Aus Performancegründen wurden einige HTML-Tags bei AMP HTML ersetzt und einige werden nicht unterstützt.


Nicht unterstützte Tags:

  • base
  • frame
  • frameset
  • object
  • param
  • applet
  • embed
  • form (Zukünftiger Support wurde bereits angekündigt)
  • input Elemente, textarea, select, option etc. (Davon ausgenommen ist das <button>-Tag)


Eingeschränkte Tags:

  • script (Nur erlaubt, um AMP Komponenten zu laden oder bei type="application/ld+json")
  • style (Ein zusätzliches Style Tag mit dem Attribut amp-custom ist im Head erlaubt)
  • link (rel-Attribute, die auf microformats.org registriert sind, sind erlaubt. Außerdem gibt es Ausnahmen, um benutzerdefinierte Fonts einzuladen)
  • meta (http-equiv-Attribut ist verboten)
  • svg
  • a (Der Wert des href Attributs darf nicht mit javascript: beginnen)


Ersetzte Tags:

  • img ⇒ amp-img
  • video ⇒ amp-video
  • audio ⇒ amp-audio
  • iframe ⇒ amp-iframe

Des Weiteren dürfen das style-Attribut, xml-Attribute sowie Attribute, die mit on beginnen (onclick, onmouseover etc.) nicht benutzt werden. Davon ausgenommen ist das on Attribut ohne Suffix.

3. AMP Elemente

Auf so gut wie jeder Webseite gibt es Bilder. Somit dürfte das wahrscheinlich wichtigste, weil meistbenutzte, AMP Element das <amp-img> Element sein. Anstatt das HTML eigene <img>-Tag zu benutzen, muss stattdessen die AMP Version dieses Tags benutzt werden.
Will man also ein Bild in seine Webseite einbauen, sähe das mit AMP zum Beispiel wie folgt aus:

<amp-img 
    src="pfad_zum_bild.jpg" 
    width=300 
    height=150 
    layout="responsive" >
</amp-img>

Das Attribut layout wird unter dem Punkt „Responsives Design“ erläutert.

Diese häufig benutzten AMP Elemente sind von Haus aus in der Standard-AMP-Bibliothek eingebaut. Erweiterte Komponenten müssen im Head des Dokuments eingeladen werden. Dazu später mehr.

Häufig benutzte Attribute

Um seine Seite AMP konform zu gestalten, sollten einem die Attribute layout, width, height, media, placeholder und fallback geläufig sein. Diese sind wichtig, um das Layout eines Elements zu definieren und diesem seinen Platz zu reservieren bevor andere Ressourcen wie JavaScript geladen wurden. layout Dieses Attribut bestimmt, wie sich das Element im Layout des Dokuments verhält. Die verschiedenen Werte für das Attribut werden unter dem Punkt „Responsives Design“ näher erläutert. Welche Werte das Attribut bei einem Element annehmen darf, steht in der Dokumentation des jeweiligen Elements.
width und height Je nachdem welchen Wert das Attribut layout eines Elements hat, müssen diese Werte gesetzt sein. Die Attribute müssen einen Integer Pixel Wert haben.
media Der Wert dieses Attributs ist ein media query. Immer wenn sich die Fenstergröße des Browser ändert, werden die Queries neu evaluiert und dementsprechend das Element angezeigt oder nicht.
placeholder Dieses Attribut kann nicht nur AMP Elementen, sondern jedem HTML Element zugewiesen werden. Ein Element, das dieses Attribut enthält, ist als Platzhalter seines Elternelements markiert. Es wird angezeigt, so lange die Ressourcen des Elternelements noch nicht geladen oder initialisiert werden konnten.
fallback Wie das placeholder Attribut kann auch dieses Attribut jedem HTML Element zugewiesen werden. Es dient dazu, dem Benutzer der Webseite mitzuteilen, wenn ein bestimmtes Element nicht angezeigt wird, weil es nicht den seinen Browser unterstützt wird.

Weitere Informationen zu den Attributen und Layout sind unter der AMP HTML Layout System Dokumentation zu finden.

Erweiterte Elemente

Erweiterte Elemente sind nicht im Standardumfang der AMP Bibliothek enthalten und müssen extra im Head eingeladen werden. Dabei handelt es sich um Elemente, die nicht so häufig gebraucht werden, wie zum Beispiel Bilder. Sie werden innerhalb eines <script>-Tags geladen:

<script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script>

Wichtig ist, dass die async– und custom-element-Attribute nicht weggelassen werden dürfen.
Eine Liste aller momentan zur Verfügung stehenden erweiterten Elemente ist hier zu finden. Zu jedem dieser Elemente gibt es eine Seite, auf der diese ausführlich beschrieben werden. Zu Beginn der Seite findet man eine kleine Übersicht, in der man unter anderem den zum Einladen nötigen <script>-Tag und einen Link zu einem Beispiel findet.

Unter ampbyexample.com sind alle AMP Elemente mit Beispielen aufgelistet. Diese Seite eignet sich gut, um einen Überblick über die Elemente und ihre Implementierung im eigenen Code zu bekommen.

4. AMP und CSS

Bei der Benutzung von CSS gibt es ein paar Einschränkungen, über die man Bescheid wissen sollte. Zunächst muss auf externe Stylesheets verzichtet werden. Ebenso muss man auf Inline Style Attribute verzichten und einige Styles sind aus Performancegründen tabu.

Die Styleangaben müssen im Head des Dokuments angelegt werden. Dabei sollte man darauf achten, dass dieser Bereich nicht zu groß wird: maximal 50000 Bytes sind erlaubt, um AMP konform zu bleiben. Muss es doch etwas mehr sein, so kann allerdings auf CSS-Präprozessoren, wie zum Beispiel Sass oder Less, zurückgegriffen werden.

Verbotene Styles

Inline Style Attribute Alle Styles müssen im <head> der Seite innerhalb eines <style amp-custom> Tags stehen.
! important Da dieses Element durch das AMP CSS selbst benutzt wird und wichtig für die Größenänderungen der Elemente ist, darf es nicht verwendet werden.
<link rel=“stylesheet“> Diese Formulierung ist nur zum Einbinden von benutzerdefinierten Fonts zulässig. Externe Stylesheets sind nicht erlaubt.
* (universeller Selektor) Der universelle Selektor darf nicht benutzt werden, da sich das negativ auf die Performance der Seite auswirken kann. Außerdem könnten dadurch andere Restriktionen umgangen werden.
:not() Dieses Element könnte dazu benutzt werden, den universellen Selektor zu simulieren.
Pseudoselektoren, Pseudoklassen, Pseudoelemente Diese sind nur in Verbindung mit Selektoren, die Tag-Namen enthalten erlaubt. Davon ausgeschlossen sind Tag-Namen, die mit amp- beginnen. Beispiele: a:hover, div:last-of-type sind erlaubt, amp-img:hover ist nicht zulässig.
-amp- Klassen und i-amp Tag-Namen Benutzerdefinierte Klassennamen dürfen nicht mit -amp- beginnen, da diese der AMP-Runtime vorbehalten sind. Im Style Bereich sollte deswegen darauf verzichtet werden, mit Selektoren auf -amp- Klassen und i-amp Tags zuzugreifen.
behavior, -moz-binding Diese Eigenschaften sind aus Sicherheitsgründen nicht erlaubt.
filter Filter dürfen aus Performancegründen nicht verwendet werden.

Transitions und Animations

Transitionen und Animationen sind nicht grundsätzlich verboten. Solche, die bei den üblichen Browsern durch die GPU unterstütz werden, sind generell zulässig. Momentan sind opacity, transform samt -vendor-Prefixes erlaubt. Bei der overflow Eigenschaft muss darauf geachtet werden, dass diese nicht als „auto“ oder „scroll“ gestylt werden darf. Außerdem darf kein benutzerdefiniertes Element eine Scrollbar aufweisen.

Benutzerdefinierte Fonts

Es gibt zwei Möglichkeiten, bei AMP Seiten benutzerdefinierte Fonts einzubinden. Zum einen ist es möglich, in einem link-Tag auf einen von AMP „weißgelisteten“ Anbieter zu verlinken. Zu diesen Anbietern zählt momentan nur: https://fonts.google.com/.
Zum anderen können Fonts auch über @font-face eingebunden werden.

5. Responsives Design

Zur Unterstützung des responsiven Designs einer Seite gibt es bei AMP ein paar neue Attribute, die den AMP Elementen zugewiesen werden können. Das wichtigste unter ihnen ist das layout Attribut, das mit den Attributen width und height zusammenarbeitet.

Folgende Werte werden durch AMP für das Layout Attribut unterstützt:

nodisplay Keine Angabe zu Höhe/Breite nötig.
Dieses Layout kann jedem AMP Element zugewiesen werden. Es hat den selben Effekt wie display: none
fixed Angaben zur Höhe/Breite nötig.
Die Elemente haben eine festgesetzte Breite und Höhe und unterstützen kein responsives Design. Ausnahmen sind amp-pixel und amp-audio Elemente.
responsive Angaben zur Höhe/Breite nötig.
Das Element wird auf die Breite seines Containers vergrößert oder verkleinert und die Höhe entsprechend angeglichen. Mit Hilfe der max-width Eigenschaft kann die Größe des Elements angepasst werden. Dieses Layout funktioniert mit allen AMP Elementen.
fixed-height Angabe zur Höhe nötig.
Das Element nimmt den zur Verfügung stehenden Platz ein, ohne dabei seine Höhe zu verändern. Das width Attribut sollte nicht angegeben werden oder auf auto gesetzt sein.
fill Keine Angabe zu Höhe/Breite nötig.
Das Element übernimmt die Höhe und Breite des Eltern-Elements.
container Keine Angabe zu Höhe/Breite nötig.
Das Element übernimmt seine Größe von seinen Kind-Elementen, ähnlich einem div. Es verhält sich wie ein Container.

Wenn möglich, sollte das responsive Layout verwendet werden, da dieses der Idee des responsiven Designs entspricht.
Ist das Layout Attribut nicht vorhanden, so wird dem Element abhängig von den gesetzten Werten automatisch ein Layout zugewiesen.

Um seine Seite möglichst responsiv zu gestalten, ist es möglich, allen AMP Elementen das Attribut media zuzuweisen. Dieses funktioniert genau wie CSS Media Queries (die ebenfalls verwendet werden können).


<b><amp-img</b><br>
    media="(min-width: 650px)"<br>
    src="breit.jpg"<br>
    width=466<br>
    height=355<br>
    layout="responsive" <b>></b><br>
<b></amp-img></b>



Je nachdem wir breit der Bildschirm ist, wird eines der beiden Bilder ausgegeben.


<b><amp-img</b><br>
    media="(max-width: 649px)"<br>
    src="schmal.jpg"<br>
    width=527<br>
    height=193<br>
    layout="responsive" <b>></b><br>
<b></amp-img></b>

Des Weiteren werden durch AMP die Attribute srcset und sizes zur Verfügung gestellt. Ersteres wurde bereits bei regulären HTML Seiten benutzt und hat den gleichen Zweck wie das Attribut media. Es stellt dem Browser je nach Bildschirmgröße andere Bilder zur Verfügung.


<b><amp-img</b><br>
    src="breit.jpg"<br>
    srcset="breit.jpg" 640w,<br>
           "schmal.jpg" 320w<br>
    sizes="(min-width: 650px) 50vw, 100vw" <b>></b><br>
<b></amp-img></b>

Die Zahl vor dem w teilt dem Browser mit, wie breit das jeweilige Bild ist. Mit Hilfe des sizes Attributs kann festgelegt werden, in welcher Größe das Bild angezeigt werden soll. Im obigen Beispiel nähme das Bild bei einer Breite des Viewports von 650px und mehr, 50% der Breite des Viewports ein. Hätte der Viewport beispielsweise eine Breite von 600px, so würde die Breite des Bildes auf 300px gesetzt. Dementsprechend würde das 320px breite Bild geladen.

Weitere Informationen, wie man das responsive Design seiner Seite mit AMP verbessern kann, gibt es auf:
www.ampproject.org.

6. Validierung

Ob die nun erstellte Seite AMP-konform ist, lässt sich schnell feststellen. Zusammen mit der AMP JS-Bibliothek wird ein AMP Validator mitgeliefert.
Um diesen zu benutzen, muss #development=1 an die URL der Seite angehängt werden. Nach der Aktualisierung
der Seite werden in der Entwickler-Konsole mögliche Validierungsfehler angezeigt.

Alternativ kann das Web-Interface unter validator.ampproject.org benutzt werden. Dort kann man einfach die URL der Seite angeben und auf VALIDATE klicken. Der Code der Seite wird daraufhin in einem interaktiven Editor angezeigt. Falls Fehler vorhanden sind, werden sie darunter angezeigt und im Code markiert.

Als dritte Möglichkeit wird eine Browsererweiterung (bis jetzt nur für Chrome und Opera verfügbar) angeboten, die jede besuchte AMP Seite automatisch prüft und mit Hilfe eines Icons anzeigt, ob die Seite AMP-konform ist. Praktisch ist außerdem, dass es ein spezielles Icon gibt, um zu signalisieren, dass die besuchte Seite zwar keine AMP Seite ist, aber eine AMP Version dieser Seite vorhanden ist.

Damit die erstellte AMP in den Google Cache geladen wird, muss diese validiert werden. Zur Unterstützung bei der Fehlerbehebung haben die AMP Entwickler einen Guide zu den verschiedenen AMP Validierungsfehlern zur Verfügung gestellt. Dieser kann hier gefunden werden.

Nach der erfolgreichen Validierung des Codes steht der Veröffentlichung der Seite nun nichts mehr im Wege. Ist noch eine Version der Seite in regulärem HTML vorhanden, so muss im Head dieser Seite auf die AMP Version verlinkt werden und umgekehrt. Ist eine solche nicht vorhanden, so muss der Link im Head der AMP Seite auf diese selbst verweisen:

<!-- Reguläre Seite: --> <link rel="amphtml" href="https://www.beispiel.com/url/zu/amp/dokument.html"> 
<-- AMP Seite: --> <link rel="canonical" href="https://www.beispiel.com/url/zu/regulaerem/dokument.html">

Weiterführende Informationen

Unter folgenden Links sind weitere Informationen zu AMP zu finden:

Veröffentlicht am

Doppelt hält Besser (IPv4/IPv6): Dual Stack mit neuem Server

Seit nun fast 5 Jahren testen wir unsere Webseiten auch mit IPv6, heute ist es dann nun auch soweit, dass unsere Webseite https://www.coding-pioneers.com über IPv6 endlich verfügbar ist. Ebenso können alle unsere Hosting-Kunden ebenfalls ihre Webseite im Dual Stack-Betrieb mit IPv4 und IPv6 auf unseren Servern betreiben.

Doch der Reihe nach: Was ist eigentlich dieses IPv6 und was macht das im Web?

Mit der Protokollerneuerung von IPv6 ändern sich grundsätzliche Abläufe der Netzwerkkommunikation. Die Erweiterung des Adressraums von 32 auf 128 Bit wirkt dabei zum einen der Verknappung der IPv4-Adressen entgegen. Zum anderen ermöglicht der neue Standard, alle Endgeräte in einem Netzwerk eindeutig zu adressieren. Anders als IPv4 setzt die Version 6 des Internet-Protokolls den Grundgedanken des Ende-zu-Ende-Prinzips konsequent um.


IPv6, noch Fragen?

IPv6 steht für „Internet Protocol Version 6“ und ist ein Verfahren zur Übertragung von Datenpaketen in paketvermittelnden Rechnernetzen, insbesondere dem Internet. Zusammen mit vielen weiteren Netzwerkprotokollen bildet IPv6 die Grundlage für die Kommunikation im Internet der Zukunft. Zentrale Funktionen von IPv6 sind die Adressierung von Netzwerkelementen über die IPv6-Adressen sowie die Paketweiterleitung zwischen Teilnetzen (Routing). Dazu setzt IPv6 an der Vermittlungsschicht (dem Layer 3 des OSI-Schichtenmodells) an.

Die Vergabe von IP-Adressen erfolgt über sogenannte RIRs (Regional Internet Registries), die von der IANA (Internet Assigned Numbers Authority) jeweils eigene IP-Adressbereiche zugeteilt bekommen. Die zuständige RIR für Europa, den Nahen Osten und Zentralasien ist das RIPE NCC (Réseaux IP Européens Network Coordination Centre).

IPv6 vs. IPv4

Das neue Adressformat der 6. Protokoll-Version unterscheidet sich auf den ersten Blick deutlich von dem des Vorgängers IPv4.

  • IPv4-Adresse: 62.108.36.46
  • IPv6-Adresse: 2a00:0f70:abcd:0102:0000:0000:245:0002

Während bei IPv4 32 Bit-Adressen zum Einsatz kommen, setzt der Nachfolger IPv6 auf 128 Bit-Adressen, die aufgrund der besseren Lesbarkeit hexadezimal dargestellt werden.

So wird das zentrale Anliegen des neuen IP-Standards umgesetzt: Mit 128 Bit lassen sich deutlich mehr einzigartige IP-Adressen generieren als mit 32 Bit.

  • Adressbereich von IPv4: 32 Bit = 232 Adressen ≈ 4,3 Milliarden Adressen
  • Adressbereich von IPv6: 128 Bit = 2128 Adressen ≈ 340 Sextillionen Adressen

Wer sich nun darunter kaum etwas vorstellen kann: Der Adressbereich von IPv4 mit ca. 4,3 Milliarden IPs reicht nicht einmal, um jeden Menschen auf der Welt mit einer einzigartigen Adresse zu versorgen, während sich mit dem 128 Bit-System theoretisch jedem Sandkorn der Erde gleich mehrere IP-Adressen zuweisen lassen würden. Die Einführung von IPv6 ist somit als Investition in die Zukunft zu betrachten. Durch das Internet der Dinge (engl. „Internet of Things“, oder kurz: IoT) wird die Zahl der Geräte, die eindeutig identifizierbar mit dem Internet verbunden werden müssen, in den nächsten Jahren deutlich zunehmen.

Aufbau einer IPv6-Adresse

Die 128 Bit einer IPv6-Adresse sind in acht Blöcke à 16 Bit geteilt. Durch hexadezimale Schreibweise lässt sich ein 16-Bit-Block mit vier Ziffern (0-9) bzw. Buchstaben (A-F) notieren. Als Trennzeichen dient der Doppelpunkt:

  • 2a00:0f70:abcd:0102:0000:0000:245:0002

Um eine IPv6-Adresse lesbarer zu gestalten, gibt es Verkürzungen: Führende Nullen innerhalb eines Hexadezimalblocks dürfen weggelassen werden (dezimal zu vergleichen mit 0100 ist 100). Besteht ein Block nur aus Nullen, muss die letzte Null erhalten bleiben:

  • 2a00:0f70:abcd:0102:0000:0000:245:0002
  • 2a00:f70:abcd:0102:0:0:245:0002

Einmal je IPv6-Adresse dürfen aufeinanderfolgende Null-Blöcke gestrichen werden:

  • 2a00:f70:abcd:0102:0:0:245:0002
  • 2a00:f70:abcd:0102::245:0002


Die aufeinanderfolgenden Doppelpunkte (im Beispiel oben nach dem 5. Block) zeigen diese Streichung an.

Praktisch stehen dem Internet weniger Adressen zur Verfügung, als das 128 Bit-Format vermuten lässt (ähnlich wie bei IPv4). Der Grund ist das Gestaltungsprinzip: Der neue Standard soll eine echte Ende-zu-Ende-Verbindung ermöglichen und die Übersetzung von privaten in öffentliche IP-Adressen auf Basis von NAT (Network Address Translation) überflüssig machen (wie es bei IPv4 noch der Fall ist). Grundsätzlich ließe sich auch mit IPv4 einen Ende-zu-Ende-Verbindung realisieren; da der IPv4-Adressraum jedoch zu klein ist, um jedes Gerät mit einer einzigartigen Adresse zu versorgen, wurde ein System mit getrennten Adressbereichen und der vermittelnden Komponente NAT entwickelt. Mit dem neuen Standard lässt sich jetzt jedes Endgerät, das an ein Netzwerk angeschlossen ist, über eine eigene IP logisch adressieren. IPv6-Adressen beinhalten daher zusätzlich zu dem Abschnitt zur Netzwerkadressierung (auch Netzadresse oder Routing-Präfix genannt) einen eindeutigen Interface-Identifier, der sich aus der MAC-Adresse der Netzwerkkarte des Endgeräts ergibt oder manuell erzeugt wird. Das Routing-Präfix als auch der Interface-Identifier umfassen dabei je 64 Bit einer IPv6-Adresse.

Aufbau: Routing-Präfix

Das Routing-Präfix einer IPv6-Adresse ist in der Regel in ein Netzwerkpräfix und ein Subnetzpräfix gegliedert. Dargestellt wird dies in der sogenannten CIDR-Notation (Classless Inter-Domain Routing). Dazu wird die Präfixlänge, sprich die Länge des Präfixes in Bits, mit einem Slash (/) an die Netzwerkadresse angehängt.

Die Notation 2a00:f70:abcd:0102::/64 beschreibt beispielsweise ein Subnetzwerk mit den Adressen 2a00:f70:abcd:0102:0000:0000:0000:0000:0000 bis 2a00:f70:abcd:0102:FFFF:FFFF:FFFF:FFFF:FFFF.

In der Regel bekommen Internetprovider (ISP) von der RIR /32er-Netze zugeteilt, die diese wiederum in Subnetze gliedern. An Endkunden werden entweder /48-Netze oder /56-Netze vergeben.

Das Paketformat von IPv6

Gegenüber IPv4 zeichnet sich IPv6 durch ein vereinfachtes Paketformat aus. Um die Verarbeitung der Pakete zu erleichtern, wurde für den Header eine Standardlänge von 40 Bytes (320 Bits) festgelegt. Optionale Informationen, die nur in Ausnahmefällen notwendig sind, werden in den Extension-Headers (EH) (dt.: Paketkopf-Erweiterungen) ausgelagert, die zwischen dem Header und der eigentlichen Nutzlast (Payload) eingebettet werden. So lassen sich Optionen einfügen, ohne dass der Header verändert werden muss.

Der IPv6-Paketkopf umfasst so nur noch acht Kopffelder, wohingehend bei IPv4 noch dreizehn Felder zum Einsatz kommen.

Jedes Feld im IPv6-Header enthält bestimmte Informationen, die für die Paketvermittlung über IP-Netze benötigt werden:

FeldErklärung
Version Beinhaltet die Version des IP-Protokolls, nach der das IP-Paket erstellt wurde (4 Bit)
Traffic Class Dient der Prioritätsvergabe (8 Bit)
Flow Label Pakete mit demselben Flow Label werden gleich behandelt (20 Bit)
Payload Length Gibt die Länge des Paketinhaltes (ohne Header) inklusive Erweiterung an (16 Bit)
Next Header Gibt das übergeordnete Transport-Layer-Protokoll an (8 Bit)
Hop Limit Gibt die maximale Anzahl an Zwischenschritten (Routern) an, die ein Paket passieren darf, bis es verfällt (8 Bit), und ersetzt damit das TTL aus IPv4
Source-IP-Address Beinhaltet die Absender-Adresse (128 Bit)
Destination-IP-Address Beinhaltet die Adresse des Empfängers (128 Bit)

Durch die Einführung der Extension-Header lassen sich optionale Informationen einfacher implementieren als bei IPv4. Auf dem Zustellungspfad eines Pakets mit IPv6-Extension-Header werden diese nicht vom Router geprüft noch verarbeitet, und so werden diese zumeist erst am Ziel ausgelesen. Somit ergibt sich eine deutliche Verbesserung der Routing-Performance von IPv6 zu IPv4, da diese optionalen Daten nicht mehr untersucht werden müssen.

Die Extension Header können unter anderem folgendes enthalten:

  • Knoten-zu-Knoten-Optionen
  • Zieloptionen
  • Routing-Optionen
  • Optionen zur Fragmentierung
  • Authentifikation und Verschlüsselung

Funktionalitäten von IPv6

Ein Großteil der Internetnutzer bringt IPv6 vor allem mit der Erweiterung des Adressraums in Verbindung. Der neue Standard bietet mehr: Weitere Funktionen, mit denen sich Einschränkungen von IPv4 überwinden lassen. Dazu gehört vor allem die konsequente Umsetzung des Ende-zu-Ende-Prinzips, die den Umweg über NAT überflüssig macht. Eine Implementierung von Sicherheitsprotokollen wie IPsec ist somit deutlich einfacher.

Darüber hinaus ermöglicht IPv6 die automatische Adresskonfiguration mit dem sog. Neighbor Discovery als auch die Vergabe mehrerer eindeutiger IPv6-Adressen pro Host mit unterschiedlichen Geltungsbereichen, um verschiedene Netzwerk-Topologien abzubilden. Neben der optimierten Adresszuordnung sorgen die Vereinfachung des Paketkopfes und die Auslagerung von optionalen Informationen für die Paketvermittlung in Extension-Headers für ein schnelleres Routing.

Mit QoS (Quality of Service) verfügt IPv6 über einen integrierten Mechanismus zur Sicherung der Dienstgüte, der für eine Priorisierung dringlicher Pakete sorgt und das Datenpaket-Handling effizienter gestaltet. Dazu wurden die Felder „Traffic Class“ und „Flow Label“ direkt auf die QoS-Methodik zugeschnitten.

Veröffentlicht am

Buzzwords des Online-Marketing für das Jahr 2016/2017

Wir waren auf der DMEXCO in Köln und haben uns Vorträge, Seminare und Diskussionsrunden für Euch angehört. Dabei sind uns folgende Buzzwords aufgefallen, die uns zweifelsfrei im nächsten Jahr begleiten werden: programmatic, mobil, performance-orientiert oder disrupted. Doch was steckt hinter den Wörtern?

Programmatic Advertising / performance-orientiert

Mittels Big-Data, der aktuellen Rechenpower und immer (künstlich-) intelligenteren Algorithmen lassen sich Vorhersagen treffen, was ein Nutzer wirklich sehen will. All diese Techniken stehen natürlich noch in den Anfängen, liefern aber auch dafür schon beeindruckend bessere Ergebnisse im bspw. Online-Advertising. Programmatic Advertising oder auch Programmatische Werbung ist im Online-Marketing ein Begriff, der das vollautomatische und individuelle Einkaufen/Schalten von Anzeigeflächen in Echtzeit Web bedeutet. Die ist über alle Plattformen (TV, Mobile-Devices, Wearables, Desktop) hinweg möglich. Ziel ist es, einem Nutzer die nur für ihn relevante Werbung anzuzeigen: One-to-One-Marketing. Dadurch gibt es im Marketing weniger Streuverluste und Werbung wird effizienter oder wie man häufig hören durfte: „performance-orientiert“ ausgeliefert. Im Optimalfall ist Marketing hiermit preiswerter, da die Conversion-Raten steigen und die Streuverluste geringer werden. Die Schattenseite der Technik: man braucht größere Datenmengen und ein wenig Intelligenz diese zu interpretieren.

Content-Marketing / Storytelling

Spätestens nach dem Google Such-Algorithmus-Update im Jahr 2015 gilt: „Content is king“! Notgedrungen haben viele Unternehmen Content regelrecht produziert. Dabei ist jedoch das Ziel aus dem Auge verloren worden: Der Besucher bzw. potentielle Kunde. Content-Marketing hat diesen Missstand aufgegriffen und entwickelt Content nicht für die Suchmaschine, sondern für den Nutzer. Ziel sind hier bestmögliche SEO-Ergebnisse aber der Kunde steht wieder im Mittelpunkt (was durch die Conversion-Rate gemessen wird).

Storytelling ist dabei im Content-Marketing ein essentieller Bestandteil der Kundenkommunkation. Storytelling lebt dabei von richtig guten Geschichten, um beim (potentiellen) Kunden auch eine entsprechende Emotion und Handlung hervorzurufen. Mit einer guten Geschichte kann auch die Marke oder das Produkt in den Hintergrund treten. Der Kunde bekommt weniger das Gefühl, dass ihm etwas verkauft wird, sondern dass er mit dem Produkt ein Problem lösen kann. Ein probates Mittel, mit dem Startups zur Zeit Millionenumsätze generieren.

Was für eine Rolle spielt dabei eigentlich VR/AR?

Die Technik hat sich seit dem Internet (zum Glück) entwickelt. Zunächst waren es einfache Textmeldungen, die zur Kommunikation genutzt wurden. Diese wurden durch eine Kommunikation mit Bildern abgelöst, aktuell sind Videos das probate Mittel der Wahl, um Geschichten zu erzählen. Mit den neuen Augmented Reality (AR) bzw. Virtual Reality (VR)-Möglichkeiten ist es möglich, eine noch tiefere Immersion zu erzielen. Der Nutzer betrachtet nicht nur die ihm präsentierte Geschichte, nein er kann Teil der Geschichte werden.

Mobile-first 2.0 – jetzt aber wirklich

In Deutschland entstehen über 50% des Web-Traffics über mobile Devices, auf Seiten wie Facebook sind es sogar 90% (20 von 22 Mio. Visits / Tag). Das Smarthphone ist dabei das Gerät, das wir kurz nach dem Aufwachen in der Hand haben und abends vor dem Schlafen zuletzt nutzen. Dabei werden Aufmerksamkeitsspannen kürzer und eigentlich hat keiner mehr Lust sich überflüssige Informationen anzusehen oder gar auf Webseiten zu warten, sich mit dem Navigationskonzept auf einer Seite zu beschäftigen oder Inhalte zu zoomen, um diese lesen zu können. Eine Seite muss nicht nur responsiv funktionieren, sondern sie muss auf die mobile Geräte möglichst zudesignt sein. Hier setzt Google mit seinem AMP an, Facebook empfiehlt doch gleich alles (oder zumindest vieles) über die Facebook-Page zu lösen und alle CMS-Hersteller versprechen, dass die von ihnen skizzierte Lösung das Mittel der Wahl ist. Kurzum: Der Dschungel wird größer und es wird essentiell hier einen Partner zur Seite zu haben, der diesen durchdringt, um hinterher im SEO-Ranking nicht komplett abzubauen und den Kunden inhaltlich dennoch zu erreichen.

Disrupted Business-Models

Alle, die nach den oben skizzierten Themen noch ruhig geblieben sind, denen sei nun gesagt: Your business model is (hyper) disruptive. Egal, ob die Hotelbranche durch Airbnb oder die Taxigesellschaft durch Uber kräftig aufgerüttelt wurde: So kann es – laut Ansicht einiger – in vielen Branchen weitergehen.

Aber mal ehrlich: Ein Jahrzehnte altes Geschäftsmodell, das darauf setzt, dass nicht jeder Endkunde CB-Funk zu Hause hat bzw. jeder Taxi-Fahrer ein Telefon mitführen kann, hat es kaum besser verdient. Wer seine Business-Strategie nicht regelmäßig auf Tauglichkeit prüft, muss früher oder später mit den Konsequenzen leben. Es gilt weiter dem Kunden einen USP durch die eigene Leistung zu geben. Für alle anderen gilt: