<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
<?php the_content(); ?>
 
 <?php endwhile; else: ?>
 <p><?php _e('Verzeihung, aber was Sie suchen, ist nicht hier.'); ?></p>
 <?php endif; ?>

Benutzt man WordPress mehr als Content-Management-System (CMS) und weniger als Weblog, hat man häufig eine statische Seite als Startseite gewählt. Möchte man auf dieser Seite dann den aktuellsten Beitrag aus der ersten Kategorie veröffentlichen, könnte man folgenden Loop auf der statischen Seite unterbringen:

<?php query_posts('cat=1&showposts=1'); ?>
<?php while(have_posts()) : the_post(); ?>
<p id="post-<?php the_ID(); ?>"><strong><?php the_title(); ?></strong>
<?php the_content(); ?>
</p>
 
<?php endwhile; ?>

Damit PHP-Code innerhalb einer statischen Seite oder eines Artikels funktioniert, muss allerdings das Exec-PHP-Plugin installiert sein. Nun hat man das Problem, das WordPress diese beiden Loops nicht unterscheiden kann und sie daher zweimal ausführt. Wenn also, wie im Beispiel, der aktuellste Artikel auf der Seite stehen soll, wird er einmal vom Loop in der Datei index.php und einmal vom Loop in der statischen Seite ausgegeben. Das heißt, der selbe Artikel erscheint zweimal auf dieser Seite.

Die Lösung in diesem Fall heißt, dass man ein neues Query-Objekt erstellt:

 
<?php
$myQuery = new WP_Query('showposts=1&cat=3');
while ($myQuery->have_posts()) : $myQuery->the_post();
?>
<p id="post-<?php the_ID(); ?>"><strong><?php the_title(); ?></strong>
<?php the_content(); ?>
</p>
<?php endwhile; ?>

Die Funktion WP_Query dient zum Auffinden verschiedenster Beiträge in der Datenbank und kann analog zu Query_posts verwendet werden. Damit kann man kontrollieren, welche Beiträge in einem Loop angezeigt werden und beide Loops voneinander unterscheiden.

Meinen Planeten habe ich so ähnlich realisiert, wie es Dunkelangst in seinem Blog beschreibt. Neben dem Plugin FeedWordPress habe ich ebenfalls die Plugins SimplePie Core und SimplePie for WordPress installiert. Außerdem braucht man die Plugins Evermore und Auto Delete Posts. Ersteres schneidet zu lange Beiträge ab (was ich aber zur Zeit noch deaktiviert habe), letzteres löscht alle Posts aus der Datenbank, die älter als eine bestimmte Anzahl an Tagen sind. Schließlich will ich diese Blogs ja nicht archivieren.

Ursprünglich hatte ich vor, den Planeten in meine bestehende WordPress-Installation zu integrieren, und die Beiträge aus dem Planeten in einem gesonderten Loop anzeigen zu lassen. Das war mir aber zu aufwendig. Also habe ich einfach ein neues Weblog aufgesetzt und das angepasste Theme kopiert. Dadurch konnte ich auch einstellen, dass der Planet nicht von Suchmaschinen besucht wird. Die ganze Werbung habe ich übrigens herausgenommen, damit sich niemand gestört fühlt.

An meinem Theme wird sich erstmal nicht besonders viel ändern, da ich damit recht zufrieden bin. Besonders die Grafik von Nina mit der Dame wird noch lange ganz oben in meinem Weblog sein.

Ansonsten kann ich mich nur Christophs Worten anschließen: Sollte jemand meinen Feed abonniert, ein Bookmark gesetzt, oder mein Blog verlinkt haben (vielen Dank dafür), so ändert bitte die URL in daten|teiler.de (auch dafür vielen Dank), obwohl mein Blog weiter unter der Adresse imhorst.net erreichbar sein wird. Als Logo könnt ihr dafür gerne das Bild mit der Dame verwenden. Nina hat ihre Bilder unter einer Creative Commons-Lizenz lizenziert.

