Kategorie: Allgemein

Vorweg — hier handelt es sich um wordpress.org-Infos, nicht um Infos über den Hoster wordpress.com. Den Unterschied erklärt findet ihr hier.

Infos zum Gutenberg-Editor

Jessica Lyschik hat eine ausführliche Anleitung zum Gutenberg-Editor geschrieben. Ihr findet sie auf gutenberg-fibel.de.

Meetups

WordPress Meetups sind informelle Treffen, die meist Abends unter der Woche stattfinden. Es gibt Vorträge oder Diskussionsrunden, und man kann seine eigenen WordPress-Problemchen zum Lösen in der Gruppe mitbringen. Es sind alle von der blutigen Anfängerin bis zur Expertin willkommen.

Mittlerweile gibt es 30 Meetupgruppen, die sich über Deutschland verteilt regelmäßig treffen: WPMeetups

WordCamps

Jedes Jahr gibt es WordCamps in Deutschland, Europa und der Welt. WordCamps sind WordPress-Konferenzen bei denen es um alle Themen rund um WordPress, aber auch alles drumherum geht. Was da so passiert an Themen kann man z.B. gut auf WordPress.tv gucken, da die meisten Vorträge aufgezeichnet werde. Hier zum Beispiel das WordCamp Cologne 2018. Eine Übersicht aller WordCamps findet sich auf WordCamp Central.

WordCamp Europe Berlin 2019

Jedes Jahr findet auch ein WordCamp Europe statt, zu dem ca. 2500 WordPress-Enthusiastinnen kommen. Nächstes Jahr ist das in Berlin! Nach Leiden, Sofia, Sevilla, Wien, Paris und Belgrad dürfen wir dieses Jahr in Berlin Konferieren und Feiern. Als Teil des Orga-Teams würde ich mich freuen wenn ihr kommt 🙂
WordCamp Europe 2019

Infos

Alle Informationen über WordPress sollen sich, wenn es nach den Organisatorinnen geht, unter wordpress.org (deutsche Seite) befinden.

Es gibt auch einen deutschen Slack-Channel, der für die Weiterentwicklung von WordPress da ist (kein Support). Dort treffen sich WordPress-Übersetzerinnen, Meetup-Organisatorinnen, das Marketing Team und viele andere. Deutscher WordPress Slack

Das internationale Team, das an der WordPress Weiterentwicklung arbeitet trifft sich unter: make.wordpress.org und im internationalen WordPress Slack.

Hilfe und Support

Die Community hilft sich gegenseitig bei Problemen mit WordPress. Hilfe zu den Themes und Plugins bekommt ihr am Besten auf der Seite des jeweiligen Themes oder Plugins in Themeverzeichnis oder Pluginverzeichnis. Solltest du ein Theme oder Plugin gekauft haben, solltest du dich direkt an die Programmierinnen wenden. Links zum Support bekommst du bei der deutschen WordPress Hilfe.

Weitere Ressourcen

• WP Letter WordPress Newsletter
• WordPress Sicherheit Newsletter zu Sicherheitsthemen
• WordPress StackExchange
• Pixolin Blog zu WordPress-Themen
• Krautpress WordPress Community Magazin
• capital_P_odCast Anfänger Podcast
• WP Sofa Podcast
• PressWerk Podcast
  

Habt ihr Fragen oder hilfreiche Ergänzungen? Einfach kommentieren 🙂

Für die letzte Woche hatte ich mir einiges vorgenommen. Es stand das am nächsten vom Kölner WordCamp entfernte WordCamp an und der Barcamp-Klassiker in Köln, den ich nunmehr mehrere Jahre Besuche

WordCamp Nijmegen

Nur anderthalb Stunden von Köln entfernt liegt das hübsche Städtchen Nijmegen. Idyllisch an der Waal gelegen, riesen Einkaufsmeile (nicht soo schön), aber mit schönen kleinen Nebengässchen, wird das bestimmt bald auch mal ein Tagesausflug.

Am ersten Abend wurde in mein super AirBnB eingecheckt und direkt die Stadt erkundet. Ich bin die 20 Minuten gelaufen, was nicht ganz so schlau war aufgrund des immer stärker werdenden Regens 😀

Durchnässt habe ich aber mein Tagesziel erreicht! Bitterballen & Biertje!

Contributor Day

