Schlagwort-Archive: Wordpress

Software

[Gentoo] Apache 2.4.26 + WordPress: Invalid post type

4 Kommentare

Hmk? After the latest system updates on Gentoo I noticed WordPress was no longer able to open any kind of post list („invalid post type“), edit posts (you do not have access to this kind of post) or create posts (form shown, but right sidebar missing). Not quite uncommon, but this time it was no broken plugin – I could reproduce the same behavior with several other WordPress instances with different versions – even a fresh install. That’s a new one.

After some probing around I’m fairly certain Apache 2.4.26 is the culprit, after downgrading to 2.4.25 the problem disappeared. All other downgrades like PHP 7.0.15 instead of PHP 7.0.19 didn’t show any effect. I yet have to confirm which combination ultimately triggers the error (FPM? Event-MPM?), but if you have similar errors: Here is your starting point…

Software

Lahmendes WordPress – eine Ursachensuche…

Schreibe einen Kommentar

Wer in den letzten Wochen auf meinem Blog unterwegs war hat es eventuell gemerkt: Irgendwie war das Ganze etwas zäh. Jeder Aufruf dauerte mindestens 5 Sekunden – nur warum?

Also gehen wir die große Frage an: Was ist der Auslöser. Frage einfach, Antwort kompliziert. Erster Anlaufpunkt: das Netz. Um zu prüfen, dass das Problem wirklich am Server und nicht am Netzwerk liegt wird die Seite lokal aufgerufen:

time wget -O - https://adlerweb.info/ > /dev/null 
[…]
real	0m5.488s
[…]

Danke, keine weiteren Fragen, am Netz liegt es nicht. Wenn wir aber schon mal da sind rufen wir auch einen statischen Inhalt auf – nehmen wir z.B. einfach mal ein Bild:

time wget -O - https://adlerweb.info/blog/wp-content/uploads/2014/05/header-2014.png > /dev/null
[…]
real	0m0.017s
[…]

Aha – der statische Aufruf funktioniert zügig, damit wäre ein Fehler des Webservers selbst eher unwahrscheinlich. Der PHP-Interpreter oder die Anwendung scheint also Auslöser zu sein. Testen wir mal eine „rohe“ PHP-Datei. Reines echo.

time wget -O - https://adlerweb.info/test.php > /dev/null
[…]
real	0m0.007s
[…]

Somit wäre auch der PHP-Interpreter raus – es kann also eigentlich nur noch WordPress sein, oder? Nunja, ein reines WordPress auf selbem Server ist da anderer Meinung:

time wget -O - https://adlerweb.info/wptest/ > /dev/null
[…]
real	0m0.895s
[…]

Deutlich langsamer als der Testcode, aber es sind ja auch ein paar Zeilen mehr – eine Sekunde ist aber imo noch erträglich. Also muss irgendwas in der Seite den Fehler verursachen – Plugins, Themes, Anpassungen. Viele Kandidaten.

Erster Versacht: Meine Solarstatistiken. Diese müssen sich erst durch meinen heimischen Anschluss quetschen und der ist nicht gerade der schnellste. Statistik aus, aber trotzden: 4.925s. Kein Wunder: Es sind ja nur wenige Zeichen Text und spätestens beim zweiten Aufruf wären sie im Cache des Servers. Also weiter geht die Deaktivierungsorgie, aber mit Nachbrenner.

Um herauszufinden ob ein Plugin oder sonstiger Code das Problem verursacht wandern alle Plugins temporär aus dem WordPress-Ordner in ein temporäres Verzeichnis. Bingo: Ohne Plugins lädt die Seite in gerade mal 0.265s – suchen wir den Schuldigen. Plugin für Plugin wird dieser eingerichtet, dabei stechen einige hervor:

– apc: +1,2 Sekunden
– wp-slimstat +0,3 Sekunden

APC war früher als Cache im Einsatz, heute ist das Plugin im Backend deaktiviert, aber durch einen damals nötigen Symlink werden offenbar trotzdem Teile des Plugins geladen. Die Ladezeit steigt dabei offenbar mit der Codegröße – wenn mehr andere Plugins geladen sind erhöht sich die Ladezeit mit APC prozentual. Wie schon gesagt: Historie – kurze Sache: Weg damit.

WP-Slimstat ist ebenfalls etwas auffällig, wenngleich weit entfernt von der Bremswirkung des vorherigen Kandidaten. Slimstat sah mir nach einer guten Idee aus – der Webserver anonymisiert bereits die IPs, entsprechend kann ich hiermit lokale & anonyme Statistiken generieren. Den Performance-Impact hatte ich mir allerdings nicht ganz so groß vorgestellt, als Alternative hat sich jetzt WordPress Statistics von Mostafa Soufi eingefunden – mit diesem Plugin kann ich keien messbare Verschlechterung feststellen.