Ein paar Änderungen an WPtouch kann man in WordPress unter den Einstellungen vornehmen, um zum Beispiel ein eigenes Menü mit zusätzlichen Seiten wie Impressum, About, Suche und so weiter zu erstellen, oder welche Icons angezeigt werden sollen.

Der besondere Vorteil von WPtouch ist, dass der Besucher meines Blogs einfach mit einem Schalter ganz unten auf der Seite zum eigentlichen Theme meines Weblogs wechseln kann, wenn im das WPtouch-Theme nicht gefällt.

Vier davon habe ich getestet: Preserve Code Fromatting, WP-Syntax, Code Autoescape und Code Markup. Preserve Code Formatting hatte Probleme mit dem Backslash, so wird “\0″ nicht dargestellt. Bei den anderen Plugins hatte ich Probleme mit den größer oder kleiner Zeichen: “<" oder ">“. Bei Beispielen mit C++-Quellcode wurde die Zeile #include <iostream> nur halb dargestellt, nämlich nur #include. Entweder wurde die Zeile in den Artikeln oder in den Kommentaren falsch dargestellt. Beides zusammen hat nicht funktioniert.

Gelöst habe ich das Ganze nun folgendermaßen: Das Plugin Code Markup habe ich für die Darstellung von Quellcode in den Artikeln installiert, die von <code>-Tags umgeben sind. Für größere Code-Blöcke nehme ich WP Syntax und schließe sie in <pre>-Tags mit Sprachattribut, z.B. <pre lang=”cpp”> ein. Allerdings funktionieren beide Plugins nicht in den Kommentaren. Dafür musste ich noch Code Auto Escape installieren, was sich aber wieder auf die Quellcode-Beispiele in den Artikeln ausgewirkt hat. Anstelle der Sonderzeichen wurden die ASCII-Werte dargestellt. Dafür wurde aber der Quellcode in den Kommentaren richtig angezeigt. Deshalb habe ich Code Auto Escape so umgebaut, dass es nur bei den Kommentaren greift, indem ich den Code-Block von

add_filter('content_save_pre', 'pri_cae_mask', 28);

bis

add_filter('the_excerpt', 'pri_cae_unmask_replace', 99);

mit Kommentarzeichen versehen habe. Man kann den ganzen Block auch einfach löschen. Jetzt reicht es, Quellcode-Beispiele in den Kommentaren mit den <code>-Tags zu umschließen, um den Code richtig anzeigen zu lassen.

• Das Plugin live-comment-preview.php herunterladen.
• Die Datei live-comment-preview.php ins Verzeichnis wp-content/plugins hochladen.
• Das Plugin in WordPress aktivieren.

Die erste Stolperfalle taucht auf, wenn man nicht das Standardtheme oder eine Variante davon benutzt. Dann muss man noch im Theme-Editor die Datei comments.php bearbeiten, in dem man folgende Zeilen einfügt:

<?php do_action('comment_form', $post-&#062;ID); ?>
<?php live_preview(); ?>

Die Kommentar-Vorschau funktioniert nun schon recht gut. Allerdings wird der Kommentar-Text nicht angezeigt, wenn man die Felder für E-Mail und Website ausfüllt. Die Lösung für diese Stolperfalle weiß Martin Hömmerich. Die Funktion hex_md5, die von dem Plugin benötigt wird, ist keine Standardfunktion und muss separat in die Datei header.php eingebunden werden:

<title>MeinBlog</title>
<script type="text/javascript" src="Pfad/md5.js"></script&>

Wenn man diese beiden Punkte beachtet hat man in kurzer Zeit eine Kommentar-Vorschau, die von vielen Kommentatoren sehr geschätzt wird.

Update: Wie Christoph weiter unten zu recht schreibt, braucht Live Comment Preview ganz schön viele Ressourcen. Daher habe ich Filosofo Comments Preview installiert. Ajax Comment Preview habe ich nicht genommen, weil es mit meinem Dirtylicious-Theme nicht zusammenarbeiten wollte. Einfach das Archiv filosofo-comments-preview.zip herunterladen, entpacken und die Datei filosofo-comments-preview.php in das Verzeichnis wp-content/plugins hochladen und in WordPress aktivieren. Die Hintergrundfarbe des Plugins kann unter “Einstellungen -> Comments Preview” eingestellt werden.

Der zweite Artikel berichtet über den Leitfaden zur Impressumspflicht herausgegeben vom Bundesjustizministerium. Mit dem Leitfaden will das Ministerium Abmahnungen vermeiden und mehr Rechtssicherheit schaffen. Allerdings soll er nur als Orientierungshilfe dienen, rechtsverbindlich ist er leider nicht. Trotzdem eine Pflichtlektüre für Menschen, die im Internet veröffentlichen.

function istZahl(Feld)
  {
  istZeichen(Feld, "0123456789", "Bitte nur Zahlen eingeben.")
  }
 
function istZeichen(Feld, istRichtig, istFehler)
  {
  for (var Pos = 0; Pos < Feld.value.length; Pos++)
    {
    if (istRichtig.indexOf(Feld.value.charAt(Pos)) == -1)
      {
      alert(istFehler)
      Feld.focus()
      return;
      }
    }
  }

JavaScript wird in WordPress-Postings aber nicht automatisch ausgeführt, da das Script nicht im HTML-Header der Seite steht. Jetzt könnte man zwar das Script in der Datei “header.php” eintragen, dann wäre es aber auch in all den anderen Seiten im Weblog verfügbar, in denen man es vielleicht nicht haben möchte. Mit folgender Methode von Frank Bültge kann man den Code auch in Postings verwenden.
Als erstes muss das Script als Datei, z.B. “formularchecker.js”, abgespeichert werden. Mit der Upload-Funktion von WordPress kann man die Datei dann hochladen und in das Posting einfügen:

<script type="text/javascript" src="/Pfad/zu/formularchecker.js"></script>
<form>
   <input type="text" name="Zahlen" size="30" maxlength="30" 
     onblur="istZahl(this)" />
   <input type="reset" value="Check" />
</form>

Das fertige Produkt kann unten bewundert werden. Wenn man eine Zahl eingibt, wird der Inhalt des Formularfeldes zurückgesetzt. Bei allen anderen Zeichen erscheint eine Fehlermeldung.

Zum Beispiel habe ich in diesem Posting folgendes Formular eingebunden:

<form action="Dokument.php" method="post">
<input type="text" size="17" name="Inhalt">
<input type="submit" value="Abschicken">
</form>

Der Inhalt der Variable “Inhalt” wird an das PHP-Skript “Dokument.php” übergeben, das im Wurzelverzeichnis der Homepage liegt.

<?php
define("FPDF_FONTPATH","fpdf/font/");
require("fpdf/fpdf.php");
 
$pdf=new FPDF();
$pdf->AddPage();
$pdf->SetFont('Arial','B',16);
$pdf->Cell(40,10,$Inhalt);
$pdf->Output();
?>

An den Zeilen, die mit “define” und “require” beginnen, kann man sehen, dass die Datei “fpdf.php” bei mit im Unterordner “fpdf” liegt. Zum Testen kommt nun hier das Beispiel:

Neben den Aufräumarbeiten und Umgestaltungen an der Sidebar habe ich noch das Formmailer-Plugin für WordPress von Dagon Design besorgt. Eine deutsche Anleitung dafür findet man im Weblog von Texto.de. Natürlich habe ich das PHP-Skript im Plugin-Editor noch ein wenig an meine Bedürfnisse angepasst, aber hauptsächlich folgenden Eintrag geändert:

Content-Type: text/plain; charset="iso-8859-1"

Damit Umlaute in der E-Mail korrekt dargestellt werden können, muss anstelle von iso-8859-1 die am weitesten verbreitete Kodierung für Unicode-Zeichen eingefügt werden: utf-8.

Schließlich habe ich bei meiner WordPress-Installation noch ein Upgrade auf die Version 2.3.3 durchgeführt.