Der Contributor Day fand an der Radboud Universität statt und nach einem kleinen Besuch bei Albert Heijn (Croissant & Vla) ging es auch zu Fuß dahin.

Nach großem Hallo verlief der Tag bei bestem Wetter ziemlich ereignislos, ich habe leider nicht allzuviel geschafft, da ich noch etwas Arbeiten musste.

Bei deutlich besserem Wetter ging es dann wieder ins Städtchen. Und neben Besuch der Promenade gab es dann leckeres mexikanisches Essen.

Conference Day

Der Konferenztag wurde im neuen Lehrgebäude der Radboud-Universiteit veranstaltet. Alles superschick und neu, überall schöne Steckdosen für die Elektronik, perfektes WiFi.

Nach einem Vortrag von Marieke van de Rakt über SEO Site Structure, den ich beim WordCamp Europe verpasst hatte schaute ich noch Bridget Willard mit „A marketer’s guide to developing empathy“ bei dem ich einiges gelernt habe wie z.B., dass man mit seiner Zielgruppe immer interagieren sollte, weil man sie sonst nie verstehen wird.

Mein Highlight war der Vortrag von Rian Rietfeld, der mir vieles vieles an Barrierefreiheit-Fragen beantwortete. Die Ergebnisse werde ich schon bald auf meiner — und natürlich auf  meinen Kundenseiten umsetzen. Guckt mal wer da hinten am Fenster sitzt 🙂

Abends musste ich leider schon nach Hause obwohl es einen zweiten Konferenztag gab, denn am nächsten Morgen startete das:

Barcamp Köln

Als Wiederholungstäter musste ich natürlich zu dem jährlich stattfindenden Barcamp in den super Räumen der QSC AG. Es gibt immer spannende Sessions, und da es ein themenoffenes Barcamp ist — alles querbeet!

So startete ich mit 10 Tipps gegen Fakenews mit allerlei guten Infos von Benjamin Quiring (Kölner Stadtanzeiger). Als nächstes gab es ein Gesellschaftsspiel, das sehr viel Spaß bereitet hat:

Danach habe ich erstmal Mittag gemacht. Super Salatbuffet und etwas Gulasch-Spätzle. Ich war dann dran mit meiner eigenen Session zum Gutenberg-Editor und ich machte mich auf in den Raum „Stadt Köln“ — ja die Stadt hat sich tatsächlich überwunden das Barcamp zu sponsern — yay!

Es gab eine tolle SEO Site Clinik mit Isis Sarah Neuerbourg von Morefire und Harald Grocholl. Die beiden haben seo-technisch meine Website auseinandergepflückt und ich habe wieder viel viel gelernt, was ich besser machen kann.

Am Ende saß ich nochmal in einer offenen Session zu Marketingtools mit Stefan Warner in der ich fleißig für meine Kunden mitgeschrieben habe.

Der Abend wurde beendet mit der alljährlichen Pizzaschlacht und Networking was bei dem tollen Wetter sehr schön war.

Auch hier gab es einen zweiten Konferenztag, das hab ich aber wirklich nicht mehr geschafft. Zu Hause aufs Sofa gefallen. War doch etwas anstrengend alles 🙂

Trotz Beweisen, Rat und Tat und Beratung von allen Seiten meinen immernoch Menschen einen Slider (auch Karussel genannt) auf Ihrer Homepage oder auch Unterseiten einbauen zu müssen. Jeder Marketing-Mensch sollte wissen:

1. Die Slider werden nicht angeschaut, noch geklickt

Die UserInnen haben gelernt, dass das was sie auf der Website suchen sich auf gar keinen Fall in einem dieser Slider befindet. So wie bei der berühmten „Banner-Blindness“, bei der die UserIn die Werbung auf der Seite ausblendet funktioniert das auch bei den Slidern.

Gerade mal 1% der UserInnen klicken auf irgendwas, das sich in diesem Slider befindet! 1% für das wichtigste, prominenteste und größte Ding auf deiner Homepage? Das kann man besser machen.

2. Die Slider nerven die UserInnen!

Nicht nur Ignoranz sondern blanker Hass gegen Slider kommt von UserInnen. Die UserInnen mögen das so sehr nicht, dass Sie einen 98-Pixel-großen Font problemlos igorieren können. Das hat diese Studie bei einer Siemens-Seite herausgefunden. Lustig, dass die das immernoch so anwenden.

