WordPress 3.7

Die aktualisierung einer handvoll blogs auf wördpress 3.7 verlief erfreulich problemlos — trotz eines gewissen plackin-apparates und… im falle einiger seits… eher obskurer kleiner häcks.

Aber muss dieses moppelchen… moment mal… *tackertacker*

ich@server $ du -hs wordpress
18M     wordpress
ich@server $ find wordpress -name '*.js' | wc -l
265
ich@server $ find wordpress -name '*.js' | xargs cat | wc -l
42276

…18 mebibyte kohd haben, nur damit man den nächsten beitrag schreiben kann? Bedarf es dafür 42276 zeilen javascript in 265 javascript-dateien? Das ganze ding ist einfach nur krank, und es wird mit jeder neuen versjon ein bisschen kranker.

Na ja, wenigstens werden die wichtigsten JS-biblioteken nicht über guhgell eingebunden, sondern lokal gehostet… 😉

WordPress.com bastelt…

…und wenn an wördpress gebastelt wird, dann gibt eigentlich immer ein paar fehler. Im moment funkzjoniert die anzeige der letzten kommentare in der seitenleiste nur, wenn man bei WP.com angemeldet ist. Ich vermute, dass die entwickler da etwas vergeigt haben, als sie den „widgets“ eine zusätzliche einstellung für bedingte sichtbarkeit gegeben haben.

Leider hat man hier bei WP.com immer wieder einmal das „vergnügen“, teil eines großen betatests zu sein, und anders als vor kurzem, als es blogs mit alten deseins völlig zerschossen hat, ist es diesmal ein eher harmloser fehler. Bis die vorherige grundfunkzjon wiederhergestellt ist — es kann sich nur um zwei oder drei tage handeln — kann ich nur eines empfehlen, um eine übersicht der letzten kommentare zu erhalten: Den RSS-fiehd für die kommentare mit irgendwas (mäjhlprogramm, dynamische lesezeichen im brauser, spezielles programm, webdienst) zu abonnieren.

Auch weiterhin viel spaß mit wördpress, dem windohs fürs web!

Korrigiertes blah-archiv zum daunlohd

Meine erste versjon des archivs vom blah-blog hatte leider den nachteil, dass die interne navigation wegen einiger sonderzeichen in dateinamen mit meikrosoft windohs nicht funkzjonierte. Dieses problem habe ich (endlich) gefixt, eine korrigierte versjon des archivs kann heruntergeladen werden.

Es handelte sich übrigens um eine frische, neue wördpress-„eigenart“.

Ich fertige so ein archiv an, indem ich…

  1. …das blog lokal aufsetze, also im SQL-dump der datenbank den domainnamen gegen den lokalen pfad im websörver ersetze und das blog im lokalen websörver betreibe,
  2. …lokal das desein anpasse, um alles zu entfernen, was in einer archiv-versjon sinnlos wäre, und schließlich, indem ich
  3. …dieses lokale blog einmal mit wget spiegele und wget die ganzen absolut gesetzten links in relativ gesetzte links verwandeln lasse — ein vorgang, der wegen des abrufs jeder einzelnen ansicht eines blogs ziemlich lange dauert, vor allem bei schlagwort-reichen blogs wie dem blahblog.

Technische anmerkung — Wer es noch nie gemerkt hat: wördpress verwendet ausschließlich absolute links, was beim umzug eines blogs oder beim anlegen eines archives immer wieder probleme macht. Das hat einen grund: die pfade der blogansichten im websörver sind frei konfigurierbar, und die beiträge stehen in HTML in der datenbank und werden einfach in die generierten seiten geschaufelt. Würden dabei relative links verwendet, müsste wördpress alle links anpassen, damit ein link auf absolut /2011/09/13/test/ sowohl aus der startseite, als auch in der schlagwort-ansicht unter /tag/test/page/3/, als auch in der jahresansicht unter /2011/page/19/ als auch in diversen anderen ansichten eines blogs funktioniert. Wenn man nur über dieses problem nachdenkt, bekommt man schnell kopfschmerzen — wördpress ist hier, wie so oft, einen pragmatischen weg gegangen, der schnell und einfach zum ziel führt. Und, wie so oft bei wördpress, führt dieser pragmatismus manchmal zu problemen…

Der beschriebene wget-krampf ist eine möglichkeit, die probleme beim anlegen eines archives zu lösen. Am ende habe ich dann ein zwar ziemlich redundantes, aber navigierbares archiv eines wördpress-blogs in form von statischen HTML-dateien für jede blog-ansicht. Und das mit erfreulich wenig aufwand, einfach, indem ich vorhandene mittel benutze…

Dieses verfahren, das ich vorher schon einige male durchgezogen habe, hat beim blahblog allerdings nicht funkzjoniert. Und ich stand vor einem rätsel. Wget war zwar so „freundlich“, alle dateien abzuholen, aber die dateinamen verlinkter dateien wurden geändert, nachdem sie heruntergeladen wurden.

Ich bin einfach nicht darauf gekommen, was das für ein verdammtes Problem war.

Nun, wenn man nicht mehr weiterweiß oder nicht mehr weiterkommt, ist — nach ein paar tagen abstand — immer ein guter moment gekommen, auch mal die dokumentazjon zu lesen. In der wget-dokumentation fand ich die info, dass wget nicht nur den gewöhnlichen links folgt, sondern auch in die HTML-kopfzeilen nach <link>-angaben schaut.

Tja, und dieses verkackte wördpress schreibt seit ein paar versjonen unter anderem folgendes in die kopfzeilen jeder einzelnen generierten datei:

<link rel="shortlink" href="startseite-des-blogs?p=4711" />

Wget ist daraufhin so „nett“, die datei umzubenennen und erzeugt mit einen dateinamen mit einem fragezeichen, der probleme bereitet… 😦

Und ich suche und suche und suche nach dem fehler… 😦

Nun gut, man kann wördpress dieses verhalten zum glück abgewöhnen. 🙂

Der einfachste weg ist es, die folgende zeile in die functions.php des verwendeten deseins aufzunehmen:

remove_action ("wp_head", "wp_shortlink_wp_head", 10, 0);

Ich hoffe, dass dieser kleine hinweis anderen hilft, die gerade gegen die gleiche scheiße kämpfen — die idee, ein archiv eines blogs in statischen HTML-seiten anzulegen, ist ja durchaus naheliegend.

Übrigens…

In diesem monat waren bislang 31964, also rd. 6,2 prozent der insgesamt 513492 zugriffe auf „unser täglich spam“ sichere häckversuche. Sehr lustig finde ich das automatisierte vorgehen der skripten, die unter ein paar standardpfaden nach einem nicht weiter gesicherten phpmyadmin suchen, weniger lustig sind leider die wörterbuchattacken auf die passwörter, weil sie doch ein bisschen last verursachen. Erstaunlich, dass „unser täglich spam“ trotzdem recht rund läuft, wenn nicht gerade jemand den DoS probt. 😉