Ergebnis des Frühjahrsputzes (a2b, 100 Requests, 10 Parallel):

Vorher:				Ohne APC:			Andere Stats

100 Requests			100 Requests			100 Requests
146.809 seconds			24.047 seconds			14.385 seconds
6282600 bytes			6282600 bytes			6240100 bytes
42.08 Kbytes/sec		256.91 Kbytes/sec		426.60 Kbytes/sec
===================		==================		==================
1468.093 ms/Request		240.471 ms/Request		143.846 ms/Request
0.68 Requests/sec		4.16 Requests/sec		6.95 Requests/sec

Durch löschen des alten Plugins konnte die Ladezeit um 83% gesenkt werden – mit neuem Statistikplugin waren sogar weitere 7% Reduktion möglich. Ein zehntel der Ladezeit – nicht schlecht für eine eigentlich so kleine Ursache…

Wir lernen: Man sollte öfter mal aufräumen, nicht mehr verwendete Plugins auch aus dem Dateisystem entfernen und Plugins vor der Nutzung vergleichen…

PC-Kram

Neues Theme im Blog

Schreibe einen Kommentar

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/05/altesdesign-288×300.png

Auch wenn mir das Design der „alten“ Seite gut gefiel: Der Autor hatte schon vor Jahren die Entwicklung aufgegeben und ich bin nicht tief genug in WordPress verwurzelt um jeden Patch auf ein vollständig eigenes Theme umzubiegen. Die Lösung heißt „twentyfourteen“ – naja, fast. Über ein paar CSS-Hacks habe ich zumindest einige mit gefallende Stilelemente retten können. Derzeit machen noch einige Seiten wie z.B. die Gallery Probleme, aber auch das wird sich wohl irgendwie ausbügeln lassen. Immerhin bin ich jetzt wieder auf einem halbwegs modernen Stand, der sich zur Abwechslung auch auf dem Handy gut lesen lässt.

Software

WordPress, HTTPs optional und die SEO-Leute

Schreibe einen Kommentar

OK, Zertifikate erneuert, dann auch noch „schnell mal“ HTTPs im Blog einschalten. Oder auch nicht…

Ich habe bereits seit langem den Adminbereich meines Blogs über HTTPS eingebunden, hierzu ist lediglich ein einfaches

define('FORCE_SSL_ADMIN', true);

in der wp-config.php notwendig. Den Blog selbst hatte ich seinerzeit auf HTTP gelassen, denn nicht jeder hat die von mir verwendete Zertifizierungsstelle CACert installiert was zu unschönen Warnungen führen würde. Optional wäre toll, aber damals zeigte sich schnell, dass die SEO-Funktionen von WordPress aus dieser einfachen Sache mal wieder eine lange Geschichte machen. Anstatt Anfragen einfach zu verarbeiten wird zur Optimierung der Suchmaschinenplatzierung alles unbekannte auf die konfigurierte Hauptadresse umgeleitet – incl. dem für WordPress unbekannten https://….

Im Netz findet man häufig kleine Codefragmente, welche in der wp-config.php die interenen Adressen bei HTTPS-Zugriffen umbiegen sollen. In meinem Fall biss sich diese Methode leider mit dem verwendeten Cache-Plugins. Fündig geworden bin ich im Plugin „WP-SSL„. Über wenige Filter werden die Adressen direkt über die API ersetzt. Da so auch die Cacher entsprechende Ausgaben erhalten ist auch der parallele Einsatz kein Problem. Das Plugin ist für mich eher Vorlage als Fertiglösung gewesen – einige Zeilen für alternative URLs und Plugins musste ich ergänzen, aber generell ist die Methode praktisch und schnell zu verstehen.

Rekonfiguration erfolgreich – somit ist diese Seite jetzt auch offiziell (auf Wunsch) per HTTPS erreichbar – selbstverständlich auch mit PFS und paranoiden Schlüssellängen, auch wenn es wohl für einen einfachen Blog nicht wirklich etwas zur Sache tut ;).

Anm: Offenbar gibt es doch noch den ein oder anderen Client (IE auf WinXP, Android 2.3), welche noch kein SNI unterstützen – für die heißt es: „Sorry, aber ohne Update geht’s nur ohne“…

Software

WordPress: Kategorien aus RSS-Feed ausschließen

Schreibe einen Kommentar