Es setzt auch der sogenannte Megafon-Effekt ein. Das ist alles so groß, bunt und bewegt sich alles, dass es mir zuviel ist und ich da nicht hingucken kann. Visueller Tinnitus.

Es verwirrt die UserInnen auch. Man schickt eine Vielzahl an Messages, die die UserIn entweder zum Großteil nicht interessieren oder vom deinem Hauptziel deiner Seite (Conversion) ablenken.

3. Nicht Barrierefrei

Menschen mit motorischen Einschränkungen können die Slider nur schwer oder überhaupt nicht bedienen.

Menschen mit kognitiven Einschränkungen können die Anzeigedauer nicht beeinflussen und somit nicht zu Ende lesen. UserInnen aus andern Ländern, die die Sprache nicht so gut können haben das gleiche Problem.

Oft sind die Slider so kompliziert programmiert, dass noch nicht einmal die Maschinenlesbarkeit gegeben ist und somit blinde UserInnen komplett raus sind (Google übrigens auch!). Also Accessibility-technisch: Setzen. Note 6.

4. SEO schädlich

Die Slider verlangsamen auch mit Performance-Optimierung signifikant die Ladegeschwindigkeit deiner Website. Es wird viel Skript geladen und ebenso viele ressourcenfressende Bilder. Das ist extrem schädlich für SEO, da Pagespeed ein großer Faktor ist bei Google.

Oft werden auch „falsche“ Überschriften in den Slidern geladen. z.B. 5x H1 in dem Slider, obwohl nur ein H1 auf jeder Seite sein darf. Das mag Tante Google gar nicht.

Hinzu kommt noch, dass dein eigentlicher Content nach unten rutscht. Das ist nicht nur für SEO schädlich auch:

5. Deine Conversion-Rate sinkt

Solltest du irgendwelche Ziele mit deiner Website verfolgen, und es wäre komisch, wenn dem nicht so ist, wird mir jede CRO-ExpertIn (Conversion Rate Optimization) zustimmen und dir sagen, dass die Erfolgsrate drastisch sinkt mit einem Slider auf der Seite. Jede CRO-Expertin wird dir sagen, dass jeweils eine Seite auch nur ein Ziel verfolgen kann und nicht 5. Und wenn das Ziel noch nicht einmal von der UserIn erblickt wird, erklärt sich das sehr einfach.

Mein Fazit & Empfehlung

Gerade auf der Startseite ist die Versuchung groß einen Slider einzubauen, um die Vielfalt deines Unternehmens oder was auch immer zu zeigen. Das, was du damit erreichst ist aber das Gegenteil. Keine deiner 5 Kommunikationsmaßnahmen in dem Slider erreichen die UserIn, deine Seite wird langsamer, sie wird weniger bei Google angezeigt und das eigentliche Hauptziel deiner Seite wird aktiv verhindert!

Meine Empfehlung für die Startseite wird es immer sein, die UserIn abzuholen. Sie hat gerade etwas gesucht und kommt auf die Website. Jetzt braucht Sie Bestätigung, quasi wie eine Belohnung, dass Sie hier richtig ist. Durch Logo und Design weiß Sie schon einmal wie dein Unternehmen heißt und welcher Look & Feel vermittelt wird. Aber macht ihr auch das, was sie sucht?

Deshalb: 3 bis 4 Sätze, die beschreiben was ihr anbietet oder macht und unterstützend ein Foto dazu, fertig.

So einfach kann es sein.

Aber ich bin Fotografin!

Nein. Auch du nicht.

Beispiel

Hallo, ich bin Phillip und ich erstelle professionelle Hundefotos von deiner geliebten Fellnase. In meinem Kölner Studio freue ich mich über euren Besuch! » Mehr über uns

p.s.: Eine große Leckerliauswahl ist vorhanden!

Ich verwende das Theme Atomic Blocks und wollte, dass meine Styles im Editor meinen Anpassungen im Child-Theme entsprechen. Dafür muss man erstmal die Original Editor Styles entfernen, bzw. ich habe Sie mit leerem Inhalt überschrieben. Dabei hat mir dieser Thread in den Gutenberg Issues geholfen.

Einmal geleert kann man nun eigene Editor Styles einbinden. Hier hat mir der Artikel von Florian Brinkmann geholfen.

