Schlagwort-Archiv:

WordPress

Etwas fürs Archiv (1):
Geordnetes Monatsarchiv

Monate und Jahre Der erste von zwei weitereren kleinen WordPress-Tips, diesmal für die Archivseite. Dorthin packt man ja gerne eine Übersicht über alle Beiträge nach Monaten und nach Kategorien, und in einigen Themes steckt so eine Funktionalität bereits drin, einige Plugins bieten ebenfalls diverse Funktionen.

Wie man solche Archive mit Bordmitteln, nämlich der Funtion wp_get_archives() und einer Theme-Template-Seite macht, hat etwa Perun im Januar beschrieben; für das Kategorienarchiv benutze ich diese auch. Für mein Monatsarchiv hab ich aber „natürlich“ eine eigene Funktion geschrieben, die mir eine schönere Darstellung nach Jahren gruppiert bietet – darum geht es in diesem Beitrag. In ein paar Tagen zeige ich euch dann den Code für die Schlagwort-Mehrfachauswahl, die ihr bereits auf der Archivseite findet.

Stellt sich nur generell die Frage, ob allzu viele Besucher diese Archiv-Funktionalität auch wirklich nutzen… aber egal, im Zweifelsfall betrachtet’s man einfach als ein bisschen Blog-Spielerei.^^

In diesem Fall hab ich den PHP-Code direkt in die Seite geschrieben (im HTML-Editor von WordPress) – weshalb auch das <?php...?>-Tag mittendrin steht –, da ich hier eh schon das Plugin Exec-PHP einsetze, das ebendies ermöglicht1. Alternativ kann man den Code natürlich auch anderweitig unterbringen, etwa über entsprechende Unterscheidungen im Theme oder komfortablerweise per Template – siehe Peruns Artikel.

Wie ihr auf dem Bild oben erkennen dürftet, sind hier Monate vor dem Blogbeginn und nach dem aktuellen Datum gar nicht dargestellt und Lücken der Regelmäßigkeit halber grau; zudem – was aber nur eine Stylingfrage ist – gibt’s keine unnötigen ansonsten listentypischen • Bullets und Einrückungen. Und in Klammern steht die Anzahl der Beiträge.

Das ist der Code dazu:

