Darauf stößt der ambitionierte WordPress-Neuling meist sehr früh in seiner Karriere. „Ist das übergeordnete Verzeichnis durch den Server beschreibbar?“ Anscheinend nicht 😉 Dafür sind auf jedem Server Dateirechte verantwortlich. Diese bestimmen, was ein „User“ mit den Dateien anstellen darf und was nicht. „User“ sind z.B. du, der FTP-User oder der Webserver-User.
Die Dateirechte (file permissions) kannst du mit jedem FTP-Programm ändern, den Dateibesitz kannst du meistens über die Bedienoberfläche bei deinem Hoster ändern.
Too long?
Der Besitzer der Dateien sollte der Server-User oder dein FTP-User Account sein
Dein Server und dein Account sollten der gleichen User-Gruppe angehören.
alle Dateien sollten auf 664 stehen
alle Ordner sollten auf 755 stehen
die wp-config.php sollte auf 660 stehen
User & Gruppen
Auf einem „normalen“ Shared Hosting, wie es die meisten von uns benutzen sind viele FTP-User, die sich einen Server teilen. Auf dem Server liegen z.B. 299 Webseiten und deine. Jeder der FTP-User hat also Zugriff auf den Server mit bestimmten Rechten. Zum Beispiel kannst du ja nur in dein Verzeichnis mit deiner Webseite reingucken, aber nicht bei den anderen.
Neben all den Usern gibt es noch den Server selbst als User. Der Server-User gehört im einfachsten Fall zu einer Gruppe mit dir, dem FTP-User.
Besitzrechte
Wenn wir eine Datei als FTP-User hochladen, sind wir normalerweise gleich die Besitzer dieser Datei auf dem Server. Wir können jeder Datei, die wir besitzen über unser FTP-Programm Dateirechte geben. Wir können jetzt also sagen was wir als Besitzer, was die Gruppe (du und der Server-User), und was „Andere“ mit den Dateien veranstalten dürfen. „Andere“ sind alle, jeder, die Weltbürger mit Internetanschluss. „Andere“ sollten auf keinen Fall Dateien ändern dürfen (write permission). Dann kann nämlich wirklich jeder alles, irgendetwas, z.B. Spam-verschickenden Code in deine Dateien einfügen und deine Webseite hacken.
Was sagen uns die Zahlen?
Dateirechte sehen irgendwie so aus: 755. Lesen ist 4, Schreiben ist 2, Ausführen ist 1. Wenn der Besitzer also Lesen, Schreiben und Ausführen darf ist die erste Zahl der Dateirechte die Summe aus 4+2+1=7. Mit „0“ darf man gar nix, kommt deshalb auch in der Liste nicht vor.
Berechtigungen
4: Lesen
2: Ändern
1: Ausführen
Summe
Besitzer
✔ Lesen
✔ Ändern
✔ Ausführen
7
Gruppe
✔ Lesen
Ändern
✔ Ausführen
5
Andere
✔ Lesen
Ändern
✔ Ausführen
5
755
(Auf dem Handy die Tabelle nach links wischen)
Wie brauchen wir das für WordPress?
alle Dateien sollten auf 664 stehen
alle Ordner sollten auf 755 stehen
die wp-config.php sollte auf 660 stehen (bitte beachte, dass das bei einigen Webservern zum Crash führen kann, probiere es dann mit 664)
Was erreichen wir damit?
Unser FTP-User darf Dateien lesen und ändern.
WordPress (der Webserver-User) darf die Dateien lesen und ändern
WordPress darf Dateien und Ordner erstellen, ändern und löschen
Andere dürfen auf keinen Fall unsere Datenbankzugangsdaten in der wp-config.php lesen oder ändern
Ein Beispielproblem
Bei all-inkl.com besteht das Problem, dass der Webserver-User nicht in einer Gruppe ist mit dir. Die Dateien gehören erstmal komplett dem FTP-User, also dir. WordPress benutzt aber den Webserver-User. Der darf dann aber keine Dateien und Ordner anlegen, weil er nicht in einer Gruppe ist mit dir, dem FTP-User.
Daher muss man bei all-inkl über das WEBFTP die Dateibesitzrechte anpassen. Der Webserver-User heißt bei all-inkl „PHP-User“. Aber Vorsicht! Wenn du jetzt eine Datei mit deinem FTP-Programm überschreiben willst geht das nicht mehr, denn du als FTP-User bist nicht mehr der Besitzer. Wenn du eine neue Datei mit deinem FTP-Programm hochlädst bist du natürlich auch der Besitzer.
Wenn du ein Sprachplugin wie Multilingual Press, Polylang, qTranslate X oder WPML nutzt, hattest du bestimmt schonmal das Problem, dass du außer den Inhalten einen Bestandteil des Themes für die jeweilige Sprache anders darstellen möchtest. Das Plugin kümmert sich zwar um die Text- und Bildinhalte die du in Beiträge und Seiten einfügst, aber nicht unbedingt um das drumherum.
Ein Use-Case für diesen wäre z.B. ein Slider oder ein Logo. Hier ist ein einfacher, erweiterbarer Codeschnipsel.
Beispiel: Shortcode anzeigen auf einer bestimmten Seite (13) mit einer bestimmten Sprache.
<?php if (is_page(13)) {
$curLang = substr(get_bloginfo( 'language' ), 0, 2);
switch ($curLang) {
case "de":
// german slider for german users
echo do_shortcode("[slidey id='1']");
break;
case "en":
// english slider for english users
echo do_shortcode("[slidey id='2']");
break;
case "es":
// spanish slider for spanish users
echo do_shortcode("[slidey id='3']");
break;
}
}
?>
<?php
if (ICL_LANGUAGE_CODE == 'en') {
// put your code here if the current language code is 'en' (English)
} elseif (ICL_LANGUAGE_CODE == 'id') {
// put your code here if the current language code is 'id' (Indonesian)
}
?>
Vielleicht habt ihr das ja schonmal selber gemacht. Würde mich interessieren wie!
In einen neuen Ordner unter wp-content/themes/ fügst du einen neuen Ordner ein mit dem Namen „child-theme-s“ ein. (wp-content/themes/child-theme-s/) In den Ordner brauchen nur zwei Dateien + deine JavaScript Datei im Unterordner /includes/js/
Code für die functions.php. In der functions.php wird zuerst das Stylesheet des Parent-Themes geladen, dann das Stylesheet des Child-Themes und dann deine JavaScript-Datei.
Um WordPress auf einer optimalen Platform laufen zu lassen sollte man im Idealfall bei einem expliziten WordPress-Hoster wie Raidboxes, Wir lieben WordPress oder Savvii seine Webseite laufen lassen, denn diese wissen zu 100% auf was es den WordPress-Kunden ankommt und haben zudem interessante Features wie Staging oder automatische Backups auf WordPress zugeschnitten. Die anderen Hoster bieten aber natürlich auch brauchbaren Webspace.
Optimale Verbindungszeiten bekommst du wenn der Server möglichst nah bei deinen Kunden steht, also achte auch darauf wo sich die Server befinden. Wenn deine Kunden hauptsächlich Amerikaner sind nimm einen amerikanischen Hoster, sind sie alle in Deutschland – einen deutschen oder niederländischen. Ich werde hier extra keine Wertung abgeben. Schaut selber und vergleicht! (Warnung: T-Online kann ich nicht empfehlen, da man da keine .htaccess anlegen kann, die man z.B. für Pretty URLs oder Performance-Optimierung braucht.)
Auch solltet ihr darauf achten, dass ihr euch per SFTP/SSH sicher mit dem Server verbinden könnt, und dass kostenlose SSL-Zertifikate für https zur Verfügung stehen.
Über Webperformance gibt es viele viele Bücher. Dieser Artikel ist alles andere als vollständig und erklärt nur, was man im Kleinen, kostenfrei selber machen kann. Für diesen Artikel solltest du wissen was ein „Webhoster“ ist, deine eigene WordPress Installation haben und wissen wie ein Plugin installiert wird.
Warum eigentlich?
Es wird immer wichtiger Webseiten für eine schnelle Auslieferung an den Kunden zu optimieren. Der erste Eindruck ist der wichtigste und zu dem gehört die Performance. Wenn du eine halbe Stunde auf dein Bier warten musst in einer Bar bist du schnell weg. Nicht umsonst ist die Webseitengeschwindigkeit einer der wichtigsten Kriterien für das Google-Ranking. Du tust also gleichzeitig etwas für deine User und für deine Suchmaschinenoptimierung, wenn du deine WordPress Webseite schneller machst.
Ein guter Server allein reicht dafür nicht aus, ist aber natürlich hilfreich. Es gibt viele super WordPress-Hoster in Deutschland. Gehe besser zu diesen und nicht zu den Großen, die Fernsehwerbung machen. Ich möchte jedoch weniger auf die Serveroptimierung eingehen, sondern eher auf die Optimierung, die man selber durchführen kann. Hier heißt es auch: Ausprobieren, Testen, Ausprobieren, Testen.
Wie teste ich die Geschwindigkeit?
Hierzu gibt es einige kostenlose Seiten, die dir genau sagen können, wie schnell deine Seite zur Zeit ist, und vielleicht sogar schon Anregungen geben, was du verbessern kannst. Falls möglich, wähle eine Testlocation möglichst nah an deinem Wohnort (z.B. Frankfurt). Mach so drei bis vier Durchläufe und schreibe dir die Testergebnisse auf! Normalerweise testet man erstmal seine Startseite.
Wichtig sind:
„Requests“ – Anfragen an den Server, z.B. eine Skriptdatei=eine Anfrage
„Load Time“ – Gesamtladezeit der Seite in Sekunden oder Millisekunden
„Page Size“ – Webseitengröße in Kilobyte oder Megabyte
Das sind die drei Faktoren, die du minimieren willst. Die Ergebnisse können direkt variieren, deshalb ist ein Durchschnitt besser zum Vergleich. Gerade bei Shared Webhosting kann das Ergebnis auch noch stark nach Tageszeit variieren. Hier einige Seiten zur Auswahl:
http://www.webpagetest.org/ Braucht etwas Zeit der Test, gibt aber eine gute Übersicht und verteilt Noten (A gut, bis D schlecht)
https://gtmetrix.com/ GTmetrix gibt dir Pagespeed- und YSLOW-Score und sagt die was du verbessern kannst.
Tools zum Testen
Am schönsten wäre es an mehreren echten Geräten zu echten Bedingungen zu Testen und gleich die Werte dazu zu sehen. Ist aber viel zu umständlich. Du kannst auf deinem eigenen Rechner Testen. Das ist praktisch, um die Requests und Page Size zu optimieren, bevor du wieder die Online-Tools zur Hilfe nimmst. Tests auf echten Geräten kann ich trotzdem empfehlen, um zu wissen wie es sich anfühlt, wenn die Seite fünf Sekunden braucht.
Am Rechner nimmt man sich die Entwickler-Tools von Chrome oder Firefox. Hier wählst du „Network“ oder „Netzwerk“. Du kannst auch live sehen wie lange deine Seite z.B. mobile mit 3G zum laden braucht. Sehr praktisch. Neben dem Ladewasserfallchart stehen unten links in der Ecke die harten Fakten. Achte darauf das Häkchen bei „Disable Cache“ zu setzen, denn du willst ja wissen, was passiert, wenn jemand zum ersten Mal auf deine Seite kommt.Das Häkchen deaktiviert den Browsercache auf deinem Rechner. Achte auch darauf, dass du aus WordPress ausgeloggt bist beim Testen! Du willst ja Testen wie sich die Seite für normale Besucher der Seite verhält.
WARNUNG
Bevor du irgendwelche Plugins testest, Skripte änderst oder sonstige Anpassungen vornimmst, mache ein komplettes Backup deiner Webseite und deiner Datenbank. Nicht jedes Plugin kann/muss sich mit deinem Server oder auch deinem Theme vertragen. So kannst du im schlimmsten Fall alles wieder herstellen. Im einfachsten Fall brauchst du einfach nur das Plugin deaktivieren und löschen. Ausprobieren heißt hier die Devise.
Server
Sagte ich du kannst selber nichts am Server ändern? Doch! Wenn du kannst schau bei deinem Webhoster nach welche PHP Version dein Server nutzt und verwende die neueste Version. Vorher aber nochmal die Warnung lesen!
Theme & Bilder
Als erstes sollte man darauf achten, dass man kein Theme benutzt, dass siebenhundert Ansichten, Funktionen und Slider darstellen kann. Diese haben von Haus aus ein Performance-Problem, da sehr viel HTML, CSS und sehr viel Javascript ausgeliefert wird. Das wirkt sich sowohl auf die Anzahl der Anfragen, als auch auf die zu ladende Datenmenge aus und somit auf die Geschwindigkeit.
Das Theme an sich sollte möglichst wenig Bilder und Grafiken beinhalten, um hier schonmal die Byte-Zahl gering zu halten. Die Bilder kann man nochmal optimieren mit einem Programm wie z.B. ImageOptim (nur optimieren) oder Gimp (auch bearbeiten).
Dein Content sollte so gestaltet sein wie du es möchtest. Da kannst du nicht unbedingt auf Bilder verzichten, optimieren solltest du diese trotzdem vor dem hochladen. Lade die Bilder nie in Originalgröße hoch. Wer hier auf Nummer sicher gehen möchte nimmt so etwas wie den Optimus Image Optimizer , ShortPixel oder WP Smush , die das für dich automatisch erledigen. In den Entwicklertools kannst du genau sehen für wie viel der Ladezeit deine Bilder verantwortlich sind indem du im Network-Fenster auf „Images“ klickst.
Lazy Load
Ein Skript, dass nur die Bilder lädt, die auch im Viewport des Users zu sehen sind. Alles was er noch nicht sehen kann, wird auch noch nicht geladen. Scrollt der User herunter werden auch erst die Bilder geladen, die dann gebraucht werden. Ein einfaches Plugin hierfür ist z.B. Crazy Lazy oder BJ Lazy Load. Man muss immer ein wenig rumprobieren, was mit dem eigenen Theme am Besten funktioniert.
Schriften
Du solltest auch darauf achten möglichst wenige Schriftschnitte zu verwenden, denn auch diese müssen geladen werden. Viele Themes bieten die Möglichkeit ganz einfach Google Fonts zu implementieren. Das ist zwar praktisch, führt aber oft dazu, dass du natürlich mehrere Schriften lädst. Das kann die kleine Fußzeile sein in der nur „Copyright“ steht und schon eine Schrift mehr geladen +50kb.
Des Weiteren werden bei dieser Methode regulär vier verschiedene Versionen von jedem dieser Schnitte geladen, um die Schrift in allen Browsern richtig darzustellen. Moderne Browser laden wirklich nur die Schriften, die auch dargestellt werden, aber einmal fett oder italic oder italic & fett im Text und es werden direkt diese Schriftschnitte hinzugeladen. Für mehr Performance könntest dich entscheiden, z.B. nur die .woff-Datei der Schrift einzubinden, die auf den meisten Browsern dargestellt wird. Falls dann ein Browser dies nicht darstellen kann, wird eine Ersatzschrift angezeigt.
Wenn du etwas fit bist in HTML und CSS kannst du die Google-Schriften selber über https://google-webfonts-helper.herokuapp.com/fonts einbinden. Das ist richtig angewendet performanter als die Einbindung per Google-Script. Zusätzlich hat es den Vorteil, dass Google nicht jedes mal nach Hause telefoniert.
Caching
Caching wird dir viel Performance bringen. Caching kennst du von deinem eigenen Browser, der bereits besuchte Seiten „cached“. Das heißt, er merkt sich die Dateien die geladen wurden, speichert diese auf deinem Rechner und hat diese direkt bei einem Neuaufruf bereit.
Caching für dein WordPress läuft etwas anders ab. Normalerweise fängt der Server bei Seitenaufruf an deine Seite zusammen zu bauen und benötigt nun die Inhalte aus deiner Datenbank. Diese sucht er sich jetzt mühsam nach und nach aus den Datenbankeinträgen heraus, vom Logolink, über deinen Text, bis zu den Links in deinem Footer, oder was sonst noch so in deiner Datenbank gespeichert ist. Das dauert natürlich und dein Server hat viel Arbeit damit.
Also setzen wir Caching ein. Nach dem allerallersten Aufruf der Seite merkt sich der Server, welche Inhalte er aus der Datenbank „eingebaut“ hat und braucht von nun an nicht mehr bei jedem Aufruf alles aus der Datenbank heraussuchen. Das komplette HTML-Dokument mit den Informationen aus der Datenbank wird quasi zwischengespeichert und kann ohne Umwege direkt geladen werden.
Für Anfänger empfiehlt sich das Plugin Cachify, dass diese Aufgabe gut erledigt. Fortgeschrittene können sich an den zahlreichen Einstellungen von WP Fastest Cache oder WP Super Cache die Zähne ausbeißen, um das Bestmögliche heraus zu holen. Es gibt auch Bezahlplugins wie z.B. WP Rocket, die dir mit einem guten Support helfen alles optimal einzurichten.
Möglichst wenig Skripte
Dein Theme, deine Plugins und WordPress selber, alle laden Skripte. Setze also ein schlankes Theme ein und möglichst wenig Plugins. Wenn du kannst lade Skripte nur dort, wo sie gebraucht werden. Zum Beispiel ein Skript für ein Kontaktformular wird nur dort gebraucht, wo es auch auftaucht; ebenso ein Skript für eine Google Map, einen Kalender oder ähnliches. Je weniger Skripte, desto weniger Ladezeit. Manchmal wird für eine kleine Funktion viel zuviel Skript geladen. Wenn du darauf Einfluss hast, reduziere die Skriptmenge.
Skripte zusammenlegen (merge / concatenate)
Wenn du aus 4 Javascripten und 7 CSS-Dateien eine Javascript und eine CSS-Datei machst, muss der Server weniger Anfragen (Requests) bearbeiten. Simpel und effektiv. Autoptimize kann das natürlich, es gibt aber auch Plugins wie Merge+Minify+Refresh, die das für dich erledigen.
Skripte Minifizieren (minify)
Neben der Reduzierung der Skriptanzahl an sich, kannst du die Skripte selbst auch noch optimieren. Sowohl dein Hauptdokument, als auch die geladenen Skripte enthalten Leerzeichen, Umbrüche und Tabs, die kein Webbrowser braucht, um deine Seite richtig darzustellen. Hierfür gibt es zahlreiche Plugins wie Merge+Minify+Refresh. Einfach mal in den Plugins suchen und testen.
Skripte in den Footer
Um deinen Usern möglichst schnell die Seite zu zeigen, kannst du einige Skripte erst am Ende deines Dokuments laden. Mit einem Tool wie Async JavaScript kann das z.B. Nichts für Anfänger! Du solltest genau wissen, welche Sachen der User direkt beim Laden braucht und welche nicht.
Critical CSS
Die Vollprofis laden nur das CSS direkt, dass man auch für die erste Ansicht braucht. Der Rest wird im Footer geladen.
Und?
Puha. Wenn du das alles gemacht hast, können schonmal zwei/drei lange Abende vorüber sein. Im Idealfall brauchst du aber an deinen Einstellungen nichts mehr zu ändern und hast nun eine dauerhaft optimierte Seite! Glückwunsch!
Reicht noch nicht? Dann Google mal was ein CDN ist, Domain Sharding, was Expire header, HHVM oder nginx ist. Schneller geht immer!
[EDIT] W3 Total Cache wurde aus dem Beitrag vollkommen entfernt, weil es in letzter Zeit einige Sicherheitslücken gab und es offiziell nicht kompatibel ist mit WordPress 4.7
Zur Auswahl eines Themes ist es ideal, wenn man schon zu 80% weiß, was auf den Seiten darzustellen ist. Man sollte sich das Design nach dem Content aussuchen. Textlastige Webseiten sollten anders gestaltet sein als eine reine Fotoseite. Viele Menüpunkte mit vielen Unterpunkten sollten anders angeordnet sein als z.B. nur vier Menüpunkte.
Und bitte aufpassen, dass das Theme nicht aus 400 Gestaltungsmöglichkeiten besteht. Damit ist es nämlich definitiv so aufgebläht, dass die Ladezeiten stark darunter leiden und das Anpassen zur mehrstündigen Qual wird. Man sollte sich also ein Theme aussuchen, dass für die eigenen Zwecke ausreicht, aber wenn möglich auch nur wenig mehr kann. Ein Schweizer Messer mit 200 Funktionen ist unpraktisch.
Wer des englischen mächtig ist kann sich diesen Vortrag von Tammie Lister anschauen. Dort ist es perfekt beschrieben.
Und auch dies sollte man beachten:
Click here to display content from Twitter. Erfahre mehr in der Datenschutzerklärung von X.
Um in WordPress einen Custom Post-Type zu erstellen öffnet man die functions.php seines Themes und fügt folgendes ein. Wir nennen den Post-Type einfach mal „Songtexte“.
Die meisten Webseiten müssen nicht gesichert werden damit sensible Daten gesichert werden, sondern damit die eigene Webseite nicht zum SPAM-verschickenden Monster wird. Die Hacker präparieren die Seite so, dass sie SPAM verschickt. Das merkt nämlich Google ganz schnell und dann ist man quasi offline und es wird dieses schöne Ding angezeigt:
Das möchte man natürlich nicht!
Alle meine Kunden bekommen von mir ein komplettes Security-Paket. Das kann man natürlich auch selber machen. Hier die Maßnahmen:
Salt-Passwörter in der wp-config.php
Die sollten eigentlich schon bei der Installation benutzt werden. Einige Anfänger vergessen dies aber ganz gerne. Wie in der wp-config.php-Datei selbst beschrieben bekommt man die hier: https://api.wordpress.org/secret-key/1.1/salt/
Und kopiert die dann einfach in die entsprechenden Zeilen ein. Beispiel:
Das Datenbank-Prefix steht standarmäßig auf „wp_“ in der wp-config.php. Von diesem Standardwert gehen natürlich auch die Hacker aus. Deswegen von Anfang an ändern oder mit diesem Plugin nachträglich ändern: https://wordpress.org/plugins/db-prefix-change/
Standarduser „admin“ auf ID=1 ändern
Oft verwenden WordPress Benutzer nur ihren zuerst erstellten User. Der bekommt standardmäßig von WordPress die ID=1. Am beliebtesten ist außerdem der Loginname „admin“. All das wissen die Hacker. Also: über den Menüpunkt „Benutzer“ neuen User anlegen mit admin-Rechten und dann den alten User löschen. Über sichere Passwörter referier ich jetzt hier mal nicht.
Login-Versuche limitieren
Mit dem kleinen Plugin Login Lockdown kann man die Loginversuche limitieren. Das hilft dabei Brute-Force-Attacken abzuwehren. Also wenn die Hacker einfach zwei Millionen Wörter/Zahlen/Kombinationen durchzugehen versuchen.
Theme auf Viren untersuchen
Manchmal ist man selber Spammer, weil man ein verseuchtes Theme benutzt. Mit diesem kleinen Plugin einfach mal testen : https://wordpress.org/plugins/antivirus/
Editor deaktivieren
Der Editor ist in WordPress standardmäßig aktiviert, um vom Backend aus die Design- oder die Plugindateien direkt zu bearbeiten. Das kann aber eine potentielle Angriffslücke für Hacker darstellen. Um diese Lücke zu schließen, braucht man lediglich ans Ende seiner wp-config.php diese Zeile eintragen:
define('DISALLOW_FILE_EDIT', true);
Wer sich noch tiefer in die Materie einarbeiten möchte, dem kann ich das exzellente Video von Thomas Brühl empfehlen: Link zum Vortrag
Jetzt haben wir alle Dateien auf dem Webserver und können uns um das Einrichten unserer Seite kümmern. Hierzu rufen wir unsere Webseite auf, auf der wir die WordPress-Dateien hochgeladen haben. Das sollte dann so aussehen (klicken für vergrößern):
Hier könnt ihr eurer Seite einen Titel geben z.B. „Phillip´s Megablog“ oder „Reiseversicherungen für Molwanîen“. Keine Angst, das kann man nachher nochmal ändern.
Dann braucht ihr noch einen Benutzernamen und ein Passwort (schön beides notieren!), eine Mailadresse die ihr abrufen könnt und auf einen Klick ist WordPress installiert! Glückwunsch! Weiter geht´s dann nächste Woche mit dem Einloggen!