Freue mich über Ideen, wie man das besser machen kann 🙂 Hier der Code für die functions.php im Child-Theme:

// Overwrite main theme editor styles with empty styles.
add_action( 'enqueue_block_editor_assets', 'philliproth_dequeue_styles' , 10 );

function philliproth_dequeue_styles() {
  wp_deregister_style( 'atomic-blocks-block-editor-styles' );
  wp_register_style( 'atomic-blocks-block-editor-styles', '' );
}

// Add my editor styles for Gutenberg.
add_action( 'enqueue_block_editor_assets', 'philliproth_add_gutenberg_assets' );

function philliproth_add_gutenberg_assets() {
  wp_enqueue_style( 'philliproth-gutenberg', get_theme_file_uri( '/css/editor-styles.css' ), false );
}

Oft ist es so, dass man aufgrund von schmalen Textblöcken gerne eine Silbentrennung auf Website verwenden möchte, oder man mag es einfach etwas aufgeräumter. Wichtig hierfür ist erstmal das lang-Attribut zu setzen im HTML-tag, bei WordPress klassischerweise in der header.php deines Themes. Für deutsch:

 <html lang="de">

Jetzt denkt ihr das muss doch de-DE heißen! Nee, das ist bei den lang-Attributen etwas anderes als z.B. bei Übersetzungen. Wer Langeweile hat liest hier beim W3C: Language tags in HTML and XML. Theme-Programmierer machen das auch gerne mal falsch 😉 Hier noch eine einfache Liste der Codes.

Als nächstes muss man die Silbentrennung per CSS aktivieren. Ein Beispiel für einen Absatz:

p {
  hyphens: auto;
}

Um Safari und Microsoft-Browser zu unterstützen, brauchen wir noch Prefixes — also:

p {
  -webkit-hyphens: auto;
  -ms-hyphens: auto;
  hyphens: auto;
}

Und das war es auch schon. Du kannst das bei WordPress in deine style.css einfügen, oder über den Customizer bei „Zusätzliches CSS“. Mittlerweile wird die Silbentrennung von den meisten Browsern unterstützt. Can I Use zeigt die Übersicht.

Eine Beispielseite

Gutenberg ist der neue WordPress-Editor, der mit der Version 5.0 von WordPress kommen wird. Der Editor ersetzt dann den noch aktuellen TinyMCE-Editor, der zum editieren von Seiten und Beiträgen verwendet wird. Hier einmal zum selber ausprobieren. In diesem Artikel zeige ich lediglich verschiedene Elemente, die der Editor anbietet. Das Aussehen der Elemente wird vom CSS des WordPress-Themes gesteuert.

Überschrift mit Trennelement drüber und drunter

Absatz — Veggies es bonus vobis, proinde vos postulo essum magis kohlrabi welsh onion daikon amaranth tatsoi tomatillo melon azuki bean garlic.

Zitat: Good things come to those who wait.

Mullenweg said Gutenberg might be here as early as August.

Ein Absatz mit Hintergrundfarbe, Textfarbe und DropCap. Gumbo beet greens corn soko endive gumbo gourd. Parsley shallot courgette tatsoi pea sprouts fava bean collard greens dandelion okra wakame tomato. Dandelion cucumber earthnut pea peanut soko zucchini. Gumbo beet greens corn soko endive gumbo gourd. Parsley shallot courgette tatsoi pea sprouts fava bean collard greens dandelion okra wakame tomato. Dandelion cucumber earthnut pea peanut soko zucchini.

Video — als Handy-Videos noch wackelten…

Audio — Camille Saint-Saëns

 Karneval der Tiere – VII. Aquarium 1886

Liste

• Liste 1
• Liste 2
• Liste 3
• Liste 4

Tabelle

Überschrift zentriert

Ja, das ist mein Hund. Veggies es bonus vobis, proinde vos postulo essum magis kohlrabi welsh onion daikon amaranth tatsoi tomatillo melon azuki bean garlic.

Gumbo beet greens corn soko endive gumbo gourd. Parsley shallot courgette tatsoi pea sprouts fava bean collard greens dandelion okra wakame tomato. Dandelion cucumber earthnut pea peanut soko zucchini.

Ein rausgezogenes Zitat!

rutscht raus aufm Desktop!

