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

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!

Mehrsprachiges SEO mit WPML – 8 Tipps vom Entwickler

Während im Internet andauernd von SEO (Search Engine Optimization) gesprochen wird, sind sehr viele Mehrsprachige Seiten noch nicht dafür optimiert und Informationen dazu sind rar. Und die meisten Informationen, die man findet, sind sehr vage oder schwer verständlich.Aus diesem Grund hat der Entwickler von WPML 8 hilfreiche Tipps zusammengetragen, welche helfen sollen, Ihr Ranking mit den bekannten Suchmaschinen zu verbessern. Diese Hinweise wurden sehr praktisch gehalten, so das sie gleich verwendet werden können um die SEO Ihrer Seite zu verbessern oder zu optimieren.Gerade Tipp #2 finden wir sehr interessant für Blogger und Betreiber von Regionsübergreifenden Blogs sollten sich Tipp #7 sehr genau anschauen und keine Scheu davor haben, ihren Content zu duplizieren, wenn es Sinn ergibt. Selbst Google empfiehlt diese Arbeitsweise! 

#1 Betrachte deine Seite wie Google

Wenn Google deine Seite liest, sieht dies anders aus als wenn Du dir die Seite im Browser ansiehst. Dabei achtet Google nicht auf ein ausgefallenes Design, Schriftarten, Farben, Animationen oder Bilder. Gut strukturierter Inhalt ist das einzige, was zählt!

Nutze die Webentwickler-Erweiterung für Google Chrome (oder Firefox), deaktiviere CSS und Bilder (stelle nur die ALT-Tags dar). Immer noch zufrieden?

#2 Überprüfe deine Überschriften

Die Struktur der Überschriften auf deiner Webseite ist einer der wichtigeren Aspekte des On-Page-SEO (Quelle: The heading structure for your blog by yoast.com)

Installiere die Chrome-Erweiterung HeadingsMap. Diese zeigt dir die Hierarchie deiner Überschriften auf jeder beliebigen Seite. Überprüfe auch die übersetzten Seiten. Nach einer H1 sollte eine H2 kommen, dann eine H3 usw. Es dürfen hier keine Brüche geben, heißt es darf keine H1 genutzt werden und dann eine H3. Die Überschriften müssen immer hierarchisch absteigend sein. Ebenso darf nur eine H1 definiert werden.

#3 Sprachen sauber setzen

Google wird versuchen die Hauptsprache jeder einzelnen Seite zu erkennen. Alle Sprachauszeichnungen (wie lang-Attribute) werden hierfür ignoriert. Um hier Suchmaschinen wie Google nicht zu verwirren, sollte nur eine Sprache je Seite genutzt werden. Man sollte davon Absehen einen Text untereinander zu übersetzen.

Überprüfe, dass Du hiergegen nicht verstößt. Ein „Kontaktieren Sie uns/Contact us/Contáctenos“ ist genau so etwas, was vermieden werden muss.

#4 Stelle sicher, dass alle Sprachvarianten einfach zu finden sind

Vermeide eine automatische Weiterleitung auf Basis der Benutzersprache. Diese Weiterleitungen können verhindern, dass Nutzer (und Suchmaschinen) die Seite nicht mehr sehen können.

Nutze stattdessen Sprachschalter und stelle sicher, dass der Nutzer diese an üblichen Stellen (Header, Footer) findet und barrierefrei nutzen kann.

Nutzt du eine browserbasierte Sprachweiterleitung prüfe, ob Google alle Sprachvarianten deiner Seiten kennt. Dies kannst Du einfach herausfinden, indem Du bei Google eine Suche nach „site:“ also „site:coding-pioneers.com“ durchführst. Hierbei müssen dann Ergebnisse zu allen Sprachvarianten auftauchen.

Bitte einen Freund den Sprachschalter zu finden, dauert dies mehr als ein paar Sekunden, solltest Du die Position bzw. das Design überdenken. Icons (wie Flaggen, Weltkugeln) können hier helfen, um aus Text hervorzustechen.

#5 Ergänze ALT-Attribute und Captions für Bilder und denk an die Übersetzungen!

Akkurate Auszeichnungen können deine Webseite sichtbarer im Web machen! Der Unterschied zwischen Platz 1 und 2 in den SERPs können 90% Besucherunterschied ausmachen!

