Wordpress
WordPress-Anleitungen: Updates, Permalinks, Multisite, WP-CLI und Performance-Optimierung.
-
WordPress automatisch aktualisieren mit WP-CLI und Cron
Veraltete WordPress-Installationen, Plugins und Themes sind das häufigste Einfallstor für Angriffe auf Websites. Mit WP-CLI und einem einfachen Bash-Script lassen sich alle Updates automatisieren – und der Server übernimmt die lästige Wartungsarbeit selbst, ohne manuelle Eingriffe. WP-CLI installieren WP-CLI ist das offizielle Kommandozeilenwerkzeug für WordPress. Die Installation ist einfach: Auf Servern mit mehreren PHP-Versionen (z.B. Plesk) muss der richtige PHP-Interpreter angegeben werden: Das Update-Script Ein kompaktes Bash-Script, das alle WordPress-Komponenten in der richtigen Reihenfolge aktualisiert: Script ausführbar machen und testen Automatische Ausführung per Cron Den Cron-Job anlegen, der das Script wöchentlich ausführt – beispielsweise jeden Dienstag um 03:00 Uhr morgens: Folgende Zeile einfügen: Mehrere WordPress-Instanzen verwalten Auf Servern mit mehreren…
-
W3 Total Cache: Browser Decode Errors durch doppeltes Gzip beheben
Sporadische Browser Decode Errors nach der W3 Total Cache-Installation deuten oft nicht auf einen W3TC-Fehler hin – sondern auf doppelte Gzip-Komprimierung. Der Browser empfängt zweifach komprimierte Daten, scheitert beim Entpacken und zeigt eine Fehlermeldung. Hier ist die Diagnose und der Fix. Das Symptom Besucher sehen sporadisch eine Fehlermeldung wie: Das Verhalten ist intermittierend – manchmal lädt die Seite normal, manchmal schlägt sie fehl. Das ist ein typisches Zeichen für Race Conditions oder inkonsistente Cache-Zustände, wie sie bei doppelter Komprimierung entstehen können. Die Ursache: Doppelte Gzip-Komprimierung W3 Total Cache kann HTML, CSS und JavaScript gzip-komprimieren, bevor es sie im Cache ablegt. Wenn der Webserver (Nginx oder Apache) zusätzlich Gzip-Komprimierung aktiviert hat,…
-
RSS-Feed funktioniert nicht – XML Parsing Error beheben
Ein häufiges WordPress-Problem: Der RSS-Feed wirft einen XML Parsing Error und ist für Feed-Reader und Aggregatoren unbrauchbar. Meist steckt eine unsichtbare Leerzeile am Anfang der Ausgabe dahinter – verursacht durch einen falschen Zeilenumbruch in einer Konfigurationsdatei. Das Symptom Beim Aufruf des RSS-Feeds im Browser erscheint eine Fehlermeldung wie: Oder in englischsprachigen Browsern: Das Problem: XML verlangt, dass das Dokument exakt mit <?xml beginnt. Steht davor irgendein Zeichen – auch ein unsichtbarer Zeilenumbruch oder Whitespace – ist das Dokument für Parser ungültig. Die Ursache: Leerzeile in wp-config.php In WordPress-Multisite-Installationen enthält die wp-config.php einen besonderen Abschnitt mit Multisite-Konfiguration. Wenn nach dem schließenden ?>-PHP-Tag (oder nach dem letzten Code-Block ohne PHP-Closing-Tag) ein Zeilenumbruch…
-
WordPress auf Ubuntu: Apache-Konfiguration für saubere Permalinks
Wer WordPress auf einem Ubuntu-Server mit Apache betreibt, stößt häufig auf ein Problem: Die sauberen Permalink-Strukturen wie /beitragsname/ funktionieren nicht – stattdessen erscheinen nur die Standard-URLs mit ?p=123. Die Ursache liegt fast immer in einer fehlerhaften Apache-Konfiguration, die mod_rewrite nicht zulässt. Das Problem: AllowOverride None Standardmäßig setzt Ubuntu bei Apache-Installationen AllowOverride None im Virtual-Host. Das bedeutet: Die .htaccess-Datei von WordPress wird komplett ignoriert – und damit auch alle Rewrite-Regeln, die WordPress für seine Permalink-Struktur benötigt. Lösung: AllowOverride All setzen Die Konfiguration in der Apache-Site-Datei (z.B. /etc/apache2/sites-available/wordpress.conf) muss entsprechend angepasst werden: mod_rewrite aktivieren Neben der Konfigurationsänderung muss auch das Apache-Modul mod_rewrite aktiviert sein: Vollständige Virtual-Host-Konfiguration für WordPress Hier eine vollständige, produktionsreife…
-
WordPress multisite password reset fix
to fix the issue with the wrong URLs http://www.site2.com forgot password links to http://www.site1.com/wp-login.php?action=lostpassword and not http://www.site2.com/wp-login.php?action=lostpassword the fix is: you change on the most lines network_site_url -> site_url wp-includes/general-template.php function wp_lostpassword_url( $redirect = '' ) { $args = array( 'action' => 'lostpassword' ); if ( !empty($redirect) ) { $args['redirect_to'] = $redirect; } $lostpassword_url = add_query_arg( $args, network_site_url('wp-login.php', 'login') ); return apply_filters( 'lostpassword_url', $lostpassword_url, $redirect ); } should be function wp_lostpassword_url( $redirect = '' ) { $args = array( 'action' => 'lostpassword' ); if ( !empty($redirect) ) { $args['redirect_to'] = $redirect; } $lostpassword_url = add_query_arg( $args, site_url('wp-login.php', 'login') ); return apply_filters( 'lostpassword_url', $lostpassword_url, $redirect ); } Also WordPress is generating the…
-
Speeding Up WordPress on Synology
Out of the box, WordPress running on a Synology is very slow (search Synology.com forums or Google if you don’t believe me). This article explains how to optimize your Synology and your WordPress website for speed. Disclaimer The below are tweaks I’ve implemented with success. I don’t know the complete extent of their validity; they just seems to bring extremely noticeable positive performance gains to my Synology. Besides these changes not working as expected on your Synology, they are risky. Before making any changes, backup your data and your Synology configuration off the Synology incase the worst happens. By implementing any of the suggestions below, you are proceeding at your own…
-
WordPress 4 Upgrade Probleme – wp-admin läuft langsam
Nach einem Upgrade auf WordPress 4 kann der Adminbereich plötzlich extrem langsam werden. Der Grund liegt meist nicht im WordPress-Core selbst, sondern in der Art, wie der Server externe Domains auflöst – und der Fix ist einfacher als erwartet. Das Problem: wp-admin reagiert kaum Nach dem Update auf WordPress 4 berichten viele Administratoren, dass das Dashboard und alle Admin-Seiten nur noch im Schneckentempo laden. Seitenaufrufe, die vorher unter einer Sekunde lagen, dauern plötzlich 10–30 Sekunden. Das Backend ist kaum noch bedienbar, während das Frontend für Besucher oft normal schnell bleibt. Die Ursache: WordPress 4 führte intern mehr HTTP-Anfragen aus als seine Vorgänger – unter anderem für Lizenzchecks, Update-Prüfungen und API-Calls…