Turnip greens yarrow ricebean rutabaga endive cauliflower sea lettuce kohlrabi amaranth water spinach avocado daikon napa cabbage asparagus winter purslane kale. Celery potato scallion desert raisin horseradish spinach carrot soko. Lotus root water spinach fennel kombu maize bamboo shoot green bean swiss chard seakale pumpkin onion chickpea gram corn pea. Brussels sprout coriander water chestnut gourd swiss chard wakame kohlrabi beetroot carrot watercress. Corn amaranth salsify bunya nuts nori azuki bean chickweed potato bell pepper artichoke.

Widgets und Spalten

Drei Spalten und etwas CSS

Man kann auch mit CSS machen, dass z.B. eine dreispaltige Zeile breiter läuft als ne zweispaltige. Dann springt das etwas aus dem Layout.

Die Bilder kommen aus: WordPress Caching einfach erklärt. Gumbo beet greens corn soko endive gumbo gourd. Parsley shallot courgette tatsoi pea sprouts fava bean collard greens dandelion okra.

Gumbo beet greens corn soko endive gumbo gourd. Parsley shallot courgette tatsoi pea sprouts fava bean collard greens dandelion okra wakame tomato. Dandelion cucumber earthnut pea peanut soko zucchini.

Dateien

Code

<?php the_title(); ?>

Galerie

Eine HTTP/2-Umstellung ist bei WordPress unproblematisch. Es ist mit wenig Problemen zu rechnen. Es beeinflusst aber die Performance, und wie wir an Performance-Optimierung für WordPress in Zukunft herangehen müssen/können. Dein Hoster kann dir sagen, ob du deine Seite auf einen HTTP/2-Server umziehen kannst.

Im Moment übertragen Server noch hauptsächlich mit dem „hypertext transfer protocol“ HTTP 1.1 von 1997.  Einfach gesagt öffnet HTTP 1.1 nur eine Pipeline für 6 gleichzeitige Übertragungen von Dateien (also 6 gleichzeitige Downloads). HTTP/2 öffnet einmal ne Pipeline und lässt dann alles durch. Man spricht hier von „Push“. Außerdem werden Header komprimiert und Requests (Anfragen/Dateien) priorisiert. Man beachte: Für die Auslieferung über HTTP/2 ist HTTPS Pflicht!

Bis dato habe ich meine Webseite für HTTP 1.1 optimiert. Also auf möglichst wenige Requests minimiert durch z.B. zusammenlegen von Skripten. Das kann man alles in meinem Artikel zu WordPress Performance lesen.

Eine Umstellung auf HTTP/2 macht einiges davon obsolet, bzw. man muss etwas anders an die Optimierung rangehen. Meine Optimierung war natürlich! schon sehr gut, deshalb bewegt sich jegliche Verbesserung im Millisekundenbereich.

Meine Webseite auf HTTP 1.1:

Ich teste meine Startseite immer mit dem Pingdom Tool Servereinstellung auf Schweden/Stockholm:

Der Lade-Wasserfall am heimischen Rechner sieht dann so aus:

Man sieht sehr schön (klick aufs Bild zum zoomen) wie nur 6 Leitungen gleichzeitig auf sind. Wenn eine Leitung frei wird, fängt eine neue Datei an zu laden. Man sieht auch, das Köln näher am Server ist als Schweden, sonst würde der nicht so schnell laden ?  Die Connaisseuse sieht auch, dass da einiges an Schwachsinn geladen wird wie z.B. die Icons der fontawesome.ttf. Das muss ich dringend mal auf .svg-icons umbauen. PIWIK Analytics auf meinem eigenen Server (statt Google Analytics, weil ich den Amis nix schicken möchte) haut am Ende nochmal richtig rein. Aber so am Ende ist das nicht so tragisch.

Meine Webseite auf HTTP/2

Ca. 50 ms schneller mit HTTP/2 – nice! Woran liegt’s?

Wie man direkt sieht: keine 6 Kanäle offen sondern einfach komplett offen. Als letztes werden die Fonts geladen, was vermutlich an meinem Font-Loading-Script liegt. Das werde ich mir mal genauer anschauen müssen.

Für die Zukunft muss ich mich mal ein wenig in die Materie einlesen müssen. Kleine Dateimengen werden immer noch der richtige Weg sein. Man kann sie in Zukunft sogar mehr aufteilen, wenn man möchte. Aber 100 .css-Dateien oder ähnliches sollte man natürlich trotzdem vermeiden.