<style type="text/css">
div.yeararch { float: left; color:#777; margin-right: 2em; }
ul.montharch { list-style-type: none; padding-left: 0px; }
</style>

<?php global $wpdb;
$mnames = array (1=>'Januar', 2=>'Februar', 3=>'März', 4=>'April', 5=>'Mai', 6=>'Juni', 7=>'Juli', 8=>'August', 9=>'September', 10=>'Oktober', 11=>'November', 12=>'Dezember');
$started = false;
$years = $wpdb->get_results("SELECT YEAR(post_date) AS year, COUNT(*) AS count
FROM $wpdb->posts
WHERE post_type='post'
  AND post_status='publish'
GROUP BY year
ORDER BY year ASC");
foreach ($years as $y) {
  echo '<div class="yeararch"><h4><a href="/'.$y->year.'/">'.$y->year.'</a> <small>('.$y->count.')</small></h4><ul class="montharch">';
  $months = $wpdb->get_results("SELECT MONTH(post_date) AS month, COUNT(*) AS count
  FROM $wpdb->posts
  WHERE post_type='post'
    AND post_status='publish'
    AND YEAR(post_date)=$y->year
  GROUP BY month
  ORDER BY month ASC");
  $ms = array();
  foreach ($months as $m) { $ms[$m->month] = $m->count; }
  for ($i=1; $i<=12; $i++) {
    $m0 = sprintf('%02d',$i);
    $mname = $mnames[$i];
    if ($ms[$i]>0) {
      echo '<li><a href="/'.$y->year.'/'.$m0.'/">'.$mname.'</a> ('.$ms[$i].')</li>';
      $started = true;
    } else {
      if ($y->year<date('Y') || $i<=date('n')) {
        if (!$started) echo '<li>&nbsp;</li>'; else echo '<li>'.$mname.' (0)</li>';
      }
    }
  }
  echo "</ul></div>\n";
}
?>

<div style="clear:both;"></div>

Großes Hexenwerk ist der Code nicht: Nach der kleinen CSS-Definition (direkt auf der Seite, da ja nur hier benötigt) schaut der PHP-Code erst in der Datenbank nach, welche Jahre denn in Frage kommen – YEAR(post_date) AS year ... GROUP BY year – und nimmt auch die Beitragsanzahl – COUNT(*) AS count gleich mit.

Für jedes Jahr wird dann ein div-Container generiert, die dank des CSS am Anfang nebeneinander stehen – so viele wie halt auf die Seite passen, bei mir geht’s 2011 dann darunter weiter; ihr könnt ja mit den Abständen (margin-right) spielen. (Der div am Ende mit clear:both; sorgt dafür, dass nachfolgender Text darunter und nicht daneben landet.)

Dann gibt’s für jedes Jahr natürlich eine analoge Datenbank-Abfrage für die nach Monaten gruppierten Beiträge des jeweiligen Jahres, die dann nacheinander ausgegeben werden. Da diese Abfrage nur so viele Array-Einträge liefert, wie Monate benutzt wurden, sortiere ich sie ins Array $ms um, um in der Schleife alle Monate von 1 bis 12 durchlaufen und für leere Monate je nachdem, ob das Blog noch gar nicht begonnen wurde (!$started) oder ob es eine Lücke ist, eine Leerzeile bzw. eine nicht verlinkte Zeile mit der traurigen Null ausgeben zu können.

(Die Monatsnamen bekäme man an sich auch eleganter über PHP-Funktionen, aber irgendwie hatte ich da Probleme im Zusammenhang mit meiner Sprachumschaltung, deshalb die Lösung mit dem $mnames-Array.)

Bei den Links zu den Monatsarchivseiten geht der Code davon aus, dass sie dem Schema /2009/12/ folgen – wer ein anderes Schema mit pretty permalinks verwendet (kommt das denn vor?), muss sie entsprechend anpassen, ebenso wer die „unschöne“ Variante mit ? und Argumenten verwendet; das wäre dann ?m=200912 etc.

So, das war der erste Beitrag zum Archiv – wer Fragen, Anregungen, Verbesserungsvorschläge o.ä. hat, möge jetzt sprechen oder für immer schweigen… Wie erwähnt geht’s dann demnächst um die Mehrfachauswahl bei den Schlagwörtern, aber vielleicht schiebe ich auch noch die Einbindung von WP.com-Stats anstelle von WP-PostViews für die Ermittlung der beliebtesten Beiträge dazwischen, wie Robert angeregt hatte. Mal sehen.

  1. Nebenwirkung: Man muss den HTML-Editor von WordPress verwenden, weil der visuelle nicht mehr möglich ist. []

WordPress: Hinweis bei Spam-Falscherkennung

Papierspam ?! Und wieder eine kleine Code-für-das-Blog-Lösung von mir, die zwar nicht unbedingt perfekt ist, aber doch hilfreich sein kann…

Viele sind dem Problem schon begegnet, dass ein Kommentar fälschlicherweise im Spam landet, weil der Spamfilter – sei es das bekannte Akismet (wie bei meinem Blog), sei es ein anderes Plugin oder einfach eine versehentlich zu scharf eingestellte Blacklist – übereifrig ist. Auf meinem Blog kommt so ein false positive im Schnitt alle drei Wochen einmal vor.

Der erfahrene Blogger oder Blogkommentierer weiß, dass er dann i.d.R. einfach darauf warten muss, dass der Blogbetreiber den Kommentar (hoffentlich) herausfischt und freigibt. Der unerfahrenere Kommentierende steht aber nicht selten wie der (Pfingst-)Ochse vor dem Berg, wenn er nach dem Absenden des Kommentars oben auf der Seite landet und auch beim Runterscrollen seinen Kommentar nicht findet; manche versuchen es dann auch erneut, manche kommen vielleicht gar nicht wieder.

Ein Hinweis könnte da helfen – doch WordPress bietet da (anders als bei noch zu moderierenden Kommentaren) keinen. Die normale Schleife, die die Kommentare ausgibt, weiß auch nicht direkt, welcher Kommentar aktuell vom Aufrufenden ist, denn der Teil der URL, in der das steht – #comment-123, was ja insbesondere für die Positionierung der Ansicht im Browser sorgt1 – ist nicht Teil der Anforderung, die der Server sieht, sondern bleibt im Browser.

Nun könnte man vielleicht die Kommentarnummer bei der Weiterleitung nach dem Abschicken auch als &-Parameter in die URL einbauen (und dann in der Ausgabeschleife mit abfragen), doch finde ich das irgendwie unschön – wer weiß, ob dadurch nicht mehrere solche URLs durch die Suchmaschinen geistern. Mir kamen zwei andere Ideen, die ich hier vorstellen will:

Lösung 1: Spam-Kommentar von derselben IP-Adresse?

Die erste Idee: Man schaut nach der Kommentarausgabe nach, ob in den letzten paar Minuten ein Spam-Kommentar von derselben IP-Adresse kam, von der die aktuelle Anfrage kommt. Das sieht dann in einer Funktion für die functions.php des Themes so aus:

function ag_spammed_comment ($gotcomments) {
    global $wpdb, $post;
    $spamcom = $wpdb->get_results ("
        SELECT * FROM $wpdb->comments
        WHERE comment_post_ID = '$post->ID'
          AND comment_author_IP = '".$_SERVER['REMOTE_ADDR']."'
          AND comment_approved = 'spam'
          AND comment_type = ''
          AND TIME_TO_SEC(TIMEDIFF(NOW(),comment_date))<120");
    if ($spamcom) {
        if (!$gotcomments) echo '<ol class="commentlist">';
        foreach ($spamcom as $sc) {
            echo '<li id="comment-'.$sc->comment_ID.'" class="comment caughtasspam">'.
            '<strong>Anscheinend wurde Ihr Kommentar von der Automatik als Spam markiert.</strong><br/>'.
            'Falls das ein Versehen war: bitte etwas Geduld, bis er manuell freigeschaltet wird.'.
            '</li>'."\n";
        }
        if (!$gotcomments) echo '</ol>';
    }
}

Aufzurufen dann in der comments.php mit ag_spammed_comment (true); (in <?php ?> eingeschlossen) nach der Ausgabe der vorhandenen Kommentare und mit false statt true im Zweig für den Fall, dass es noch keine Kommentare gibt – wobei diese Unterscheidung nur nötig ist, wenn man den Hinweis wie einen Kommentar in die ol/ul mit einbinden (und gestalten) will; wer einen separaten div-Block verwenden will, kann sich die Unterscheidung sparen.

Die Klasse .caughtasspam Ist dann natürlich noch in der style.css angemessen (z.B. mit rotem Rahmen) zu formatieren.

Allerdings gibt’s da ein…

Problem: Der Cache

Wer ein Cache-Plugin wie WP Super Cache einsetzt, das die erzeugten Seiten zwischenspeichert, steht dann vor dem Problem, dass dieses – eigentlich sinnvollerweise – den Cache der betroffenen Seite bei einem Spam-Kommentar nicht invalidiert, d.h. noch dieselbe alte Seite ausliefert, ohne dass der Code oben zur Ausführung kommt und seinen Hinweis ausgeben kann.

Eine Lösung dafür: Man ändert das Plugin so, dass Spam-Kommentare (aber nicht Spam-Trackbacks) doch die gecachete Seite löschen. Das geht bei WP Super Cache in wp-cache-phase2.php in der function wp_cache_get_postid_from_comment, wo man nach

} elseif ( $comment['comment_approved'] == 'spam' ) { 

die beiden Zeilen

if ( isset( $GLOBALS[ 'wp_super_cache_debug' ] ) && $GLOBALS[ 'wp_super_cache_debug' ] ) wp_cache_debug( "Spam comment. Don't delete any cache files.", 4 );
return $postid;

durch diese ersetzt:

//--ag: for false-positive message
if ( $comment['comment_type'] == '' ) {
    if ( isset( $GLOBALS[ 'wp_super_cache_debug' ] ) && $GLOBALS[ 'wp_super_cache_debug' ] ) wp_cache_debug( "Spam comment. But update cache for post $postid to allow for false-positive message.", 4 );
    return wp_cache_post_change($postid);
} else {
    if ( isset( $GLOBALS[ 'wp_super_cache_debug' ] ) && $GLOBALS[ 'wp_super_cache_debug' ] ) wp_cache_debug( "Spam trackback. Don't delete any cache files.", 4 );
    return $postid;
}

Dann funktioniert’s auch mit dem Hinweis. Allerdings auf Kosten der Performance, falls zufällig echte Spammer viele Spamkommentare auf eine Seite abzuladen versuchen, die auch häufig von Besuchern aufgerufen wird – was bei den meisten Blogs aber nicht so häufig sein dürfte, denke ich.

Der größere Nachteil ist m.E., dass man ein (weiteres?) Plugin hat, bei dem man bei einem Update aufpassen muss, dass man die Änderungen auch in die neue Version übernimmt. Diesen Aufwand will ich mir sparen, deshalb habe ich hier eine andere Lösung eingebaut:

Lösung 2: JavaScript (mit jQuery)

Diese Lösung funktioniert natürlich nicht, wenn der Kommentator JavaScript deaktiviert hat – ein Nachteil, den ich hier aber in Kauf nehme in der Hoffnung, dass diese Kombination selten genug auftritt – dafür funktioniert sie aber auch, wenn jemand über für jede Anfrage wechselnde Proxy-Server surft.

Hier gibt’s sogar zwei Lösungsvarianten, deren erste ich nur kurz anschneiden will: Man ändert mittels comment_post_redirect-Filter (der von wp-comments-post.php aufgerufen wird) die Ziel-URL so, dass bei einem Spam-Kommentar das #comment-123 durch etwas wie #spammed ersetzt wird, und sorgt dann per JavaScript dafür, dass ein im Theme eingebauter, anfangs auf display: none gesetzter (oder leerer) Hinweisblock eingeblendet (oder mit dem Hinweistext gefüllt) wird, wenn #spammed in der URL vorkommt – denn anders als der Server hat JavaScript auf diesen Teil Zugriff.

Variante 2, die auch hier eingebaut ist, kommt ohne einen solchen Filter aus und schaut einfach nach, ob es ein Element namens #comment-123 auf der (vollständig geladenen) Seite überhaupt gibt. Wenn nicht, wird der Hinweistext eingefügt (durch JavaScript deswegen, damit Suchmaschinen den Hinweis nicht indizieren):

<div id="spammedhint" class="comment caughtasspam" style="display:none;"></div>
<script type="text/javascript">
<!--
var theUrl = document.location.toString();
if (theUrl.match("#comment-")) {
    var theHash = theUrl.substr(theUrl.indexOf("#"));
    if (jQuery(theHash).length==0) {
        jQuery(document).ready(function() {
            jQuery("#spammedhint").html("<strong>Anscheinend wurde Dein Kommentar von der Automatik als Spam markiert.</strong><br/>"+
            "Falls das ein Versehen war: bitte etwas Geduld, bis er manuell freigeschaltet wird.").fadeIn();
            var targetOfs = jQuery("#spammedhint").offset().top;
            jQuery("html,body").animate({scrollTop: targetOfs-20}, 500);
        });
    }
}
//-->
</script>

Die Frage der Existenz wird mit if (jQuery(theHash).length==0) abgefragt, da jQuery() immer ein Objekt zurückliefert und ein ansonsten naheliegendes if (jQuery(theHash)) immer wahr ist. Mit der letzten jQuery-Zeile wird dann innerhalb 500 ms zum Hinweisblock gescrollt (bzw. knapp drüber); mit einer ganz kurzen Zeit gab’s manchmal Probleme, weil das document irgendwie doch noch nicht ganz ready war und der Browser dann an eine andere Stelle zurücksprang. (Kann aber sein, dass das nur beim Neuladen einer Seite, wie man’s beim Testen nunmal macht, passiert.)

Ich habe diesen HTML/JS-Code direkt (und natürlich nicht in <?php ?> eingeschlossen) in die comments.php eingefügt (also nicht in die functions.php ausgelagert), und zwar direkt nach <?php if ('open' == $post->comment_status) : ?> und damit direkt vor die Ausgabe der Eingabefelder.

Auch hier sollte man die Klasse .caughtasspam dann natürlich noch in der style.css angemessen formatieren.

Nun hat auch diese Methode einen Nebeneffekt, der sowohl unerwünschterweise (aber wohl sehr selten) auftritt, wenn jemand irgendwoher einen falschen Link mit einer nicht existierenden bzw. unsinnigen Kommentarnummer hat, als auch erwünschterweise, wenn jemand den Link mit seinem erstmal durchgegangenen Kommentar gebookmarkt hat und dieser nachträglich in den Spameimer geworfen wird, denn dann wird dieser Hinweis auch ausgegeben.

Was es euch auch ermöglicht, diese Funktion einfach zu testen – ich habe hier einen Link für euch vorbereitet. :) Ihr könnt aber auch einen neuen Kommentar schreiben und dort „diesisteinspamtest“ einfügen, dieses Wortkonglomerat hab ich für ebendiesen Zweck auf die Blacklist gesetzt. Aber übertreibt’s nicht, ich muss die schließlich alle freischalten…

Wer kein Cache-Plugin verwendet, kann also die erste Lösung gut verwenden, andernfalls gilt es eben Vor- und Nachteile abzuwägen; ich habe mich wie gesagt für die JavaScript-Lösung entschieden.

Meinungen, Kritik, Anregungen, Probleme, Fragen…?

  1. wer ein fehlerhaftes Theme hat, das diese ID für die Kommentare nicht erzeugt und somit alle Kommentatoren nach dem Kommentieren am Seitenanfang landen, sollte das jetzt endlich auch reparieren… []

Beliebteste Beiträge

Ich weiß nicht, ob’s jemand schon bemerkt hat^^, aber seit letzter Woche findet sich in meiner Sidebar ein Abschnitt mit den beliebtesten Beiträgen, und wie das bei mir so üblich ist, bemühe ich da nicht groß ein Plugin, sondern hab das selber gebastelt. Und da es vielleicht den einen oder anderen auch interessieren könnte, gibt’s diesen Beitrag… Verbesserungsvorschläge sind natürlich willkommen.

Die Frage war also: Welche Kriterien sollen für die Beliebtheit gelten, und wie krieg ich das mit einer Datenbankabfrage hin? Die Kriterien, an die ich gedacht habe, sind:

  • Aufrufzahlen der Beiträge, gezählt mit WP-PostViews1;
  • Anzahl der Kommentare;
  • Länge der Kommentare2 – kurze à la „toller Beitrag“ weniger stark gewichten;
  • Alter der Beiträge – neue Beiträge mit vielen Aufrufen oder Kommentaren sollen bevorzugt werden – bzw. Aufrufe pro Tag.

Wer ein Plugin zur Beitragsbewertung einsetzt, mag dessen Werte natürlich auch noch mit einschließen; entsprechendes gilt für ein anderes Statistik-Plugin als WP-PostViews. Und natürlich gibt’s auch etliche „Popular Posts“-Plugins, doch die wenigsten davon berücksichtigen mehr als die Kommentaranzahl – und eine maßgeschneiderte Lösung ist mir eben auch lieber…

Generell stellt sich noch die Frage nach der Gewichtung – wenn bei euch fast jeder Besucher kommentiert, müsst ihr die Kommentaranzahl nicht deutlich stärker als die Aufrufe gewichten, und man kann natürlich eigene Schwerpunkte setzen. Und man muss die einzelnen Kriterien auch nicht einfach mit einem Faktor addieren, sondern kann etwa alle anderen durch das Alter teilen u.v.a.m. Meine Gewichtung seht ihr unten im/nach dem Code.

Nun könnte man dazu mehrere Datenbankabfragen machen, die alle der Post-ID, also der eindeutigen Nummer eines Beitrags, ihren jeweiligen Wert zuordnen, und diese Arrays dann mittels PHP verrechnen und gewichten – ich hab’s hingegen in eine einzige MySQL-Abfrage gequetscht (war auch ’ne kleine Übung in Sachen MySQL… und ist sicher nicht perfekt…); mag sein, dass einzelne Abfragen schneller wären, aber nach etwas Optimierung hatte ich meine Query so weit, dass sie nicht viel länger dauert als das „Einsammeln“ der Kommentarlängen (die bei >10000 Kommentaren/Trackbacks schon ein bisschen dauert), und vermutlich geht’s nicht viel schneller – konkret: von ca. 1½ auf 0,3 Sekunden.

(Aus der Zeit vor der Optimierung stammt auch die kleine Cache-Funktionalität, die ihr gleich im Code seht; bei Verwendung eines Datenbank-Caches oder Verlassen auf den Query Cache der Datenbank selbst wäre die auch weniger wichtig.)

Hier also der Code3:

function ag_popular_posts($num=10) {
    global $wpdb;
    $lastupdate = (int) get_option("ag_popular_lastupdate",0);
    $output = '';
    if (time()-$lastupdate > 1800) {
        $exclude = "
            AND ID NOT IN (78,70)
            AND ID NOT IN (
                SELECT object_id FROM $wpdb->term_relationships
                WHERE $wpdb->term_relationships.term_taxonomy_id IN (92,384)
            )"
;
        $posts = $wpdb->get_results("
            SELECT ID,post_date,post_title,post_name,comment_count,
                $wpdb->postmeta.meta_value AS views,
                TO_DAYS(NOW())-TO_DAYS(post_date) AS age,
                comment_length,
                ($wpdb->postmeta.meta_value/2
                 +comment_count*50
                 +comment_length/comment_count*5
                 +(TO_DAYS(post_date)-TO_DAYS('2006-09-06'))*5) AS popularity
            FROM $wpdb->posts,$wpdb->postmeta,(
                SELECT comment_post_id, SUM(LENGTH(comment_content)) AS comment_length
                FROM $wpdb->comments
                WHERE comment_approved='1'
                GROUP BY comment_post_id) AS thecomm
            WHERE $wpdb->posts.ID = $wpdb->postmeta.post_id
            AND $wpdb->posts.ID = thecomm.comment_post_id
            AND $wpdb->postmeta.meta_key = 'views'
            AND comment_count > 0
            AND post_status = 'publish'
            AND post_type = 'post'
            AND post_password = ''
            $exclude
            ORDER BY popularity DESC, post_date
            LIMIT $num"
);
        if ($posts) {
            $output="<ul>";
            $pop0=0;
            foreach ($posts as $p) {
                if ($pop0==0) $pop0=$p->popularity;
                $output.='<li><a href="'.get_permalink($p->ID).'" title="'.
                        $p->comment_count.' Kommentare mit durchschnittlich '.
                        ($p->comment_count==0?'0':number_format($p->comment_length/$p->comment_count,1)).' Zeichen, '.
                        number_format($p->views).'x aufgerufen, '.
                        number_format($p->age).' Tage alt'.
                    '">'.
                    $p->post_title."</a> ".
                    "<small>(".number_format($p->popularity/$pop0*100,0).'%'.")</small>".
                    "</li>\n";
            }
            $output.="</ul>\n";
        }
        update_option("ag_popular_lastupdate",time());
        update_option("ag_popular_cached",$output);
    } else {
        $output = get_option("ag_popular_cached",'');
    }
    if ($output!='') {
        echo "<li id=\"side-popular\">\n".
            "<h2>Beliebteste Beitr&auml;ge</h2>\n".
            $output.
            "</li>\n";
    }
}
 

Also gehen wir den Code mal durch:

Wir beginnen mit der Abfrage, ob die Liste aktualisiert werden soll – das Intervall liegt hier bei 1800 Sekunden, also einer halben Stunde.

Um bestimmte Beiträge auszuschließen, kann man ihre ID wie in der ersten Zeile des ausgelagerten $exclude-Statements angeben – bei mir ist es 78 = die Liste der Musik-Zitate, die aufgrund ihrer hohen Abrufzahlen unangefochten an Platz 1 wäre, aber nicht so interessant ist, dass ich sie hier in der Beliebtheitsliste hervorheben möchte, und die 70 = die damalige Technorati4-Ketten-Aktion, die nur bei manchen Gewichtungsversuchen in der Top 10 wäre –, oder alternativ z.B. auch post_name.

Eine ganze Kategorie oder ein ganzes Tag kann man mit dem zweiten AND ID NOT IN-Statement ausschließen. Dazu muss man die term_taxonomy_id der/des fraglichen Kategorie/Tag herausfinden – indem man in der Tabelle wp_terms anhand des Namens die term_id findet und mit dieser in wp_term_taxonomy nachschlägt (oder irgendwelche WP-Funktionen verwendet, mit get_term_by() könnt’s vielleicht gehen) – und am Ende einsetzen; bei mir will ich alle Quiz-Beiträge (92) und nur englische (384) ausschließen (bzw. in englischer Ansicht alle deutschen, da steht dann 385).

Weiter geht’s mit der eigentlichen SELECT-Abfrage. In deren ersten vier Zeilen stehen ein paar für die Ausgabe benötigte Angaben, danach in Klammern (...) AS popularity der eigentliche Beliebtheitswert.

Wie ihr (vielleicht) seht, gewichte ich die Seitenaufrufe mit 0,5, die Kommentaranzahl mit 50, die durchschnittliche Kommentarlänge ebenso wie die Neuheit des Beitrags (Tage seit Blog-Start, was ihr für euch natürlich ändern müsst, siehe gelb hinterlegtes Datum – wenn ihr stattdessen das Alter, also die Tage zwischen Beitrag und heute, verwenden wollt, nehmt TO_DAYS(NOW())-TO_DAYS(post_date)) mit 5, was sich nach etwas Herumspielen als recht passend für mein Blog gezeigt hat.

(Die kurz darüber deklarierten Felder (AS views, AS age) kann man hier übrigens nicht mit den neuen Namen nehmen, da meckert MySQL – also eben nochmal komplett einsetzen.)

Die FROM-Zeile enthält neben der wp_posts-Tabelle noch wp_postmeta, weil dort die Aufrufzahlen von WP-PostViews liegen – braucht ihr nicht, wenn ihr diese Werte nicht verwendet – und das untergeordnete SELECT für die Kommentarlänge, genauer: die Summe der Länge aller Kommentare mit derselben post_id (inkl. Trackbacks; diese könnte man mit AND comment_type='' vor GROUP ausschließen).

Die WHERE– und die erste AND-Zeile verknüpfen die beteiligten Tabellen über die Post-ID, die nächste wählt die WP-PostViews-Werte aus (die eben „views“ heißen) und der Rest beschränkt das ganze auf geeignete Beiträge.

Danach wird die Ausgabe zusammengebastelt, insb. in der foreach-Schleife, die über die Beiträge läuft, wo der Link samt Tooltip (title) mit statistischen Infos und einem Prozentwert der Beliebtheit mit 100% für den 1. Platz zusammengeklebt wird.

Wenn diese Ausgabe zusammengeklöppelt ist, wird sie noch schnell in die Datenbank für unseren kleinen Cache geschrieben, von wo aus sie (im else-Zweig) innerhalb der nächsten halben Stunde gelesen wird. Und zu guter Letzt muss das ganze natürlich noch (mit Überschrift) ausgegeben werden.

So, das war jetzt jede Menge Code. Wer Verständnis- oder sonstige Fragen, Anmerkungen, Stellungnahmen, Lob, Kritik, Verbesserungsvorschläge, Beleidigungen, Ideen oder Anregungen hat, nur raus damit – Moment, auf eine dieser Arten von Äußerungen solltet ihr besser verzichten.^^

 

  1. mit dem Nachteil, dass ich dieses anfangs alle Zugriffe inkl. Suchmaschinen zählen ließ, aber seitdem ich auch WP Super Cache nutze nur mittels JavaScript – wodurch die Zähler mittlerweile weit weniger stark steigen… []
  2. auf Anregung von Julia, dankeschön []
  3. ich hoffe, ich hab beim Wieder-Entfernen meiner Sprachumschaltung keinen Fehler eingebaut… []
  4. Berners-Lee hab es selig []

Links und Video der Woche (2010/11)

(Hier war etwas als Flash-Objekt eingebunden. Nicht mehr zeitgemäß.)

Projekt 42: Salz

Projekt 42 Wieder ein neues Thema im Projekt 42, bei dem die Teilnehmer einen Text zu einem vorgegebenen, meist mehrdeutigen Wort – diesmal „Salz“ – schreiben sollen.

Da ich keine Suppe essen wollte, um extra darin Salz zu finden, lasse ich mir bei WordPress online welches generieren:

define('AUTH_KEY',        '91-Q@_{1Ksl*AUQ^N9J|~Z?FeU-SKl+v[Q@yGwU9-+s#/ +&)k$<S/$6/SphQN[l');
define('SECURE_AUTH_KEY', '|LRQ]fldP|lF--/U)[bza9%Q98:L_g9uy?]x{BgkV-4/%^}QHra=mjnv-c,Hrb0G');
define('LOGGED_IN_KEY',   'XhLa=<#GpF_[h;Wv;X<|@R,|$Iy9mT;1pu;-4-`Vd_MtJKne9S@b|]T&URZb4$()');
define('NONCE_KEY',       'qNLi~Q{M00<xl futIl9.hO#~>2Q~/f||GxR$Bbg;j+8.@Y4^oA<K%f{tb~lhZTS');

Sieht nicht allzu lecker aus, oder? Soll es auch nicht sein – denn solche hashing salts sollen das Knacken von Informationen, in diesem Fall in WordPress und seinen Cookies, erschweren, gewissermaßen den Hacker-Kiddies die Suppe versalzen. (Ihr habt doch hoffentlich eure eigenen Salze in eurer wp-config.php…?) Wikipedia meint:

Salt (engl. „Salz“) bezeichnet in der Kryptographie eine zufällig gewählte Bitfolge, die an einen gegebenen Klartext vor der Verwendung als Eingabe einer Hashfunktion angehängt wird, um die Entropie der Eingabe zu erhöhen.

Aber ich wäre nicht ich, wenn ich in diese ASCII-Salzkörner nicht noch spaßeshalber Informationen hineindeuten würde. :mrgreen: Hätte Nostradamus damals schon solche kryptographischen Methoden verwendet, seine unverständlichen Prophezeiungen wären endlich verständlich geworden, so nach dem Motto: unverständlich mal unverständlich ergibt verständlich. Daraus folgt natürlich, streng wissenschaftlich, dass dieser WordPress-Generator ebenfalls große Geheimnisse der Vergangenheit und Zukunft prophezeit.

Also, was sagen uns diese Keys nun? AUTH_KEY ist nur für Autofahrer interessant, denen ihre Karre Probleme macht, was sie zum Stöhnen bringt – daher Authhhh… Die Zeichen verraten uns, dass insbesondere den Neunaugen („AUQ^N9“) nahestehende Kryptozoologen („1Ks“=X=unbekannt) vorsichtig sein müssen, wenn sie Ski („SKl“) von Viquaigwug („v[Q@yGwU9“, wo auch immer das liegen mag) zur Sphinx („SphQN[l“) transportieren wollen.

Bei sicheren Autos – SECURE_AUTH_KEY –, also wohl solchen mit Panzerglasscheiben u.ä., wie sie hochrangige Politiker benutzen, muss insbesondere die FDP („fldP“) aufpassen, wenn ihr Außenminister nach Laurie River (Kanada) fliegen (IATA-Flughafencode „LRQ“) und dorthin 9 Kerle („g9uy“) unbezahlt („U)[bza“) mitnehmen sollte. Der Rest dürfte einige Namen dieser Begleiter prophezeien: Big K.V., Q. Hara, M.J.Novac, Herbog…

Gefängnisinsaßen oder andere Eingeschlossene wird der LOGGED_IN_KEY interessieren, aber aus Sicherheitsgründen kann ich diesen hier nicht öffentlich deuten.

Und natürlich kann in diesen Tagen auch die Kirche nicht aus dem Spiel bleiben, auch wenn Nonnen, die Zielgruppe des NONCE_KEY, dabei eher unterrepräsentiert sind. Benötigt wird dieser Prophezeiung nach jedenfalls ein Kimono („Q{M00“) in Größen bis L („<xl“) – wird das die neue Mode der Nonnentracht? Zwecklos („futIl9“, futile) ist es jedenfalls, H0-Modellbahngleise („hO#“) zu zwei Kühen („~>2Q“) zu fliegen („f||G“), vor allem von Remscheid („RS“) nach Böblingen („Bbg“). Dafür kennen wir jetzt den Namen des Nachfolgers (oder der nächsten Ausbaustufe) des Teilchenbeschleunigers („tb“) LHC, nämlich „lhZTS“. Was das wohl heißen könnte? Zero Time Singularity? Endlich die von allen Weltuntergangsfreunden heiß ersehnten Schwarzen Löcher? Heißa!