Dank eines Hinweises von Jakob fand ich noch ein Problem auf dieser Seite, welches mit reclaim.fm zusammen hängt. Ich spiele (fast) alle meine Social-Media-Inhalte auch im Blog ein. Da sie in eigenen Kategorien landen lässt sich das Ganze recht einfach filtern: Alles aus dieser Ecke wird nicht als Blogpost angezeigt – dachte ich. Leider landeten die Einträge weiterhin im RSS-Feed, was natürlich nicht Sinn der Sache war.

Um die Änderungen halbwegs konsistent zu behalten sollte das Ganze vorzugsweise im Theme eingebracht werden. Dank web-kreation.com war der fehlende Tipp schnell ergoogled. Mit einer kleinen Änderung werden die Kategorien nur ausgeblendet wenn keine anderen Filter aktiv sind, so sollte imo nur der Hauptfeed von den Ausnahmen betroffen sein.

Hier der Code, welcher in die functions.php des Themes eingebracht werden muss:

function filter_social_rss($query) {
  if ($query->is_feed && $query->get('cat') == '' && $query->get('tag') == '') {
    $query->set('cat','-240,-241,-178,-242');
  }
  return $query;
}

add_filter('pre_get_posts','filter_social_rss');
Netzkultur

Überlegungen zu Reclaim.fm

Schreibe einen Kommentar

Vor einigen Tagen hat Sascha Lobo in seinem Überraschungsvortrag auf der re:publica 2013 seine Strategie zur Rückeroberung der Netzdaten präsentiert: Mir Reclaim.fm möchte er dafür sorgen, dass die Blogs und Webseiten der Internetnutzer wieder aus ihrem Winterschlaf erwachen. Keine so schlechte Idee: Viele Daten liegen heute in der Cloud und diese ist – wie nicht zuletzt einige Ausfälle in letzter Zeit erneut bewiesen haben – nicht unfehlbar. Ich selbst bin nicht so tief in der Cloud versunken wie manch anderer: Die Inhalte wichtiger Twitter-Erkenntnisse finden sich in Blog-Posts wieder, viele YouTube-Videos stehen auch über meinen Server zum Download bereit, aber einige Sachen verschwinden auch in den Tiefen des Netzes.

Der erste Ansatz, welcher auf der Projektseite explizit als Entwicklerschnellschuss beschrieben wird, ist technisch zwar deutlich verbesserungswürdig, das Konzept ist aber vielversprechend: Statt eigener Systeme zu entwickeln setzt man auf Standards: Youtube-Videos, Facebook-Posts, Tweets – alles wird durch separate „Proxy-Scripts“ verarbeitet und am Ende als RSS ausgegeben. Da dieses Feed-Format weit verbreitet ist sind die Inhalte so über so ziemlich jeden Newsreader nutzbar. Unter anderem besteht so auch die Möglichkeit per Blog-Syndication (z.B. FeedWordPress für WordPress-Blogs) die Inhalte auf die eigene Webseite zu duplizieren.

Auch wenn die Scripte noch in einem frühen Stadium stecken: Das Grundkonzept funktioniert. Auch bei mir landen jetzt Inhalte aus verschiedenen Netzen in einer (auf der Startseite versteckten) Blog-Kategorie, jedoch ist noch ein weiter weg zu gehen: Bilder und Video werden so z.B. derzeit nur auf die Cloud-Dienste verlinkt, hier sollte besser eine lokale Kopie erfolgen um die Inhalte wirklich dauerhaft zu sichern. Auch hoffe ich, dass mit den ersten Versionen eine bessere Versionsverwaltung folgt: Momentan gibt es die Scripte nur als ZIP-Datei, kein GIT-Repository oder ähnliches – Patches erstellen ist somit nur schwer möglich.

Ein Anfang ist immerhin gemacht – ich hoffe, dass viele mitziehen und ihre Daten zukünftig nicht einfach nur großen Unternehmen schenken sondern selbst nutzen und dabei vorzugsweise auf freie Formate und Protokolle setzen, denn wie sich an der Nachricht über das Abhören von Skype zeigt sind die Warnungen der Verfechter von XMPP, PGP & Co nicht zwingend durch Verfolgungswahn entstanden.

Saffig

Neue Webseite für Saffig

Schreibe einen Kommentar