Anregungen?

Es gibt verschiedene Arten von Caching. Die meisten von uns kennen das sogenannte Browsercaching. Da werden Inhalte, die einmal in den Browser geladen wurden, wie z.B. ein Bild, im eigenen Browser gespeichert, so dass beim neuen Laden der Seite das Bild nicht schon wieder geladen werden muss. Das spart Zeit, wenn man z.B. eine Seite zurück springt. Das Bild ist sofort da. Wir reden hier heute aber über etwas anderes 🙂

Caching macht deine Website schneller. Bei WordPress ist es so, dass die Inhalte, die du z.B. für einen neuen Blogartikel eingibst in einer Datenbank gespeichert werden. Eine Datenbank kann man sich wie eine Sammlung vieler langer Excel-Tabelle vorstellen. Da stehen dann alle Dinge drin die du über die WordPress-Oberfläche gespeichert hast. Bei diesem Blogartikel ist es z.B.: wo meine Logodatei liegt, welche Punkte im Navigationsmenü stehen sollen, der Titel des Blogartikels, das Datum, der Autor, der Inhalt des Artikels und so weiter.

Um jetzt diese Inhalte aus der Datenbank heraus zu holen muss der Server sich etwas anstrengen, und das braucht Zeit. Er muss jetzt aus allen Tabellen die Inhalte herausfiltern, die auf der Seite dargestellt werden und das ganze in einem HTML-Dokument verpacken. Das kann dann an den Browser rausgeschickt werden, der diese Inhalte dann darstellt.

Das passiert bei jeder Anfrage des Browsers ohne Datenbank-Caching:

Optimieren lässt sich das in dem man Caching aktiviert. Dafür gibt es verschiedene Methoden, aber das Ergebnis ist in etwa das Gleiche. Der Server erstellt bei der allerallerersten Anfrage des Browsers das HTML Dokument und legt es dann als fertige HTML-Version in einen Ordner ab. Schon bei der zweiten Anfrage wird jetzt nur noch dieses fertige HTML-Dokument an den Browser geliefert und man spart sich die zeitfressenden Datenbankabfragen. Die Seite ist jetzt gecached.

Auf dem Schaubild sieht man, dass der Server nur einmal das HTML-Dokument erstellt und dann ablegt. Der Browser bekommt von nun an nur das abgelegte HTML-Dokument geliefert. Nicht verwirren lassen – in den meisten Fällen handelt es sich hier um denselben Server, der diese Sachen für dich tut.

Der kleine Trick kann je nach Seite zu bis zu 80% schnelleren Ladezeiten führen. Gerade bei komplexen WordPress Themes, die viele hundert Einstellungen in den Datenbanken gespeichert haben führt dies zu einer deutlichen Verbesserung der WordPress Performance.

Für diese Aufgabe gibt es einige WordPress Plugins wie z.B. WP Fastest Cache oder WP Super Cache, die diese Sachen für dich erledigen können. Aber Vorsicht! Nicht jeder Server kann das. Man muss also manchmal ein bisschen ausprobieren, was auf dem eigenen Server funktioniert.

Außerdem gibt es noch einige WordPress-Hosting-Anbieter, die diese Funktion direkt auf ihrem Server installiert haben. Bei denen musst du gar kein Plugin installieren, da funktioniert das von selbst.

Was ist zu beachten

Wenn du einen Cache eingerichtet hast gibt es ein kleines Problem. Nämlich dann, wenn du Änderungen an deiner Seite vornimmst. Diese sind mit Caching natürlich nicht direkt auf deiner Seite sichtbar.

Mal angenommen du schreibst einen neuen Blogartikel. Dieser muss dann in der Blogliste auftauchen. Der Server weiß aber noch nichts von deinem neuen Blogartikel und liefert fleißig die gespeicherte alte Blogliste aus, ohne deinen neuen Artikel. Einige Plugins haben dafür extra Einstellungen, um das neu ablegen der Seiten („Cache leeren“) zu automatisieren, die solltest du dir genau anschauen. Die meisten haben auch einen kleinen Button „Cache leeren“ oder „Delete Cache“ mit dem du die Leerung manuell vornehmen kannst.

