Archiv des Autors: admin

preg_replace & Co. im praktischen Einsatz

Ich bin immer noch an den exportierten Posts aus WordPress, die wir im Q&D-Editor schonmal manuell nachbearbeitet haben. Dabei sind sicher etliche Dinge aufgefallen, die man programmatisch korrigieren könnte, und wie man das praktisch angeht, schreib ich hier mal auf.

Wir haben immer noch die Ausgangstabelle rezepte, in der nur die ID, der post_content und der post_title drinstehen. Damit wir unsere Rohdaten nicht verhunzen, legen wir uns erstmal eine leere Kopie dieser Tabelle an, das geht im phpmyadmin unter „Operationen“, kopiere Tabelle, nur Struktur, oder mit dem simplen SQL:

CREATE TABLE rezepte_arbeit LIKE rezepte

Das kopiert die Struktur inklusive evtl. vorhandener Indizes etc. und wird unser Arbeitspferd. (Falls man mal die Daten mitkopieren möchte, CREATE TABLE table2 SELECT * FROM table1, aber das nur als Anmerkung am Rande)

Zur Kontrolle des Ergebnisses klemmt man sich die (noch leere) Arbeitstabelle in den Q&D-Editor. Spätestens jetzt macht es Sinn, den Namen der Tabelle auf eine Variable zu legen und die beiden SQLs entsprechend anzupassen.