Bild: http://saffig.de/wp-content/uploads/Homepageteam-300×199.jpgZeit wurde es: Die 2007(?) erstellte Webseite meines Heimatortes passte Designtechnisch nicht mehr ganz in die heutige Zeit und auch das in die Jahre gekommene Joomla verhieß nichts Gutes (korrekterweise, denn kurz vorm Umschalttermin zerlegte sich die Originalseite). Offenbar nicht meine Meinung, denn seitens der Ortsgemeinde kam die Anfrage, ob ich nicht helfen könne – vermutlich nicht zuletzt da ich bereits bei einigen Vereinen die Finger im Spiel hatte. Bei den ersten Gesprächen stellte sich schnell heraus, dass das Hauptaugenmerk auf der Bedienbarkeit liegen sollte. Joomla ist zwar kein textbasierter HTML-Editor, jedoch benötigt man doch etwas Einarbeitung um die Funktionen korrekt nutzen zu können. Nun, bei wenigen Änderungen im Monat keine besonders gute Zeitanlage. Nachdem ich mir einige aktuelle CMSsen angeschaut habe landete ich doch wieder bei meinem Standard: WordPress hat dank seiner Herkunft eine sehr einfache und auch für außenstehende geeignete Verwaltungsoberfläche, kann auch ohne Kenntnis von FTP & Co aktualisiert werden und stellt dennnoch einen für die meisten Punkte ausreichenden Funktionsumfang zur Verfügung. Die alten Inhalte übernahm ich „händisch“ per Copy&Paste, so konnte ich auch gleich die Designsünden in Form von übermäßigen <table>s eliminieren. Auch an anderer Stelle freut sich mein Techniker-Ich: Die bisherige Textseite mit Nachrichten wird über die Artikel-Funktion abgewickelt, die ebenfalls textliche Terminliste steckt nun im Plugin AjaxEventCalendar, welches auch gleich einen iCal-Feed drangeflanscht bekam. Dank HTML5/CSS3 skaliert das Design auch passabel bis auf Handys runter, hier habe ich lediglich im CSS die <li>-Bullets aktiviert, sodass die verschachtelte Menüstruktur auch Mobil erkennbar bleibt. Viele weitere Änderungen hatte ich ja bereits gebloggt.

Ich denke, dass die Umstellung ganz gut funktionierte. Bei der Vorstellung kam überweigend positives Feedback und trotz einfacherer Bedienung sollten die Inhalte technisch sauberer bleiben und so auch ein gewisses Maß an Barriere- und damit auch Technikerfreiheit bieten.

www.saffig.de

 

 

Software

„SECURITY VIOLATION“ nach Gallery2-Update

Schreibe einen Kommentar

Offenbar hatte sich beim letzten WordPress-Update klammheimlich meine Gallery-Integration zerlegt – zwar lief hier noch alles wie gewohnt, allerdings wurden die Kurz-URLs nicht korrekt aufgelöst. Schuld war eine (manuelle) Änderung der .htaccess-Datei, die für etwas Chaos sorgte. Während der Fehlerbehebung ist mir aufgefallen, dass meine Gallery nicht ganz auf dem neuesten Stand ist. Zwar verzichte ich noch immer Absichtlich auf Gallery3, jedoch hatte ich offenbar ein XSS-Fix für den 2er-Zweig verpennt. Das Update lief fehlerfrei, jedoch wurden anschließend im Blog keine Bilder mehr angezeigt. Versuchte ich das Bild direkt zu öffnen wurde eine HTML-Seite mit der G2-Fehlermeldung „SECURITY VIOLATION“ gezeigt. Nachdem ich einige Zeit in der falschen Richtung suchte fand sich das Problem bei den Plugins: Meine Fotos werden mit einer Watermark versehen, dass zuständige Plugin war jedoch nach dem Update nicht mehr aktiviert und sorgte bei externen Aufrufen für den Fehler.

Software

WordPress / TwentyTwelve: Home umbenennen

Schreibe einen Kommentar

WordPress zeigt bei Verwendung einiger Themes (z.B. Twentytwelve) in der Navigation immer auch die Startseite an, nutzt hierbei jedoch nicht den Seitennamen sondern immer die Bezeichnung „Home“. Um dies zu ändern muss man etwas tiefer im System graben: In der Datei wp-content/languages/de_DE.po findet sich eine passende MsgID, der zugehörige Text eine Zeile drunter. Eine Änderung könnte z.B. so aussehen:

…
#: wp-includes/post-template.php:899
msgid "Home"
msgstr "Startseite"
…

Da WordPress auf Gettext setzt muss die PO-Datei noch kompiliert werden. Dies geschieht auf *nix-Systemen z.B. mit

msgfmt -o de_DE.mo de_DE.po

Windowsnutzende Cloudfanatiker können natürlich auch ein entsprechendes Onlinetool benutzen ;).

Stand heute (WordPress 3.5.1 von WPDE) gibt es z.T. Probleme mit der mitgeliferten PO:

de_DE.po:2104: `msgid‘ and `msgstr‘ entries do not both end with ‚\n‘
msgfmt: found 1 fatal error

In diesem Fall im Editor die genannte Zeile öffnen und am Ende der Übersetzung (msgstr) die Newline (\n) löschen.