Wenn dein Hoster für dich Cached gibt es meistens auf der Bedienoberfläche des Hosters einen Button zum Cache leeren.

Wenn du noch mehr über WordPress Optimierung wissen möchtest kannst du hier weiterlesen: WordPress Performance.

Ich freue mich über Fragen und Anregungen in den Kommentaren (ja, auch bei einem neuen Kommentar muss der Cache gelöscht werden 😉

Google hat ein neues Projekt, dass Accelerated Mobile Pages oder auch „AMP“ heißt. Man möchte damit abgespeckte, mobil-optimierte Seiten anbieten, die superschnell laden. Das sollte deine Webseite im besten Fall auch so schon machen, aber wenn du deine WordPress-Beiträge auch als „AMP“-Version anbietest werden diese höher in den Google Suchergebnissen gerankt. Also ein guter Grund sich das mal anzuschauen.

Umsetzen kannst du das mit einem Plugin. Es gibt dafür ein schickes Plugin von Pagefrog, dass dir bei der Einrichtung hilft. Einfach installieren und den Anweisungen folgen, und schon hat man mit dem Anhängsel /amp/ an seiner Artikel-URL eine AMP-Seite (Beispiel). Das Plugin braucht auf jeden Fall auch das von Automattic entwickelte AMP-Plugin.

Der Haken

Das AMP-Plugin reduziert deine Seite soweit, dass es keinen Footer mehr gibt. Und da es in Deutschland ja Gesetz ist, dass ein Impressum-Link zu sehen sein sollte muss etwas hinzugefügt werden.

Ich hab mich an die Anleitung von Guru 2.0 gehalten und bin sehr zufrieden mit dieser einfachen Methode. Der Code wird in die functions.php eingefügt:

//Fusszeile hinzufuegen
function philliproth_addFooter($amp_template) {
  $blog_title = ''.get_bloginfo('name');
  ?>
  <footer class="amp-wp-title-bar">
    <div>
      <a href="<?php echo get_home_url(); ?>" title="<?php echo esc_html($blog_title); ?>"> 
        <amp-img src="https://www.philliproth.de/wp-content/uploads/2016/04/Logo_Webx-amp.gif" 
                 alt="<?php echo esc_html($blog_title); ?>" 
                 width="270" height="65"></amp-img> 
      </a><br>
      <a href="<?php echo get_home_url(); ?>/impressum" title="Impressum von <?php echo esc_html($blog_title); ?>">Impressum und Datenschutz</a> | 
      <a href="<?php echo get_home_url(); ?>/kontakt" title="Kontakt zu <?php echo esc_html($blog_title); ?>">Kontakt</a>
    </div>
  </footer>
  <?php
}
add_action('amp_post_template_footer', 'philliproth_addFooter');

WordPress AMP CSS hinzufügen

Als Designer fand ich das aber alles nicht ganz so hübsch und musste also eine Methode finden, dass etwas zu stylen. Hierbei half mir dieser Artikel von Delicious Brains.

Mit ein paar zusätzlichen Zeilen in der functions.php kann man also einige Anpassungen machen (gekürzt):

add_action( 'amp_post_template_css', 'philliproth_amp_css_styles' );
function philliproth_amp_css_styles( $amp_template ) {
    // only CSS here please...
    ?>
    
    body {
    	    background: #edede9;
    }

    footer {
    	text-align: center;
        background-color: #fff;
        padding-bottom: 20px;
    }
    
    footer a{
    	text-decoration: none;
    }
    
    footer img {
    	margin-left: 5px !important;
    }
    
   
    <?php
}

Hab ich alles richtig gemacht?

Mit den Entwicklertools von Chrome könnt ihr testen ob ihr und das Plugin alles richtig gemacht habt. Hinter die URL hängt ihr: #development=1 (Beispiel) und öffnet dann in den Developer-Tools die Console. Jetzt müsst ihr nochmal die Seite neu laden und schon seht ihr entweder Fehler oder das schöne „AMP validation successful.“ Viel Glück!

Habt ihr die Google Search Console in den Webmaster-Tools für eure Webseite aktiviert, wird euch Google zusätzlich nach dem nächsten Crawl sagen, ob ihr alles richtig gemacht habt unter „Darstellung der Suche -> Accelerated Mobile Pages“

Habt ihr schon Erfahrungen mit AMP gemacht? Freue mich über Anregungen!