Bild-Beschreibungen (Captions) sind Texte, die sichtbar unter dem Bild stehen und zusätzliche Informationen liefern. Diese sog. Captions werden deutlich häufiger gelesen als der Hauptinhalt. Besucher neigen dazu eine Webseite nur noch zu Scannen. Untersuchungen haben gezeigt, dass Besucher besonders häufig an Bildern und den Beschreibungen dazu stoppen, um diese zu lesen. Somit ist es auch wichtig, genau diese Captions zu übersetzen.

Zusammengefasst: Prüfe ob deine Bilder ALT-Tags haben und in korrekter Sprache gesetzt sind. Hierzu hilft die Web Developer-Erweiterung (das Tool aus #1). Prüfe auch, ob die Captions Sinn ergeben und in der richtigen Sprache gepflegt sind!

Benutze hreflang-Attribute und regionale URLs richtig

Das hreflang-Attribut sagt Google was für alternative Übersetzungen es zu der entsprechenden Seite gibt. So kann Google zu jedem Ergebnis auch die korrekte Sprache bzw. lokale URL ausspielen.  Wenn dies korrekt genutzt wird kann es die Positionierung in der Suchmaschine dramatisch verbessern.

Das schöne ist, wenn man WPML nutzt, um seine mehrsprachige Seite zu bauen, werden die Attribute automatisch auf der Seite platziert!

Tipp: Ob du Tags mit hreflang-Fehlern hast, findest Du in der Google Search Console (ehemals Webmaster Tools).

WPML 4.0 Beta veröffentlicht!

Das Team rund um WPML hat die Veröffentlichung der Beta zu WPML 4.0 bekannt gegeben. Inhalt des großen Updates sind eine verbesserte Aufteilung zwischen Administration der Webseite und der Übersetzungen.

Zusätzlich werden allgemeine Verbesserungen für den  Übersetzungsvorgangs implementiert. Dazu wird ein neuer Medien- und Übersetzungseditor eingefügt, der auf dem Stand mit führender Übersetzungssoftware ist. Mehr Informationen und der Download der 4.0 Beta wurden vom WPML-Team in einem Ankündigungs-Beitrag veröffentlicht, zusammen mit einigen Beispielen.

Das Team von WPML sammelt derzeit noch Feedback zur Beta und strebt eine Veröffentlichung der Version 4.0 in etwa 2 Wochen an. Tests der Beta sollten nicht ohne ein Backup vorher vorgenommen werden, da noch einige Fehler bis zur Veröffentlichung ausgemerzt werden müssen.

Lösung für: [] operator not supported for strings in wp-content/plugins/revslider/includes/framework/base-admin.class.php:71

WordPress umgezogen und dann das „[] operator not supported for strings in /home/kinkusr/public_html/wp-content/plugins/revslider/includes/framework/base-admin.class.php:71“.

Die Lösung ist ganz einfach. Hier muss in Zeile 21 in wp_content/plugins/revslider/includes/framework/base-admin.class.php die folgende Zeile geändert werden:

private static $arrMetaBoxes =''; //option boxes that will be added to post

in

private static $arrMetaBoxes = array(); //option boxes that will be added to post

Alternativ hilft auch ein Upgrade des Revolution-Sliders. Hierfür muss ggf. ein Update des Themes oder des Revolution-Sliders ausgeführt werden:



Quelle:

[1] xtemos.com: Forum xtemos.com/forums/topic/revolution-slider-error-crashes-admin-cp/

Plesk auf Debian installieren

Plesk (eine Webserver-Distribution mit Konfigurationstool für Webhosting) auf Linux besser gesagt Debian installieren? nichts leichter als das: Laden Sie den Autoinstaller von der Webseite von der Website von Odin herunter:


wget http://autoinstall.plesk.com/plesk-installer

Fügen Sie Ausführungsberechtigungen hinzu:


chmod +x plesk-installer

Wechseln sie für die Installation am besten zum root-User

su root

Starten Sie den Autoinstaller mit dem folgenden Befehl:

./plesk-installer

Weitere Informationen finden Sie in der Plesk Installationsanleitung auf der Webseite von Odin:
http://download1.parallels.com/Plesk/PP12/12.0/Doc/de-DE/online/plesk-installation-upgrade-migration-guide/

*: vom Hersteller Parallels Inc. [ehemalige SWsoft Inc.]; Im März 2015 benannte Parallels den Service Provider Geschäftsbereich in Odin um.

Was ist ein Favicon und wie füge ich das Favicon zum WordPress Blog hinzu

Webseiten haben in der Regel ein Icon, das normalerweise am linken Rand des jeweiligen Tabs angezeigt wird und helfen unter verschiedenen Tabs die jeweilige Webseite besser identifizieren zu können. Auch in den Favoriten wird dieses Icon genutzt, daher heißt es Favicon. In diesem kurzen How-To erkläre ich Dir, wie Du das Favicon auch in deinen Blog bekommst.

Was ist das Favicon?

Favicon ist Ein Kofferwort aus dem englischen „Favourite-Icon“. Es ist auch als Shortcut-Icon, Website-Icon oder Bookmark-icon bekannt. Es ist ein rechteckiges Bild, das bei vielen Browsern vor dem jeweiligen Webseiten-Namen erscheint.

Erstmalig wurde dieses 1999 durch den IE5 unterstützt. Heutzutage unterstützen die meisten Browser dieses Favicon. Die Größe beträgt ursprünglich 16 x 16 Pixel. Heutzutage werden auch 32 x 32 Pixel und 48 x 48 Pixel von vielen Browsern unterstützt. Auf mobilen Geräten wird das Icon auch als Shortcut-Icon für den jeweiligen Screen genutzt. Daher sind von 56 bis 310 Pixel im Quadrat nötig.

Hauptsächlich wird über das Favicon die Benutzerfreundlichkeit gesteigert, da so der Tab oder der Favorit schneller gefunden werden kann.
Ebenfalls zeigt es häufig das Markenlogo, das als eine Art Siegel für den Nutzer fungiert und Vertrauen aufbaut:

Bekannte Symbole werden so mit Vertrauen vorbelegt und als Nutzer weiß man wo man hinzuklicken hat.

Ebenfalls zeigt es häufig das Markenlogo, das als eine Art Siegel für den Nutzer fungiert und Vertrauen aufbaut:

Bekannte Symbole werden so mit Vertrauen vorbelegt und als Nutzer weiß man wo man hinzuklicken hat.

Wie erstelle ich ein Favicon?

Die Erzeugung von Favicons ist angenehmer Weise kinderleicht. Du brauchst keinen Entwickler von uns Coding Pioneers engagieren. Du kannst ein individuelles Icon mit PhotoShop oder verschiedenen Online-Tools erstellen. Wenn Du die Grafik selber erstellst, dann beachte, dass immer eine Datei am besten mit dem Namen „favicon.ico“ dabei generiert wird in der Größe von 16 x 16 Pixeln.

Mit WordPress in der Version 4.3 (und folgende) ist das Seiten-Icon bereits als Feature im System und man muss nur noch eine Datei, die optimaler Weise 512 x 512 Pixel hat hochladen:
WordPress Dashboard > Design > Customizer: Hier in den Website Informationen das Website-Icon.

Ansonsten kann auch ein Generator, wie favicomatic genutzt werden, um die gewünschten Versionen eines Favicons zu erstellen. Diese werden dann auf den FTP-Server am besten in das root-Verzeichnis der WordPress-Installation gelegt oder entsprechend in das Theme-Verzeichnis unter wp-content > themes > ‚Theme Name‘.

Zurück im WordPress Backend muss noch eine Kleinigkeit an der header.php-Datei des Themes geändert werden. Dazu unter WordPress Dashboard > Design > Editor die header.php Datei öffnen (oder entsprechend über das FTP-Programm. Nun muss folgender Code nach dem <head> ergänzt werden:


<link rel="icon" type="image/x-icon" href="<?php echo get_stylesheet_directory_uri(); ?>/favicon.ico">

Wenn Du hingegen das favicon.ico im Template-Verzeichnis in die assets gelegt hast, musste du den Pfad entsprechend ergänzen:


<link rel="icon" type="image/x-icon" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/favicon.ico">

Wenn Du die Datei favicon.ico in das WordPress Root-Verzeichnis gelegt hast:

<link rel="icon" type="image/x-icon"href="http://www.deinewebseite.de/favicon.ico">

Wenn Du hingegen ein paar mehr Icons nutzen möchtest, könnte es auch entsprechend wie folgt aussehen:



<link rel="apple-touch-icon-precomposed" sizes="57x57" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/apple-touch-icon-57x57.png" /><br> <link rel="apple-touch-icon-precomposed" sizes="114x114" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/apple-touch-icon-114x114.png" /><br> <link rel="apple-touch-icon-precomposed" sizes="72x72" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/apple-touch-icon-72x72.png" /><br> <link rel="apple-touch-icon-precomposed" sizes="144x144" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/apple-touch-icon-144x144.png" /><br> <link rel="apple-touch-icon-precomposed" sizes="60x60" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/apple-touch-icon-60x60.png" /><br> <link rel="apple-touch-icon-precomposed" sizes="120x120" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/apple-touch-icon-120x120.png" /><br> <link rel="apple-touch-icon-precomposed" sizes="76x76" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/apple-touch-icon-76x76.png" /><br> <link rel="apple-touch-icon-precomposed" sizes="152x152" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/apple-touch-icon-152x152.png" /><br> <link rel="icon" type="image/png" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/favicon-196x196.png" sizes="196x196" /><br> <link rel="icon" type="image/png" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/favicon-96x96.png" sizes="96x96" /><br> <link rel="icon" type="image/png" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/favicon-32x32.png" sizes="32x32" /><br> <link rel="icon" type="image/png" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/favicon-16x16.png" sizes="16x16" /><br> <link rel="icon" type="image/png" href="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/favicon-128.png" sizes="128x128" /><br> <meta name="msapplication-TileImage" content="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/mstile-144x144.png" /><br> <meta name="msapplication-square70x70logo" content="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/mstile-70x70.png" /><br> <meta name="msapplication-square150x150logo" content="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/mstile-150x150.png" /><br> <meta name="msapplication-wide310x150logo" content="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/mstile-310x150.png" /><br> <meta name="msapplication-square310x310logo" content="<?php echo get_stylesheet_directory_uri(); ?>/assets/images/mstile-310x310.png" /><br>

Nach dem Editieren musst du die Änderungen nur noch speichern. Es kann sein, dass es einige Stunden/Tage Bedarf, bis das Icon sichtbar ist (alternativ kannst du auch deinen Browsercache leeren).

Viel Spaß mit deinem neuen Favicon, solltest du darüber hinaus noch Fragen haben, schreib uns gerne.

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

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

E-Mails an AOL können nicht gesendet werden

Dein E-Mail-Server kann keine E-Mails an *@aol.de-Adressen senden? Hier zeigen wir, wie Dein Postmaster diesen Missstand beheben kann und wie Dein Mailserver auf die Whitelist von AOL kommt.

Symptom der E-Mail-Probleme mit AOL

Auf einem unserer neueren Server trat das Problem auf, dass keine E-Mails an AOL gesendet werden konnten. Und das trat auf, obwohl der RDNS-Eintrag gesetzt war und wir auch auf keiner Blacklist standen. Die E-Mails sind einfach in der E-Mail-Warteschlange und irgendwann kommt folgende Fehlermeldung an den Absender:

Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long.

Explizites Whitelisting bei AOL zur Lösung nötig

Nach kurzer Recherche im Internet habe ich folgendes Portal bei AOL gefunden:
postmaster.aol.com

Dann ist hier ein Tool zum Prüfen der IP-Reputation:

postmaster.aol.com/ip-reputation

In unserem Fall war die Reputation gut, unter dem Ergebnis findet man jedoch den Hinweis:
„DYN:T1 errors usually occurs if you send high volume of mail. To resolve DYN:T1 errors, please apply for Whitelist.“. OK, nicht unbedingt schlüssig bei 10 Mails pro Woche an AOL, aber ich war zwischenzeitlich auch etwas ratlos.

Um sich auf die Whitelist eintragen zu lassen, auf postmaster.aol.com/whitelist-request den Bereich expandieren, Haken setzen und auf den nächsten Seiten alle Daten angeben. 10 Minuten später kommt eine E-Mail, die bestätigt werden muss, und ab diesem Moment kann man über den entsprechenden Server auch wieder E-Mails an AOL versenden.