//Arbeitstabelle festlegen
$arbeitstabelle = "arbeit_rezepte";
echo "<h1>Tabelle: ".$arbeitstabelle."</h1>";
...
$sql = "SELECT * FROM ".$arbeitstabelle." WHERE post_content LIKE '%".$filter."%'";
...
$sql = ('SELECT * FROM '.$arbeitstabelle.' WHERE post_content LIKE "%'.$filter.'%" 
LIMIT '.$limit.', '.$ergebnisse_pro_seite.'');

Wer es ganz genau haben möchte, legt auch noch den Dateinamen des Q&D-Editor Skripts auf eine Variable und paßt die Navigationslinks entsprechend an, aber das ist eigentlich schon Fleißarbeit:

//Dateinamen auf Variable legen
$datei = "arbeitspferd.php";
...
if($limit>0){echo '<a href="'.$datei.'?seite_nr='.($limit-1).'"><button type="button">Voriger Datensatz</button></a>';}
echo '<a href="'.$datei.'?seite_nr='.($limit+2).'"><button type="button">Nächster Datensatz</button></a><br>';
...
 //Nav Links alle Seiten
 for ($i=1; $i<=$row_total; $i++) { 
    echo "<a href='".$datei."?seite_nr=".$i."'>".$i."</a> "; 
};

Da die Tabelle noch leer ist, kriegt man erstmal gar nichts angezeigt:

arbeitstabelle_leer

arbeitstabelle_leer

Aber das ist ja OK so und wird sich gleich ändern.

Das Gerüst für die geplanten Aktionen

Ich bastle mir ein kleines Formular mit einem Button zum Starten des Skripts, und gebe der Übersicht halber mal alle Datensätze tabellarisch aus. Das sieht so aus:

<?php
//file:skript_starten.php
header('Content-Type: text/html; charset=utf-8');
require 'connection.php';

//Quell-und Zieltabelle festlegen
$quelltabelle = "rezepte";
$zieltabelle = "arbeit_rezepte";

echo "<h1>Skript starten</h1>";
echo "<h2> Quelle: ".$quelltabelle." Ziel: ".$zieltabelle."</h2>";

//Formular mit Button für Start
echo "<form action ='#' method = 'post'>";
echo "<input type = 'submit' name = 'absenden' value = 'Skript starten'>";
echo "</form>";

if(isset($_POST['absenden'])){
    
    echo "<script type=\"text/javascript\">alert('Skript gestartet');</script>";
    
    //Hier kommt die Action hin
    
    
    }

$sql = "SELECT * FROM ".$quelltabelle."";
$rs_result = $conn->query($sql);
$row_total = $rs_result->num_rows;

echo "Datensätze gesamt: ".$row_total."<br>";

 //Ausgabe in Tabelle - nur Arbeitsversion, kann man für den Betrieb rausnehmen
echo "<table border='1' cellpadding='4'>";
echo "<tr><th>ID</th><th>Titel</th><th>Content</th></tr>";
 
 while($row = $rs_result->fetch_assoc()) {
            
            echo "<tr><td valign='top'>".$row["ID"]."</td>";
            echo "<td valign='top'>".utf8_encode($row["post_title"])."</td>";
            //HTML Source in Textarea ausgeben
            echo "<td valign='top'><textarea rows='5' cols='80'>".utf8_encode($row["post_content"])."</textarea>";
            echo "</td></tr>";
            
 } //Ende von while row = rs_result
 
 echo "</table>";
 
?>

Ich hole mir mit dem require die Connection, lege Quell-Und Zieltabelle auf Variable und baue mir den Button für das Starten des Skripts. Die Kontrollausgabe der aktuellen Quelltabelle ist nicht unbedingt notwendig, das dient nur der Übersicht.

Jetzt gehts zur Sache

Der Ablauf ist folgender: die Datensätze aus der Quelltabelle werden selektiert und die Felder auf Variablen gelegt. An den Variablen nimmt man dann die nötigen Manipulationen vor, und die fertig bearbeiteten Datenfelder werden in ein Array geschrieben. Aus dem Array füllt man dann mit Insert die Zieltabelle. Das Ergebnis kann man dann gleich mal im Q&D-Editor überprüfen. Ich mach dann gleich noch ein Beispiel, hier zuerst mal der Source:

if(isset($_POST['absenden'])){
    
    echo "<script type=\"text/javascript\">alert('Skript gestartet');</script>";
    
    //Hier kommt die Action hin
    
    $sql = "SELECT * FROM ".$quelltabelle."";
    $rs_result = $conn->query($sql);
    
      
    $i=0;
    $temp = array();
    
    while($row = $rs_result->fetch_assoc()) {
            
            $akt_id =$row["ID"];
            $title = $row["post_title"];
            $content = $row["post_content"];
            
            // Hier kann man beliebige Stringfunktionen auf die Felder anwenden
            $content = strip_tags($content);
            
            //Behandelte Strings in Array einlesen
            $temp[$i][id] = $akt_id;
            $temp[$i][titel] = $title;
            $temp[$i][content]= $content;
            $i = $i+1;
            
    }
            
 }
$len_temp = count($temp);

//Array zeilenweise in Zieltabelle wegschreiben
for ($i = 0; $i < $len_temp; $i++){    
  
          $temp_id = $temp[$i][id];
          $temp_titel = $temp[$i][titel];
          $temp_content = $temp[$i][content];
          
          //addslashes ist nötig weil sonst der Insert bei jedem Hochkomma aussteigt
          $sql_insert = "INSERT INTO ".$zieltabelle." (ID, post_title, post_content) 
          VALUES (".$temp_id." ,'".addslashes($temp_titel)."' , '".addslashes($temp_content)."')";
          
          if (mysqli_query($conn, $sql_insert)) {
                      echo "Insert erfolgreich<br>";
                      
                    }
                      
                    else {
                      echo "Fehler beim Update: " . mysqli_error($conn);
                      
                    }
} // end for

Das wars schon – das Skript braucht ein paar Sekunden, nicht ungeduldig werden. Wichtig ist, dass man die einzufügenden Felder beim Insert noch mit einem addslashes() behandelt, weil sonst bei jedem Anführungszeichen im Text das Skript aussteigt.

Ich habe oben nur eine Ersetzung ausgeführt, nämlich das:

$content = strip_tags($content);

Das führt in der Praxis evtl. zu unerwünschten Effekten, weil es wirklich gnadenlos alle HTML-Tags raushaut. Für meine Zwecke besser geeignet ist der strip_tags mit Ausnahmen:

$content = strip_tags($content,'<h2>, <h3>, <ol>, <ul>, <li>');

Das läßt meine Überschriften und die Listen drin, sieht schon besser aus.

mit_liste

mit_liste

Aber da muss jeder selber tüfteln, was für seine Zwecke am besten geeignet ist. Fröhliches googlen nach praktikablen Stringbehandlungen! Und nicht vergessen vor erneutem Starten des Skripts die Zieltabelle mit Truncate zu leeren, sonst fällt der Insert wegen doppelter IDs auf die Nase.

Nachtrag: den Truncate kann man natürlich auch ins Skript mit einbauen, einfach die Action um folgenden Code ergänzen:

//Zieltabelle leeren
    $sql_zap="TRUNCATE TABLE ".$zieltabelle."";
    if (mysqli_query($conn, $sql_zap)) {
                      echo "Truncate erfolgreich<br>";
                      
                    }
                      
                    else {
                      echo "Fehler beim Truncate: " . mysqli_error($conn);
                      
                    }

Das muss natürlich vor dem Insert rein, am Besten setzt man es ganz an den Anfang innerhalb der if(isset($_POST…)-Bedingung. Dann spart man sich das manuelle Leeren der Zieltabelle.

Quick&Dirty Editor Sourcecode

Der Editor kommt mit erstaunlich wenig Code aus, das sind gerade mal knapp 90 Zeilen. Ich gehe das hier mal der Reihe nach durch. Meine Ausgangstabelle heißt rezepte und sieht so aus:

ausgangstabelle

ausgangstabelle

Sie enthält nur die rudimentären Daten meiner Rezepte aus dem Inselfisch-Kochbuch, und zwar die ID, den post_content und den post_title.

tabelle_rezepte

tabelle_rezepte

Wir ändern nur den post_content, Titel und ID bleiben unangetastet.

Zuerst bastle ich mir natürlich die Datenbankconnection:

<?php
//file:connection.php
error_reporting(0);
$servername = "localhost";
$username = "root";
$password = "";
$dbname = "conversion";

 
// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn->connect_error) {
    die("Connection failed: " . $conn->connect_error);
} else {echo "Datenbank Connection OK<br>";}
?>

Die wird per require reingeholt, und dann kanns losgehen. Ich habe hier den Algorithmus aus der nummerischen Pagination zweckentfremdet und lasse mir pro Seite genau einen Datensatz anzeigen.

<?php
//file:seitenweise.php
header('Content-Type: text/html; charset=utf-8');
require 'connection.php';


$sql = "SELECT * FROM rezepte";
$rs_result = $conn->query($sql);
$row_total = $rs_result->num_rows;
$gesamte_anzahl = $row_total;

echo "Datensätze gesamt: ".$row_total."<br>";

/* 1 Datensatz pro Seite festlegen*/
$ergebnisse_pro_seite = 1;
$gesamt_seiten = ceil($gesamte_anzahl/$ergebnisse_pro_seite);

if (empty($_GET['seite_nr'])) {
    $seite = 1;
} else {
    $seite = $_GET['seite_nr'];
    if ($seite > $gesamt_seiten) {
        $seite = 1;
    }
}

$limit = ($seite*$ergebnisse_pro_seite)-$ergebnisse_pro_seite;
if($limit<0){$limit =0;}

Zuerst zähle ich die Datensätze, dann lege ich fest, dass pro Seite genau ein Datensatz angezeigt werden soll. Defaultmässig landet der Editor bei Seite 1. Dann berechne ich mir das Limit, also beim wievielten Datensatz die Ausgabe beginnen soll. Das verwenden wir gleich mal für die Navigationsbuttons „Voriger Datensatz“ und „Nächster Datensatz“:

//Debug-Ausgaben und Nav-Buttons
echo "Datensatz = ".($limit+1)." von ".$row_total."<br>";
echo "Datensätze pro Seite = ".$ergebnisse_pro_seite."<br>";
if($limit>0){echo '<a href="seitenweise.php?seite_nr='.($limit-1).'" style="font-weight: bold;"><button type="button">Voriger Datensatz</button></a>';}
echo '<a href="seitenweise.php?seite_nr='.($limit+2).'" style="font-weight: bold;"><button type="button">Nächster Datensatz</button></a><br>';

Dann hole ich mir auch schon den Datensatz mit der aktuellen Seitennummer:

//Selektiere Datensatz mit der aktuellen Seitennummer
$sql = ('SELECT * FROM rezepte LIMIT '.$limit.', '.$ergebnisse_pro_seite);
$result = $conn->query($sql);

Da meine Variable $ergebnisse_pro_seite den Wert 1 hat, wird ein Datensatz pro Seite ausgegeben. Den zeige ich mir in einer while-Schleife in einer zweispaltigen Tabelle an. Die Tabelle enthält eine textarea, in die kommt der HTML-Code. In der zweiten Spalte wird die Vorschau ausgegeben. Zuerst schubse ich mal die ID des aktuellen Datensatzes in eine Variable, die brauchen wir später für den Update.

Dann frage ich ab, ob der „Änderungen speichern“-Button gedrückt wurde. Wenn ja, zeige ich den geänderten Inhalt des Editorfensters in der Tabelle an, wenn nein einfach den Originalcontent so wie er aus der Abfrage kommt.

//Ausgabe in Tabelle mit Formular
 while($row = $result->fetch_assoc()) {
            $akt_id = $row["ID"];
            echo "Aktuelle Datensatzid: ".$akt_id."<br>";
            
            echo "<form action ='#' method = 'post'>";
            echo "<input type = 'submit' name = 'absenden' value = 'Änderungen speichern'>";
            echo "<table border='1' cellpadding='4'>";
            echo "<th>".utf8_encode($row['post_title'])." HTML</th><th>Vorschau</th></tr>";
            
            //Wenn Speichern gedrückt wurde, editierten Content aus der Textarea ausgeben 
            if(isset($_POST['absenden'])){$inhalt = $_POST['content'];}
            else {$inhalt = utf8_encode($row['post_content']);}
                        
            echo "<tr>";
            //HTML Source in Textarea ausgeben
            echo "<td valign='top'><textarea rows='50' cols='80' name='content' id='content'>".$inhalt."</textarea>";
            echo "</td>";
            
            //HTML Vorschau ausgeben
            echo "<td valign='top'>".$inhalt."</td>";
            echo "</tr>";
            echo "</table>";
            echo "</form>";

Jetzt fehlt nur noch der Update, der wird beim Klicken des „Änderungen speichern“-Buttons ausgelöst:

if (isset($_POST['absenden'])){
                            
            //***********Action
            
            $sql = "UPDATE rezepte SET post_content =
'".utf8_decode(addslashes($_POST['content']))."' WHERE ID=".$akt_id."";
            //*************End Action
            
           if (mysqli_query($conn, $sql)) {
              echo "Record updated successfully";
              echo "<script type=\"text/javascript\">alert('Änderungen erfolgreich gespeichert');</script>";
            }
              
            else {
              echo "Error updating record: " . mysqli_error($conn);
              echo "<script type=\"text/javascript\">alert('Fehler beim Speichern');</script>";
            }    
    
    } //Ende von isset absenden
 } //Ende von while row = result

Im Update überschreibe ich den Inhalt von post_content mit dem Inhalt des Editorfensters, die steckt ja in der Variablen:

$_POST['content']

und zwar im Datensatz mit der aktuellen ID. Wegen der deutschen Umlaute muss ich hier mit utf8- encode und -decode arbeiten, das muß man bei einer anderen Datenbankkollation evtl anpassen. Ausserdem brauche ich noch einen addslashes(), weil meine Texte Anführungszeichen enthalten können. Dann mache ich noch eine kleine Fehlerbehandlung und gebe einen Javascript-Alert aus, ob der Update funktioniert hat oder nicht. Das wars auch schon – jetzt fehlt nur noch die nummerische Pagination zum anklicken des i-ten Datensatzes:

 //Nav Links alle Seiten
 for ($i=1; $i<=$row_total; $i++) { 
    echo "<a href='seitenweise.php?seite_nr=".$i."'>".$i."</a> "; 
};

Bitteschön, fertig ist der Q&D-Editor!

vanillekipferl_im_editor

vanillekipferl_im_editor

Tipp, auch quick&dirty:

Man kann ganz schnell eine (primitive) Filterfunktion basteln, wenn man die beiden SQL-Strings um eine „LIKE“-Klausel ergänzt:

$sql = "SELECT * FROM rezepte WHERE post_content LIKE '%".$filter."%'";
...
//Selektiere Datensatz mit der aktuellen Seitennummer
$sql = ('SELECT * FROM rezepte WHERE post_content LIKE "%'.$filter.'%" LIMIT '.$limit.', '.$ergebnisse_pro_seite.'');

Die Variable $filter setzt man am Anfang des Skripts auf den gewünschten Wert, zum Beispiel auf „caption“ oder „<ul>“ oder was auch immer. Dabei muss man aber berücksichtigen, was die aktuelle Datenbankkollation als Suchkriterien akzeptiert, bei Umlauten und Sonderzeichen kommt man da sonst zu unerwarteten Ergebnissen. Aber so als kurze Arbeitshilfe ist das schon mal ganz nützlich.

Quick&Dirty Editor für HTML-Posts mit Vorschaufunktion

Wer viel mit CMS umgeht, kennt das zur Genüge: in der Datenbank landet im Feld für den Inhalt eines beliebigen Posts oder einer Seite Text mit jeder Menge HTML-Tags, schließlich arbeitet man ja mit dem TinyMCE oder einem seiner Verwandten.Das sieht zum Beispiel in WordPress so aus:

<h2>Einleitung</h2>
In München-Haidhausen gibt es einen wunderbaren Laden, den "Liquid", da kann man erlesene Alkoholika auch in kleinen Mengen (ab 0,1 l) kaufen. Daher gibt es bei mir die Scaloppine mal mit Marsala, mal mit Sherry, oder ich bereite sie mit Portwein zu, ganz nach Lust und Laune. Wichtig ist, daß der Wein eher von der lieblichen Sorte sein soll, nur dann bekommt die Sauce den schönen vollmundigen Geschmack.
<h2>Zutaten</h2>
Für 4 Personen:

4 Kalbsschnitzel oder 8 dünn geschnittene Minutensteaks, alle Fettränder und Häutchen sorgfältig abgeschnitten, Mehl zum wenden. Je 1 El Butter und gutes Olivenöl, Salz, Pfeffer.
Zum Ablöschen: 1 kleines Glas lieblicher Südwein.
Noch 1 El. eiskalte Butter.
<h2>Zubereitung</h2>
Siehe <a href="http://evileu.de/inselfisch-kochbuch/2017/01/12/schnitzel-mit-zitrone-scaloppine-al-limone/">Scaloppine Grundrezept</a>, zum Ablöschen ein kleines Glas Südwein (s.oben) nehmen. Man kann die Scaloppine auch noch mit etwas feingehackter Petersilie bestreuen, aber das muß nicht unbedingt sein.

Das ist der post_content eines Rezeptes für Scaloppine. Im Inselfisch-Kochbuch sieht das so aus:

scaloppine

scaloppine

Recht und schön, aber im richtigen Leben kommt es immer wieder mal vor, dass man Content aus einem CMS abzieht und in einem anderen CMS weiterverwenden möchte. Das geht in den seltensten Fällen ohne umfangreiche Nacharbeiten, und nicht alles kann man programmgesteuert erledigen.

Man kann mit PHP natürlich alle HTML-Tags entfernen (siehe strip_tags Doku) und dabei sogar Ausnahmen definieren, welche Tags drinbleiben dürfen, und man kann sich auch mit preg_replace mehr oder weniger geniale Ersetzungen einfallen lassen. Aber das hat auch so seine Nachteile.

In dem Scaloppine-HTML ist zum Beipiel ein Link drin, der auf das Inselfisch-Kochbuch auf evileu.de verweist, das kann natürlich nicht so bleiben. Schmeißt man alle Links programmatisch komplett raus, ergibt der Text keinen Sinn mehr, da fehlt dann für das ganze Rezept die Zubereitung. Hier müßte man, wenn man es ganz richtig machen will, dem Link nachgehen und den entsprechenden Zubereitungstext rauskopieren. Das ist natürlich aufwendig, aber im Zweifelsfall die einzig richtige Lösung.

Tscha, was macht man jetzt, wenn man vor ein paar Hundert Posts sitzt, die manuell überarbeitet werden müssen? Man überlegt sich eine Arbeitserleichterung.

Voraussetzungen

Ich hab mir mal aus der WordPress posts-Tabelle nur die minimalsten Rohdaten abgezogen, nämlich die ID, den Titel und den Content, gefiltert nach post_type = post und post_status=publish, das sind die Kerndaten aller veröffentlichten Kochrezepte. Wenn ich sonst noch was brauchen sollte, den Autor oder das Datum oder sogar die Kategorien oder sonstwas, das kann ich mir später über die ID wieder dazulinken. Das selbe könnte ich auch mit Joomla-Beiträgen oder Drupal-Nodes machen, Hauptsache die ID kommt mit und der Titel und Content passen. Und das Ganze ist eigentlich nur sinnvoll, wenn die Posts nicht allzu lang sind, aber meine Kochrezepte gehen selten über eine Bildschirmseite hinaus.

Wir basteln uns einen Quick&Dirty Editor

Damit man jetzt nicht immer direkt in der Datenbank rumpfuschen muss, wenn man in einem HTML-Post etwas ändern will, habe ich mir eine zwar nur als Arbeitspferd geeignete, aber durchaus zeitsparende Lösung überlegt. Ich habe bei meinen ganzen Snippets zur Pagination gekupfert und mir ein PHP-Script gebaut, in dem pro Seite ein Datensatz dargestellt wird. Es gibt eine rudimentäre Navigation (voriger/nächster Datensatz), das reicht mir für die Arbeit, schließlich gucke ich im Zweifelsfall einen Datensatz nach dem anderen durch. Dann habe ich mit Hilfe einer Tabelle zwei Bildschirmbereiche konstruiert, im ersten wird der HTML-Code dargestellt und kann editiert werden, im zweiten gibt es eine Vorschau des Ergebnisses. Noch ein Knöpfchen zum Speichern der Änderungen, und es kann losgehen.

qe_scaloppine

qe_scaloppine

Für den Fall dass ich zu einem bestimmten Datensatz springen möchte habe ich ganz unten auch noch eine nummerische Navigation eingebaut, das ist bei über 300 Datensätzen ganz nützlich.

seitenpagination

Seitenpagination

Wie man mit dem Editor arbeitet

Wenn man in einem Post etwas entdeckt hat, das man ändern möchte, kann man dies direkt im HTML-Fenster tun. Hier habe ich zum Beispiel ein Bild drin, das wird WordPress-typisch in einen caption-Shortcode eingeklemmt, der sorgt in WordPress für die korrekte Darstellung der Bildbeschriftung.

caption

caption

Ein anderes CMS kennt aber den Shortcode nicht, also muss er raus. Das sieht man auch an der Darstellung im Vorschau-Fenster, der Browser kann natürlich ohne WordPress mit dem Shortcode nix anfangen und stellt ihn als Text dar:

caption_vorschau

caption_vorschau

Um das zu korrigieren, schmeisse ich im HTML-Fenster die caption-Tags raus und platziere noch ein paar <br> an den geeigneten Stellen, mache gleichzeitig noch einige kleine Textkorrekturen:

ohne_caption

ohne_caption

Klick auf den Button „Änderungen speichern“, dann kommt erst mal eine kurze Meldung, ob der Update erfolgreich war:

meldung

meldung

Und dann kriegt man das Ergebnis im Vorschaufenster angezeigt:

vorschau

vorschau

Na bitte, das geht doch ratzfatz!

Ohne Netz und doppelten Boden

Da ich beim Klicken auf den „Änderungen speichern“-Button direkt einen Update auf die Datenbank fahre, sind die Änderungen natürlich nicht mehr rückgängig zu machen, aber das kann ich verschmerzen. Schlimmstenfalls muss ich mir einen Datensatz aus der Originaltabelle wieder herholen, wenn ich ihn total verhunzt habe, aber das ist mir eigentlich noch nicht passiert. Im richtigen Leben wird sowas eh der Praktikant machen, und der kann HTML und weiß was er tut, wenn er Tags rausschmeisst oder korrigiert.

Der Q&D-Editor ist ja auch nur als Arbeitshilfe für Entwickler gedacht, und nicht für den Endanwender. Er soll auch nicht den gezielten Einsatz von programmatischen preg_replace-Aktionen ersetzen, die haben ja durchaus auch einen Sinn. Mir gehts immer so, dass ich beim Arbeiten mit dem Editor meistens ganz schnell merke, welche Elemente programmgesteuert rausgeschmissen werden können, weil ich immer die selben Tags editiere – und dann ist natürlich ein bisschen zusätzliches PHP angesagt. In der Praxis wird man immer eine Kombination aus manuellem Editieren und programmgesteuerten Ersetzungen fahren, damit bin ich eigentlich bis jetzt recht gut klargekommen.

Und jetzt gibts den Sourcecode des Q&D-Editors, in einem neuen Beitrag.

 

Joomla Modul für alfabetische Pagination

Weil es doch ein bißchen anders geht als in WordPress, hab ich hier nochmal die alfabetische Pagination von Beiträgen aufgegriffen und in ein Joomla-Modul gepackt. Nur mal kurz zur Erinnerung, das Ganze soll so aussehen:

alfabetisch

alfabetisch

Eigentlich selbsterklärend… wenn man auf einen Buchstaben klickt, werden alle Beiträge mit diesem Anfangsbuchstaben aufgelistet, natürlich als Links. Interessant ist hier, dass der Joomla-Datenbanktreiber die Sortierung aus dem „order by title“ ohne weitere Kunstgriffe auch mit deutschen Umlauten und Accents richtig macht, in WordPress musste man da etwas tricksen. Aber das nur als Randnotiz.

Da in Joomla die Beitragskategorien so elementar wichtig sind, habe ich ins Modul eine Auswahl der Kategorie mit aufgenommen. Hier wurde die Kategorie „Rezepte“ gewählt, es geht aber auch jede andere Kategorie, da kommt das Standardformularfeld vom Type „category“ gerade recht.

Und hiermit fangen wir auch an, die XML-Datei für unser Modul sieht so aus:

<?xml version="1.0" encoding="utf-8"?>
<extension type="module" version="3.1.0" client="site" method="upgrade">
    <name>Alfapage Modul</name>
    <author>Evi Leu</author>
    <version>1.0.0</version>
    <description>Alfabetische Pagination</description>
    <files>
        <filename>mod_alfapage.xml</filename>
        <filename module="mod_alfapage">mod_alfapage.php</filename>
        <filename>index.html</filename>
        <filename>helper.php</filename>
        <filename>tmpl/default.php</filename>
        <filename>tmpl/index.html</filename>
    </files>
    <config>
    <fields name="params">
        <fieldset name="basic">
            <field name="mycategory" type="category" extension="com_content" label="Kategorie auswählen" description="" />
        </fieldset>
    </fields>
    </config>
</extension>

Die XML-Defi enthält genau ein Feld für Benutzereingaben (grün markiert), hier kann man aus den vorhandenen Kategorien eine auswählen.

alfapage_modul

alfapage_modul

Das Modul habe ich mod_alfapage genannt, bitte Dateinamen entsprechend anpassen nicht vergessen.

Dann gehts auch schon zur Sache. Die mod_alfapage.php sieht so aus:

<?php
/**
 * Basic Module Entry Point
 */

// No direct access
defined('_JEXEC') or die;
// Include the syndicate functions only once
require_once dirname(__FILE__) . '/helper.php';

//Werte aus dem Fieldset abholen
$kategorie = $params->get('mycategory');


$data = new stdClass();
//Objekt füllen
$data->kategorie = $kategorie;

        
$basic_ausgabe = modBasicHelper::getAusgabe($data);
require JModuleHelper::getLayoutPath('mod_alfapage');

Hier wird genau ein Parameter an die Helper-Klasse übergeben, nämlich die ID der gewählten Kategorie aus dem Dropdown-Feld im Modul. Nicht vergessen: in der default.php den Variablennamen anpassen!

<?php 
// No direct access
defined('_JEXEC') or die; ?>
<?php echo $basic_ausgabe; ?>

Weiter geht es in der helper.php, hier kann man einiges vom WordPress-Plugincode übernehmen, aber eben nicht alles. Erster Stolperstein: ich möchte den Namen (nicht die numerische ID) der gewählten Kategorie ausgeben. Dafür behelfe ich mir so:

<?php
/**
 * Helper class für Basic Modul
 
 */
class ModBasicHelper
{
    /*
     * @param   variable  $params containing the module parameter
     *
     * @access public          */    
          
          
    
    public static function getAusgabe($params)
    {
        $akt_kat = $params->kategorie;
        
        //Kategorietitel holen
        $db = JFactory::getDbo();
        //get current category id
        $id = $akt_kat; 
        //match id to cat.id from _categories set to variable $id
        $db->setQuery("SELECT cat.title FROM #__categories cat WHERE cat.id='$id'"); 
        $category_title = $db->loadResult();
        
        echo "<h2>Alfabetisches Verzeichnis der Kategorie ".$category_title."</h2>";

Ich hab keine schönere Methode gefunden, also gehe ich mit dem Select auf die categories-Tabelle und hole mir den Kategorienamen zur übergebenen ID.

Dann konstruiere ich mir genau wie in WordPress Submit-Buttons von a-z und frage mit einem if isset() ab, welcher denn geklickt wurde.

//***************************************
        //Buchstaben a-z in Array schreiben
            $letters = array();
            for ($i = 'a', $j = 1; $j <= 26; $i++, $j++) {
                $letters[$j] = $i;    
            }
            //Formular mit Buttons
            echo "<form action = '#' method = 'post'>";
            
            for ($i=1; $i <=26; $i++){
                echo "<input type='submit' name='".$letters[$i]."' value='".$letters[$i]."'>";
            }
                echo "</form>";
               
        for ($j = 1; $j <= 26; $j++){    
        if (isset($_POST[''.$letters[$j].''])){
            
            return el_aufruf("".$letters[$j]."",$akt_kat);
            
        }

Der angeklickte Buchstabe und die aktuelle Kategorie-ID werden an eine Hilfsfunktion zur Ausgabe übergeben, die steht in der helper.php nach der Klassendefinition (Wenn man sie innerhalb der Klassendefinition mit reinpackt, Aufruf mit modBasicHelper::el_aufruf()).

Hier hole ich mir zunächst aus der Tabelle #__content alle Einträge, die mit dem übergebenen Buchstaben anfangen. Ausserdem filtere ich nach state = 1 (published) und der übergebenen Kategorie-ID:

function el_aufruf($stabe, $kat){
    $db =JFactory::getDBO();
    $suchstabe = $stabe."%";
    $query = "SELECT * FROM #__content where title like '".$suchstabe."' and state = 1 and catid = ".$kat." order by title";
    $db->setQuery($query);
    $db->execute();
    $gefunden = $db->getNumRows();
    $results = $db->loadObjectList();   
     
        
        echo "<h3>".$gefunden." Beiträge zum Buchstaben ".strtoupper($stabe)."</h3>";

Durch die auf der Variable $results liegende Objektliste mit dem Abfrageergebnis steppen wir nun wie gewohnt mit einem foreach durch und geben alle Titel der gefundenen Beiträge aus. Um auch einen Link zum Beitrag konstruieren zu können, muss man in Joomla ein bißchen umständlich operieren, das geht so:

foreach ($results as $einpost){
            
            $article = JControllerLegacy::getInstance('Content')
            ->getModel('Article')->getItem($einpost->id);

            $url =  JRoute::_(ContentHelperRoute::getArticleRoute($einpost->id, 
                      $article->catid, 
                      $article->language));
            
            echo "<a href = '".$url."'>".$einpost->title."</a><br>";
            
        }
    
} //end function el_aufruf

Damit wird eine Linkliste zu den gefundenen Beiträgen ausgegeben. Das wars – alfabetische Pagination in Joomla für Beiträge einer frei wählbaren Kategorie.

buchstabe_k

buchstabe_k

Pedanten werden anmerken, das die Sortierung nicht ganz Telefonbuch-konform ist, die Umlaute werden nicht nach ihren Diphtongen einsortiert (ä als ae), sondern nach ihrem Basis-Buchstaben (ä als a). Aber damit kann ich leben, da mach ich jetzt nix.

Wo Joomla die Benutzereingaben von Modulen speichert

Ich hab gerade in einem kleinen Projekt ein Modul mit mehrfachen Benutzereingaben gebraucht, und dafür kamen mir die Standard Form Field Types von Joomla gerade recht. Wer dazu eine kurze Auffrischung braucht, in diesem Artikel habe ich mich näher über Benutzereingaben in Joomla-Modulen ausgelassen.

Ich brauchte ein Textfeld, eine Zahl, eine Dropdown-Liste und drei Radiobuttons sowie eine Textarea, und das sieht in der XML-Datei des Moduls so aus:

<config>
    <fields name="params">
        <fieldset name="basic">
            <field name="param1" type="text" default="" label="Bitte Text eingeben" description="Auszugebender Text"></field>
            <field name="param2" type="number" default="" label="Bitte Zahl eingeben" description="Auszugebende Zahl"></field>
            <field name="meineoption" type="list" default="" label="Eine Option wählen" description="">
                <option value="1">Option 1</option>
                <option value="2">Option 2</option>
            </field>
            <field name="meinradio" type="radio" default="" label="Bitte auswählen" description="" class="btn-group">
                <option value="Ja">Ja</option>
                <option value="Nein">Nein</option>
                <option value="Weissnicht">Weissnicht</option>
            </field>
            <field name="meinetextarea" type="textarea" default="" label="Längeren Text eingeben" description="" rows="10" cols="5" filter="raw"/>
        </fieldset>
    </fields>
    </config>

Das erzeugt die folgenden Eingabemöglichkeiten im Modul:

basicmodul

basicmodul

Erhob sich bei mir ganz schnell die Frage: wo werden denn diese Benutzereingaben gespeichert?

Kurzes Googlen ergab des Rätsels Lösung. In der Tabelle #__modules wird für jedes neu erzeugte Modul ein eigener Eintrag angelegt, man suche im Feld title nach dem Titel des Moduls, bei mir heißt es „Basic“. (Wenn man ganz sichergehen will, guckt man sich auch noch das Feld module an, da sollte der Name des betreffenden Moduls drinstehen, bei mir ist das mod_basic)

In diesem Datensatz findet sich im Feld params ein längerer String, der sämtliche Benutzereingaben enthält, der sieht etwa so aus:

{„param1“:“Hallo ich bin dein Basic-Modul „,“param2″:“199″,“meineoption“:“2″,“meinradio“:“Weissnicht“,“meinetextarea“:“<h1>Lorem ipsum<\/h1> w\u00e4r jetzt praktisch mal schauen was der mit dem Umbruch macht“,“module_tag“:“div“,“bootstrap_size“:“0″,“header_tag“:“h3″,“header_class“:““,“style“:“0″}

Aber, das ist doch… ja klar! JSON ist das, und dem kommen wir ganz einfach bei. Ich möchte mal Beispielhaft den param2 (die Zahl) ausgeben, in Joomla klappt das so:

$db =JFactory::getDBO();
$query = 'SELECT params FROM #__modules WHERE title="Basic"';
$db->setQuery($query);
$result = $db->loadResult();
$meinarray = json_decode($result);
echo "Hier kommt param2: ".$meinarray->param2;

Dabei entspricht der Name der Array-Position dem Namen des Eingabefeldes in der XML-Definition, so einfach ist das. Ist vielleicht ganz nützlich zu wissen, falls man diese Werte mal an anderer Stelle brauchen sollte.

Sag niemals nie: Widget für die X neuesten Beiträge eigener Post Types

Ich hab ja gesagt, mir ist das zu kompliziert, aber jetzt hab ich mir doch ein Widget geschrieben, das die X neuesten Beiträge eines wählbaren Post Types anzeigt. Man kann dem Widget einen Titel geben, man kann eingeben wieviele Beiträge angezeigt werden sollen, man kann auch noch anwählen ob das Datum mit angezeigt werden soll oder nicht. Aussehen tut das Ganze so:

post_type_widget

post_type_widget

Und die Ausgabe in der Sidebar sieht zum Beispiel so aus:

widget_posts

widget_posts

Hier hab ich als Post Type „post“ angegeben (das sind meine Rezepte), das Limit auf 5 gesetzt und Datum ausgeben angekreuzt.

Das Widget wird ganz normal im Plugins-Verzeichnis angelegt, der Header mit der Klassendeklaration sieht so aus:

/*
Plugin Name: Post Type Widget
Plugin URI: http://evileu.de/wordpress
Description: Zeigt die neuesten X Beiträge des gewählten Post Types an
Author: Evi Leu
Version: 1.0
Author URI: http://evileu.de
*/


class PostTypeWidget extends WP_Widget
{
  function PostTypeWidget()
  {
    $widget_ops = array('classname' => 'PostTypeWidget', 'description' => 'Zeigt die neuesten X Beiträge des gewählten Post Types an' );
    $this->WP_Widget('PostTypeWidget', 'Post Type', $widget_ops);
  }

Interessant wird es in der Formulardefinition, da habe ich mir ein Dropdownfeld mit meinen vorhandenen Post Types gebastelt, ich picke das mal heraus und markiere die anzupassenden Stellen rot:

<p>
    <label for="<?php echo $this->get_field_id( 'posttype' ); ?>"><?php _e( 'Select Post Type', 'textdomain' ); ?>:</label>
    <p>Post Type auswählen
   <select id="<?php echo $this->get_field_id('posttype'); ?>" name="<?php echo $this->get_field_name('posttype'); ?>" class="widefat" style="width:100%;">
    <option <?php selected( $instance['posttype'], 'post'); ?> value="post">Post</option>
    <option <?php selected( $instance['posttype'], 'kochbuch'); ?> value="kochbuch">Kochbuch</option>   
    <option <?php selected( $instance['posttype'], 'projects'); ?> value="projects">Projects</option> 
    </select>
   </p>

Man hätte auch die vorhandenen Post Types aus der Datenbank fischen können, aber das war mit zu viel Heckmeck, da müsste man ja noch die WordPress-eigenen Types und evtl. auch die von irgendwelchen Plugins angelegten herausfiltern, ich fand es so herum entschieden einfacher. Wer mehr Post Types hat, ergänzt einfach den Select entsprechend.

Nachtrag: alle Post Types aus der wp_posts anzeigen

Jetzt hab ichs doch noch ausprobiert, wer sich alle vorhandenen Post Types aus der wp_posts im Dropdownfeld anzeigen lassen will, kann für den Select folgende Konstruktion verwenden:

 <p>Post Type auswählen
   <select id="<?php echo $this->get_field_id('posttype'); ?>" name="<?php echo $this->get_field_name('posttype'); ?>" class="widefat" style="width:100%;">
    <?php
    global $wpdb;
    $alleposts = $wpdb->get_results( "SELECT DISTINCT post_type 
                                      from ".$wpdb->prefix."posts");
    
    foreach($alleposts as $einpost){      
      echo "<option ".selected( $instance['posttype'], $einpost->post_type)." value=".$einpost->post_type.">".$einpost->post_type."</option>";
    }
    ?>
    
    </select>
   </p>

Da kriegt man halt auch jeden Schrott angezeigt, aber es funktioniert:

alle_post_types

alle_post_types

Bleibt jedem selber überlassen, ob er diese Option verwenden will oder den statischen Select von oben. Mir ist die statische Dropdownliste lieber, weil sie den Benutzer nicht in Versuchung bringt hier eine sinnfreie Option wie z.B revisions anzuwählen. Natürlich könnte man den SQL entsprechend aufblasen und noch einige „WHERE post_type NOT LIKE ‚xyz'“ dranflicken, aber das ist mir entschieden zu umständlich.

Die Checkbox für das Datum

Für die Checkbox zum Datum anzeigen habe ich folgende Konstruktion verwendet:

<p>
    <input class="checkbox" type="checkbox" <?php checked( $instance[ 'your_checkbox_var' ], 'on' ); ?> id="<?php echo $this->get_field_id( 'your_checkbox_var' ); ?>" name="<?php echo $this->get_field_name( 'your_checkbox_var' ); ?>" /> 
    <label for="<?php echo $this->get_field_id( 'your_checkbox_var' ); ?>">Datum anzeigen</label>
</p>

Die ganze Funktion form($instance) sieht so aus:

function form($instance)
  {
    $instance = wp_parse_args( (array) $instance, array( 'title' => '' ) );
    $title = $instance['title'];
    
    $instance = wp_parse_args( (array) $instance, array( 'posttype' => '' ) );
    $posttype = $instance['posttype'];
    
    $instance = wp_parse_args( (array) $instance, array( 'anzahl' => '' ) );
    $anzahl = $instance['anzahl'];
    
    $instance = wp_parse_args( (array) $instance, array( 'your_checkbox_var' => '' ) );
    $your_checkbox_var = $instance['your_checkbox_var'];
    
    
    
?>
  <p><label for="<?php echo $this->get_field_id('title'); ?>">Titel: <input class="widefat" id="<?php echo $this->get_field_id('title'); ?>" name="<?php echo $this->get_field_name('title'); ?>" type="text" value="<?php echo attribute_escape($title); ?>" /></label></p>
  
   <p>
    <label for="<?php echo $this->get_field_id( 'posttype' ); ?>"><?php _e( 'Select Post Type', 'textdomain' ); ?>:</label>
    <p>Post Type auswählen
   <select id="<?php echo $this->get_field_id('posttype'); ?>" name="<?php echo $this->get_field_name('posttype'); ?>" class="widefat" style="width:100%;">
    <option <?php selected( $instance['posttype'], 'post'); ?> value="post">Post</option>
    <option <?php selected( $instance['posttype'], 'kochbuch'); ?> value="kochbuch">Kochbuch</option>   
    <option <?php selected( $instance['posttype'], 'projects'); ?> value="projects">Projects</option> 
    </select>
   </p>
  <p><label for="<?php echo $this->get_field_id('anzahl'); ?>">Anzahl: <input id="<?php echo $this->get_field_id('anzahl'); ?>" 
name="<?php echo $this->get_field_name('anzahl'); ?>" type="number" value="<?php echo attribute_escape($anzahl); ?>" /></label></p>
<p>
    <input class="checkbox" type="checkbox" <?php checked( $instance[ 'your_checkbox_var' ], 'on' ); ?> id="<?php echo $this->get_field_id( 'your_checkbox_var' ); ?>" name="<?php echo $this->get_field_name( 'your_checkbox_var' ); ?>" /> 
    <label for="<?php echo $this->get_field_id( 'your_checkbox_var' ); ?>">Datum anzeigen</label>
</p>
  
  
  
<?php
  }

Dann noch die Funktion update() anpassen:

function update($new_instance, $old_instance)
  {
    $instance = $old_instance;
    $instance['title'] = $new_instance['title'];
    $instance['posttype'] = $new_instance['posttype'];
    $instance['anzahl'] = $new_instance['anzahl'];
    $instance[ 'your_checkbox_var' ] = $new_instance[ 'your_checkbox_var' ];
    return $instance;
  }

Und schliesslich in der Funktion widget() die Variablen abholen:

function widget($args, $instance)
  {
    extract($args, EXTR_SKIP);
 
    echo $before_widget;
    $your_checkbox_var = $instance[ 'your_checkbox_var' ] ? 'true' : 'false';
    $title = empty($instance['title']) ? ' ' : apply_filters('widget_title', $instance['title']);
    $posttype    = empty( $instance['posttype'] ) ? '' : esc_attr( $instance['posttype'] );
    $anzahl    = empty( $instance['anzahl'] ) ? '' : esc_attr( $instance['anzahl'] );

Der eigentliche OpCode des Widgets ist nicht weiter kompliziert, die Hauptsache ist die SQL-Query, in die ich die Variablen für den Post Type und für die Anzahl einsetze:

global $wpdb;
    $alleposts = $wpdb->get_results( "SELECT * from ".$wpdb->prefix."posts 
where post_type like '".$posttype."' 
and post_status like 'publish' 
ORDER BY post_date DESC
 LIMIT ".$anzahl."");
    

Das ganze wird noch nach dem post_status=publish gefiltert und absteigend nach Datum sortiert und kann jetzt in einem foreach ausgegeben werden. Dabei baue ich noch die Abfrage ein, ob das Datum mit ausgegeben werden soll:

foreach($alleposts as $einpost){
        
        $dt = new DateTime($einpost->post_date);
        echo $einpost->post_title." ";
        if ($your_checkbox_var == 'true'){ echo $dt->format('d.m.Y');}
        echo "<br>";
    }

Hier könnte man wie schon öfter gehabt mit dem get_permalink() über die ID gleich noch den Link zum entsprechenden Beitrag mit einbauen, das spare ich mir jetzt. Wem das jetzt zu schnell ging, den ganzen Code des Widgets gibt es hier gezippt: post-type-widget

Viel Spaß beim Nachbauen!

 

 

Custom Post Types: kurzes Resümee

Wie wir gesehen haben, sind Custom Post Types und Custom Taxonomies für jemanden, der ein bisschen Ahnung vom Programmieren hat, nicht besonders schwierig zu realisieren. Rein funktional gesehen sind sie eine tolle Erweiterungsmöglichkeit, die WordPress auf dem Weg zum „richtigen“ CMS mit Siebenmeilenstiefeln weiterbringen. Was hab ich also noch zu meckern?

Eben: es geht nicht ohne Eingriffe in die functions.php (oder ein selbst programmiertes Plugin), und man kommt auch nicht darum herum die Theme-Templates zu manipulieren. Da würde ich mir eine andere Lösung wünschen! Es wäre eine tolle Erweiterung des Core, wenn man Custom Post Types und Taxonomien über das Dashboard anlegen könnte, und dass da Bedarf da ist, zeigt die stattliche Auswahl an Plugins für diesen Zweck. Ich hab hier mal mit Absicht auf deren Einsatz verzichtet, eben weil es nicht sonderlich kompliziert ist sich seine Custom Post Types selber zu stricken, und  weil ich manchmal gern den Dingen auf den Grund gehe.

Aber für zukünftige WordPress-Versionen wäre es schon eine Bereicherung, wenn einem die Erstellung eigener Post Types auch so einfach gemacht werden würde wie bei der Konkurrenz (Joomla, Drupal…). Beim googlen zum Thema bin ich einige Male auf Diskussionen gestossen, in denen genau dies thematisiert wird. Also, mal schauen was noch kommt, und was sich die WordPress-Entwickler da noch einfallen lassen. Es bleibt jedenfalls spannend!

Custom Post Types in einem Widget

Ich hab nach langem und nicht besonders produktiven Googlen beschlossen, KEIN eigenes Widget für die Ausgabe der neuesten X Kochbücher zu schreiben, das ist mir viel zu umständlich. Es gibt auch Plugins speziell für diesen Zweck, aber das muss auch nicht sein, denn eigentlich ist die Anforderung mit einem einzigen MySQL-Statement zu erschlagen, das machen wir selber. Ich packe das wieder mal in einen Shortcode, der kann in die functions.php oder in ein Plugin, ganz nach Belieben. Das Ganze sieht schlicht und ergreifend so aus:

function kochbuch_ausgabe(){
   
  global $wpdb;
  $alleposts = $wpdb->get_results( "SELECT * from iii_wpposts 
WHERE post_type LIKE 'kochbuch' 
AND post_status LIKE 'publish' 
ORDER BY post_date DESC LIMIT 10");
    
    $ausgabe="";
    foreach($alleposts as $einpost){
        
        $ausgabe = $ausgabe.$einpost->post_title."</br>";
    }
    return $ausgabe;
 }
 add_shortcode('k_ausgabe', 'kochbuch_ausgabe');

Im Select ist alles drin was wir brauchen, das Limit kann man sich nach Wunsch selber anpassen.

Wenn wir das jetzt in einem Widget in der Sidebar haben wollen, klemmen wir uns ein Text-Widget und fügen da den Shortcode ein, und vergeben einen Titel nach Wunsch. Sollte das nicht klappen, muss man zuerst noch Shortcodes für das Text-Widget aktivieren, das geht mit einer Zeile in der functions.php:

add_filter('widget_text', 'do_shortcode');

Fertig sieht das so aus:

die_neuesten_kochbücher

die_neuesten_kochbücher

Wer mag, kann sich jetzt noch mit get_the_permalink() die Links zu den entsprechenden Kochbüchern basteln, die ID ist ja mit im Select. Das spare ich mir jetzt, da kann jeder selber kreativ werden.

Die Ausgabe der Custom Taxonomies in einem Widget: ein schickes kleines Plugin

Da mir die Tabellenstruktur der Taxonomies zu komplex für einen Select ist (join über 4 Tabellen), hab ich mal kurzen Prozeß gemacht und mir ein Plugin für diesen Zweck ausgesucht:

List Custom Taxonomy Widget

Es tut genau das, was es soll, und ist so gut wie selbsterklärend.

list_custom_taxonomy

list_custom_taxonomy

Die Ausgabe ist ganz wie erwartet:

aus_aller_welt

aus_aller_welt

Damit lass ich es gut sein, da muss man echt nichts mehr selber programmieren. Das Widget läßt sich natürlich auch für die Kochbuch-Stichworte verwenden, da brauchen wir also auch nix extra.

widget_stichworte

widget_stichworte

Für Bastler: es geht auch mit get_terms()

Wer sich die Ausgabe der Custom Taxonomies partout selber antun möchte, kann auf die WP_Funktion get_terms() zurückgreifen (siehe Codex). Den Link auf die enstprechenden Begriffe holt man sich dabei mit get_term_link(). Ich hab hier nur mal ein ganz kurzes Beispiel in einen Shortcode gepackt:

function get_land(){
 $terms = get_terms( 'land' );
if ( ! empty( $terms ) && ! is_wp_error( $terms ) ){
 
 foreach ( $terms as $term ) {
   
   echo "<a href = '".get_term_link($term)."'>".$term->name ."</a><br>";
     }
 
}
}
add_shortcode('land_ausgabe', 'get_land');

Das berücksichtigt jetzt nicht die geschachtelte Struktur, sondern gibt nur eine alphabetisch sortierte Liste der Terms der Taxonomie land mit ihren Links aus.

land_bastler

land_bastler

Man könnte jetzt noch den Namen der Taxonomie als Parameter in den Shortcode übergeben und sonst noch allerhand… aber wie gesagt, das ist was für Bastler. Ich verwende das oben vorgestellte Plugin, und gut ists.

Custom Post Type Kochbuch: das Feintuning, mit Custom Taxonomies

Verwendung des Excerpts/Auszugs

Zuallererst möchte ich einstellen, dass man bei den Kochbüchern in der Blog View nicht den ganzen Inhalt angezeigt bekommt, der ist nämlich im Zweifelsfall recht lang, und ausserdem mit mehreren großformatigen Bildern versehen. Dafür gibt es in WordPress die Funktion des Auszugs (Engl. Excerpt), damit kann man einen kurzen Einführungstext erstellen, der dann z.B. in der Liste der Suchergebnisse statt dem ganzen Beitrag angezeigt wird. Den Auszug hatten wir in unserer Post-Type-Definition aus dem vorigen Beitrag noch nicht mit drin, das ist aber schnell nachgeholt. Wir ergänzen in der functions.php unseres Childthemes die Post-Type-Definition wie folgt:

function post_type_kochbuch() {
    register_post_type(
                'kochbuch',
                array(
                    'label' => __('Kochbuch'),
                    'public' => true,
                    'show_ui' => true,
                    'supports' => array(
                    'title',
                    'editor',
                    'excerpt',
                    'post-thumbnails',
                    'custom-fields',
                    'revisions')
                )
        );
    
     
}

Damit wird im Beitragseditor unter dem Content-Feld jetzt das Feld Auszug mit angezeigt, und wir können einen Kurztext eingeben. Wie und wo überall der angezeigt wird ist vom Theme abhängig, ich arbeite hier mit einem Child von Twenty Twelve, da geht man es so an:

Dafür klemmt man sich die content.php und legt eine Kopie ins ChildTheme-Verzeichnis. Dann macht man sich auf die Suche nach der Codezeile:

<?php if ( is_search() ) : // Only display Excerpts for Search ?>

Die ändert man wie folgt:

<?php if ( is_search() || is_home() ) : // Display Excerpts for Search and Homepage ?>

Und schon tauchen auf der Kochbücher-Seite nur noch die Titel und die Auszüge auf. Kleiner Pferdefuß: das gilt jetzt auch für die Rezepte-Blogseite, auch dort werden nur noch Titel und Excerpts(falls vorhanden) angezeigt – ist mir aber ganz recht so, ich finde das wesentlich übersichtlicher. Ich schau aber mal, ob ich da noch eine genauere Steuerungsmöglichkeit finde.

Kategorien und Schlagwörter für die Kochbücher

Dafür legen wir uns zwei Custom Taxonomies an, die nur für den Post Type Kochbuch gelten. Das ist nicht weiter kompliziert, hier der Eintrag für die functions.php:

function kochbuch_create_my_taxonomy() {

    register_taxonomy(
        'land',
        'kochbuch',
        array(
            'label' => __( 'Land' ),
            'rewrite' => array( 'slug' => 'land' ),
            'query_var' => 'land',
            'show_ui' => true,
            'hierarchical' => true,
        )
    );
      register_taxonomy( 
      'kochbuch-stichwort', 
      'kochbuch',
        array(
             'hierarchical' => false,
             'label' => __('Kochbuch-Stichwort'),
             'query_var' => 'kochbuch-stichwort',
             'show_ui' => true,
             'rewrite' => array('slug' => 'kochbuch-stichwort' )
        )
    );
}
add_action( 'init', 'kochbuch_create_my_taxonomy' );

Rot markiert sind die Einträge für die Benennungen und die Slugs der jeweiligen Taxonomie. Die grün markierte Option ‚kochbuch‚ am oberen Ende der Taxonomie-Definition sorgt dafür, daß die Taxonomie auch nur für den Post Type Kochbuch herangezogen wird. Der einzige Unterschied zwischen den beiden Taxonomien ist, dass ich für die Land-Taxonomie ‚hierarchical’=>true eingestellt habe, das erlaubt eine Schachtelung der Länder. Für die Kochbuch-Stichworte steht hierarchical => false, das ergibt eine Ebene wie man es von den Stichworten in Worpress gewohnt ist.

Das sollte schon genügen, um unsere Custom Taxonomies funktional zu machen:

custom_taxonomies

custom_taxonomies

Ich hatte übrigens beim Testen am Anfang das Problem, dass neue Taxonomie-Einträge sich nicht abspeichern liessen. Die Ursache war ein Plugin-Konflikt! Ich hatte auf der Testumgebung noch einen Haufen experimentelle Plugins am Laufen, die hab ich deaktiviert, dann hat es ganz normal funktioniert. Die Wurzel des Problems war anscheinend eine Schlamperei meinerseits, ich hatte in einigen Plugins vor dem öffnenden <?php-Tag Whitespaces drin, das mag WordPress gar nicht, da gibt es die bekannte Meldung „Das Plugin verursachte X Zeichen unerwartete Ausgabe…“

Wie man die neuen Taxonomien ins Template einfügt

Das hängt wieder ziemlich vom Theme ab, da muss man ein bisschen rumprobieren. Die Taxonomie Land bekommt man mit folgender Codezeile:

<div class="entry-meta">
            <?php echo get_the_term_list( $post->ID, 'land', 'Rezepte aus aller Welt: ', ', ', '' ); ?>
            
        </div>

Ich hab da gleich mal die div class= „entry meta“ mitgenommen, damit die Formatierung wie bei den WordPress-Standardkategorien ausfällt. Die Codezeile kommt in die content.php ins Child-Theme, und zwar zwischen dem Block für den entry-content und dem footer:

</div><!-- .entry-content -->
        <?php endif; ?>
        <div class="entry-meta">
            <?php echo get_the_term_list( $post->ID, 'land', 'Rezepte aus aller Welt: ', ', ', '' ); ?>
            
        </div>
        <footer class="entry-meta">

In der Blogansicht sieht das dann so aus:

land_anzeige

land_anzeige

Und so sieht es aus, wenn man auch noch die Stichworte an der selben Position ausgibt:

<div class="entry-meta">
            <?php echo get_the_term_list( $post->ID, 'land', 'Rezepte aus aller Welt: ', ', ', '' ); ?><br>
            <?php echo get_the_term_list( $post->ID, 'kocbuch-stichwort', 'Stichworte: ', ', ', '' ); ?>
            
        </div>

(im kocbuch-Stichwort ist ein Schreibfehler, bitte ignorieren)

Nicht vergessen: Permalinks updaten!

Sonst kriegt man die 404-Meldung, wenn man auf einen der Taxonomy-Einträge klickt. Unser Endergebnis sieht jetzt in der Blog-Ansicht so aus:

blogview_kochbuch

blogview_kochbuch

Wir haben: den Titel, den Excerpt, die Länder und die Stichworte. Paßt!

Jetzt möchte ich noch gern meinen neuen Post Type Kochbuch in einem Widget „Die neuesten Kochbücher“ ausgeben, und die Kochbuch-Länder ebenfalls, aber dazu gibt es einen neuen Beitrag.

WordPress Custom Post Types – die Ehrenrettung als CMS?

Was in anderen CMS längst zur Standardausrüstung gehört, nämlich eine Logik zur Verwaltung und Präsentation unterschiedlicher Beitragstypen, ist in WordPress „out of the box“ erstmal nicht machbar, man hat Blog-Beiträge und statische Seiten, und das wars erstmal. In Joomla habe ich dafür die Kategorien mit einem ausgefeilten Verwaltungssystem, in Drupal die Inhaltstypen mit nicht minder komfortabler Steuerung über die Benutzeroberfläche.

Wozu braucht man überhaupt diese Unterscheidung nach unterschiedlichen Inhaltstypen?

Das ist für einen einfachen Quasselblog erstmal noch nicht notwendig, man kann ja seine Beiträge über die WordPress-Kategorien sehr feinkörnig und sogar hierarchisch logisch gruppieren. Das Kategoriensystem von WordPress ist sogar besonders ausgefeilt und komfortabel in der Bedienung, da haben sich die Core-Programmierer wirklich was einfallen lassen.

Es stellt sich aber bei den meisten Blogs mit der Zeit heraus, dass der ursprünglich vorgesehene Rahmen nach einiger Laufzeit zum zu engen Korsett wird. Einfaches Beispiel: dieser Blog hier, der vor anderthalb Jahren als reiner WordPress-Plauderblog angefangen hat. Mit der Zeit kamen dann noch andere Themen dazu, reine PHP- oder MySQL-Topics zum Beispiel, oder auch vor ein paar Monaten die Beitragsserie über Joomla. Wenn ich da gleich sauber gearbeitet hätte, hätte ich mir gleich einen neuen Beitragstyp für jedes neue Thema angelegt, da hab ich geschlampert und versucht, das über den Kategorienbaum zu steuern. Hat jetzt nicht gerade zur Übersichtlichkeit beigetragen, ich gebs ja zu. Ob ich das jetzt nachträglich noch umbauen möchte weiss ich noch nicht, aber schöner wärs schon man hätte für jedes Haupthema eine eigene Blogseite, und auch eine eigene Kategorisierung oder auch Stichwort-Verwaltung.

Wieso – ist denn WordPress MultiBlog-fähig?

Ein definitives „Im Prinzip ja“. Es geht halt nicht so ohne weiteres über die Benutzeroberfläche, man kommt nicht darum herum in die functions.php einzugreifen oder sich ein Plugin zu schreiben. Aber gehen tuts – mit Custom Post Types. Es ist noch nicht einmal besonders schwierig, und Tante Google liefert auch jede Menge Artikel zu dem Thema. Besonders informativ fand ich diesen Beitrag bei Elmastudio,  und auch der Beitrag hier von drweb bringt ordentlich Licht in die Sache. Mit den Custom Post Types in einem Atemzug werden häufig die Custom Taxonomies angesprochen, das klingt erstmal kompliziert, ist aber eigentlich auch nicht weiter schwierig. Man kann sich damit eigene Kategorie- und Stichwort-Logiken für die neuen Post Types anlegen, das ist sehr nützlich und absolut praxistauglich.

Wir gehens hier aber mal langsam und der Reihe nach an. Ich nehme als Beispiel wieder mein Inselfisch-Kochbuch, da haben wir gleich einen praktischen Einsatz.

Wozu jetzt einen neuen Beitragstyp?

Im Inselfisch-Kochbuch sind die Beiträge meine Rezepte, und das ist gut eingefahren und funktioniert auch prächtig. Die Anwender finden sich gut zurecht, das Kategoriensystem ist in der Praxis bewährt und sowohl übersichtlich als auch informativ. Welche Inhalte also habe ich, die einen neuen Beitragstyp sinnvoll machen würden? Na, die Kochbücher! Die habe ich auf statische Seiten gelegt, und das ist weder besonders übersichtlich für die Anwender (ellenlanges Aufklappmenü) noch für mich komfortabel zu pflegen. Ich hätte ja noch eine ganze Latte Kochbücher, die ich auch gern einstellen würde, aber da jedesmal das Menü wieder umzustricken ist mir echt zu aufwendig. Da wäre es doch viel schöner, ich könnte im Blog-Stil meine Kochbücher der Reihe nach reinklopfen und immer wieder dynamisch welche dazuschreiben… ja, auf gehts!

Wie soll der neue Post Type Kochbuch aussehen?

Eigentlich auch nicht anders als jeder andere WordPress-Beitrag. Titel, Beschreibung, gegebenenfalls ein Bild. Dazu noch Autor und Verlag, gegebenenfalls der Preis und  die Seitenzahl – aber das muss jetzt nicht in eine strikte Logik gepackt werden, das hat alles im Inhalt Platz. Interessanter ist es dann schon, die Kochbücher nach Herkunftsland (Bayern, USA, Asien…) zu gruppieren, dafür werde ich eine eigene Logik basteln. Und dann nehmen wir noch eine Stichwortverwaltung mit rein, in der könnte sowas stehen wie: Nachschlagewerk, Lesefutter, Grundrezepte, Spezialitäten, Für Anfänger, für Profis… das kommt dann beim Eintragen der Kochbücher, da wird sich noch einiges finden. Für die Herkunftsländer macht eine hierarchische Kategorien-Logik Sinn (Asien/Thailand, Asien/China…), für die Stichwörter (irgendwie logisch) die Stichwörter. Das legen wir uns jetzt mal der Reihe nach an.

Definition des neuen Post Types Kochbuch in der functions.php

Da können wir so gut wie alle WordPress-Beitragseigenschaften übernehmen, deswegen wird die Definition relativ kurz und knackig:

function post_type_kochbuch() {
    register_post_type(
                'kochbuch',
                array(
                    'label' => __('Kochbuch'),
                    'public' => true,
                    'show_ui' => true,
                    'supports' => array(
                    'title',
                    'editor',
                    'post-thumbnails',
                    'custom-fields',
                    'revisions')
                )
        );
}
add_action('init', 'post_type_kochbuch');

Damit ist der neue Post-Type auch schon angelegt und taucht bereits im Admin-Menü auf:

kochbuch_admin

kochbuch_admin

Man kann auch schon mal testweise einen neuen Eintrag vom Typ Kochbuch anlegen, aber wenn man ihn anschauen will, kommt wahrscheinlich die 404-Fehlermeldung. Wir machen auch erst mal noch was anderes:

Ein Template für den neuen Post Type anlegen

Dafür klemmt man sich die archive.php aus dem Parent-Theme und macht eine Kopie mit dem Namen archive-kochbuch, die legt man ins ChildTheme-Verzeichnis. Zuerst ändert man den Templatenamen:

/**
 * Template Name: Kochbuch Archive pages
 *
 */

Dann ergänzt man den Code unmittelbar vor dem Loop um eine Zeile, so daß WordPress auch den richtigen Post Type anzieht:

<?php query_posts(array('post_type'=>'kochbuch')); ?>
            <?php
            /* Start the Loop */
            while ( have_posts() ) : the_post();

Jetzt noch im Dashboard unter Einstellungen/Permalinks einmal die Permalink-Einstellungen speichern. Jetzt sollte man sich den eben erstellten ersten Kochbuch-Beitrag auch angucken können.

Eine eigene Seite für die Kochbücher erstellen

Neue Seite erstellen, ich nenn sie mal einfach Kochbücher. Wenn alles geklappt hat, kann man jetzt bei den Templates das soeben erstellte Kochbuch-Template anwählen:

kochbuch_template

kochbuch_template

Damit werden auf dieser Seite automatisch alle Beiträge vom neuen Post Type Kochbuch angezeigt. Diese Seite fügt man sich jetzt noch in sein Menü ein, und schon kann man loslegen.

Jetzt fehlt noch ein bisschen Feintuning, zum Beispiel möchte ich noch die Herkunftsländer und die Stichworte haben, aber dafür gibt es einen neuen Beitrag.