Archiv der Kategorie: WordPress

Inhaltsverzeichnis revisited: wg PHP 8 und sauber als Shortcode

Ich hab mir schon vor Jahren ein Inhaltsverzeichnis für meine WordPress-Webseiten gebastelt, das hatte ich damals mit PHP Code for Posts realisiert. Jetzt bei der Umstellung auf PHP 8 fällt es auf die Nase, ich musste es also eh noch mal überarbeiten. Es war ein relativ kleines Problem: ich hab in den Funktionsaufrufen für die Ausgabe pro Buchstabe keine Hochkommata für den Parameter dringehabt, das sah so aus:

BuchstabenAusgabe(A);

PHP 8 hätte es aber gern so:

BuchstabenAusgabe("A");

Bei der Gelegenheit hab ich es gleich in einen Shortcode gepackt und den Aufruf der Ausgabe mit einem Array gelöst, und weils so schön geklappt hat gehen wir es hier mal im Galopp nochmal durch.

Als Erstes kommt der Plugin-Header und die Definition des Shortcodes:

/*
Plugin Name: Inhaltsverzeichnis
Plugin URI: http://localhost/zum-schwarzen-pinguin/wp-content/plugins/inhaltsverzeichnis
Description: Erzeugt einen Shortcode [el_inhaltsverzeichnis] , der ein Inhaltsverzeichnis aller veröffentlichten Beiträge aus der Tabelle posts erstellt
Version: 3.0
Author: Evi Leu
Author URI: http://www.evileu.de
*/
add_shortcode( 'el_inhaltsverzeichnis', 'el_inhaltsverzeichnis_handler_function' );
function el_inhaltsverzeichnis_handler_function(){
echo "<h2>Inhaltsverzeichnis</h2>";...

Dann rufe ich die Funktion zur buchstabenweisen Ausgabe mit Hilfe eines Arrays für das Alfabet auf:

//Array mit Alfabet erzeugen
$alphas = range('A', 'Z');

//Durch alfabet durchsteppen
foreach($alphas as $letter){
//Alle Beiträge zu einem Buchstaben ausgeben
BuchstabenAusgabe("$letter");
}

Mit dem Buchstaben gehe ich in die Tabelle posts und hole mir die passenden Einträge heraus. Daraus wird eine Liste mit Links erzeugt, das geht schön mit der guid.

function BuchstabenAusgabe($aktBuchstabe){
global $wpdb;

//Beginn Originalcode
$table_name = $wpdb->prefix . 'posts';

//Datensätze zählen & Ausgabe Anzahl

$count_query = "select count(*) from $table_name where post_status='publish' and post_type = 'post' and post_title like '$aktBuchstabe%'";
$num = $wpdb->get_var($count_query);

//Ausgabe nur wenn auch Datensätze vorhanden sind
if ($num>0) { 
echo "<h2>$aktBuchstabe:&nbsp".$num."&nbsp Beiträge</h2>";

//Alle Datensätze vom Typ post und published ausgeben

$alleposts = $wpdb->get_results( "SELECT post_title, 
post_status, post_type,
guid FROM $table_name
where post_status='publish' and post_type = 'post' and post_title like '$aktBuchstabe%'
order by post_title");

foreach ( $alleposts as $einpost ) 
{ 
echo '<a href="', $einpost->guid, '/",">', $einpost->post_title, '</a></br>';

}

} //Ende if Anzahl grösser Null
//Ende Originalcode
}//ende function BuchstabenAusgabe

Das wars schon, Shortcode an beliebiger Stelle einsetzen und schwupps hat man ein schönes Inhaltsverzeichnis.

Wenns so einfach wäre: die Tücken der lokalen WordPress-Installation

Ich gebs zu, ich hatte es mir einfacher vorgestellt, eine lokale Kopie dieses Blogs anzulegen. Dateien per SFTP runterladen… hat fast eine Stunde gedauert, war aber noch OK. Datenbankbackup einspielen… das ging recht flott, so nach 10 Minuten war MySQL damit fertig. wp_config anpassen (Datenbank Name, User Pwd etc.). Pfade in der wp_options anpassen. Dann liefs, aber mein Plugin lief nicht. Doch es lief so prinzipiell schon, die Erstellung der CSV-Datei aus den Beitragstiteln lief ohne Fehler durch. Aber später bei der Anzeige der Linkliste gabs Probleme. Die guid aus der wp_posts stand natürlich überall noch mit dem Serverpfad drin, da machte ein Klick die Life-Installation auf und zeigte brav den passenden Eintrag an. Menno, ich will aber die lokalen Beiträge haben…

In diesem gewohnt informativen Beitrag bei elmastudio wird vorgeschlagen, die Pfade in der Datenbank Backup Datei mit Hilfe von Notepad++ Suchen&Ersetzen anzupasssen und die Tabellen erst dann zu importieren. War ich wieder zu schnell.. also, Tabellen nochmal droppen und neuer Versuch. Ich melde mich dann wieder.

Also, nach mehreren vergeblichen Versuchen eine Webseite manuell umzuziehen ist es mir jetzt zu dumm geworden, und ich hab mich an das Plugin Duplicator erinnert, das besonders für kleinere Webseiten 1a geeignet ist. Hier bei Weptimizer findet man eine ausführliche Anleitung. Ich hab jetzt meinen Praxis Dr. Inselfisch Blog lokal umgezogen und geh mal mein Plugin testen.

Nachtrag: der Duplicator ist schon Klasse, er hat mir diesen Blog hier klaglos auf meinen lokalen Webserver umgezogen, auch wenn das Einspielen von 94 MB gezipptem Archiv schon ein Stück gedauert hat. Tolles Plugin, wirklich!

Danke, Gutenberg! Wenn Shortcodes nicht funzen…

… nehme man den Classic Editor. Nee, ohne Schmarrn, dem ist so. Ich hab gestern gedacht ich werde noch wahnsinnig, meine Shortcodes tun nicht das was sie sollen, ich krieg ständig diese bescheuerten JSON-Fehler. Permalinks neu erstellt, an- und abgemeldet, Webserver neu gestartet, half alles nix. Bis ich dann beim googlen auf den Hinweis gestossen bin, dass man auf den Classic Editor zurückswitchen soll, wenn diese Fehler auftreten.

Gesagt, getan. Und was soll ich sagen? Jetzt funken meine Shortcodes wieder. Das darf doch wohl nicht wahr sein! Ist natürlich verdammt ärgerlich. Und ich weiss nicht, ob ich bei meinen Life-Blogs wirklich auf den Classic Editor umstellen möchte, das muss ich mir noch schwer überlegen. Ist schon ein dicker Hund.

Darf ich vorstellen: Stichwort Plugin Teil 1, CSV-Datei erzeugen

Da ich die ganze Mechanik schon mal programmiert habe, in Access mit Visual Basic, hab ich mir relativ leicht getan es auch in PHP zu lösen. Was gar nicht schön war: bei komplexeren Datenbankoperationen ist mir x-mal der Webserver abgeraucht. Deswegen hab ich dann die Notbremse gezogen und bin auf eine CSV-Datei ausgewichen. Nicht die schlechteste Lösung, was Stabilität und Performance angeht.

Was hab ich gemacht? Ich geh da mal im Schnelldurchlauf durch, haben wir alles schon mal so oder in ähnlicher Form gehabt. Trotzdem, das eine oder andere ist vielleicht gut zu wissen.

Also,, zunächst wird ein Plugin mit einem Eintrag für das Admin-Menü erstellt. Dazu legt man eine Datei an, die folgendermassen aussieht:

/*
Plugin Name: Stichworttabelle
Description: Erzeugt eine neue Stichworttabelle aus den Titeln der Beiträge (post_title)
Author: Evi Leu
Version: 0.1
*/
    add_action('admin_menu', 'stichworttabelle_plugin_setup_menu');
	
	function stichworttabelle_plugin_setup_menu(){
    add_menu_page( 'Stichworttabelle', 'Stichworttabelle Plugin', 'manage_options', 'stichworttabelle', 'stichworttabelle_init' );
}
 
function stichworttabelle_init(){... HIER GEHTS MIT DER MAIN FUNCTION LOS

Diese Datei kommt in ein eigenes Unterverzeichnis „Stichworttabelle“ im Plugin-Verzeichnis deiner WP-Installation und heißt Stichworttabelle.php. Sie kann jetzt in der Liste der installierten Plugins aktiviert werden. Sie tut zunächst mal nichts ausser einen Eintrag im Admin-Menü zu erzeugen, der heißt „Stichworttabelle Plugin“ und ist erstmal noch eine leere Seite.

Die Menüseite wird in der Funktion function stichworttabelle_init() mit Leben gefüllt, erst kommt ein bisschen Infotex, dann wird der Name der Datenbank ermittelt und ausgegeben:

echo "<h1>Stichworttabelle neu erstellen</h1>";
	echo "Das Plugin hat zwei Funktionalitäten: </br></br>
	1. Diesen Admin-Menüpunkt Stichworttabelle Plugin, in dem die Stichworttabelle neu aufgebaut werden kann.</br>
	Aus Performancegründe und wegen der Runtime-Stabilität wurde die Stichwortbasis in eine externe CSV-Datei ausgelagert. Diese wird neu erstellt, falls sie nicht schon vorhanden ist. Falls sie schon vorhanden sein sollte, wird sie überschrieben. Man kann die Datei beliebig oft neu erzeugen, z.B. wenn es grössere Mengen neuer Beiträge gibt.</br></br>
	
	2. einen Shortcode [stichwortverzeichnis]. der an beliebiger Stelle in einem Beitrag oder einer Seite eingesetzt werden kann und dort ein Stichwortverzeichnis erzeugt.</br></br>";
	global $wpdb;
	
	//Datenbankname ermitteln
	$mydatabase=$wpdb->dbname;
	echo "Sie arbeiten auf der Datenbank: ".$mydatabase."</br>";
	echo "Stichworte werden aus den Titeln ihrer Beiträge erzeugt</br>";

Dann kommt ein kleines Formular, das aus genau einem Button besteht:

//***************Begin Formular
//Formular mit Button
//"
// Stichwortliste Datei neu erzeugen startet die array-Erzeugung fuellen und befüllt die Datei stichwortliste.csv wieder

echo "<form action = '#' method = 'post'>";
	
	echo "<input type='submit' id='el_button2' name='ButtonFuellen' value='Stichwortliste Datei neu erzeugen'>";
	echo "</form>";
	
	if (isset($_POST['ButtonFuellen'])){
			
			return tabelle_fuellen();
		}
//*****************End Formular

Wenn auf den Knopf gedrückt wird, wird die Funktion tabelle_fuellen aufgerufen. Jetzt wirds interessant:

function tabelle_fuellen(){
	
	$neuesArray=array_erzeugen();
	erzeuge_csv($neuesArray);
}

Die Variable $neuesArray wird mit Hilfe der Funktion array_erzeugen() befüllt. Diese erstellt eine Stichwortliste aus den Titeln aller Beiträge in der Tabelle wp_posts, dazu gleich mehr.

Dann wird die Funktion erzeuge_csv aufgerufen, sie kriegt als Parameter unser Array mit und schreibt die Einträge zeilenweise in eine Datei.

Frischauf, wir sehen uns die Funktion array_erzeugen() mal näher an. Der erste Teil mit den nötigen MySQL-Abfragen sieht so aus:

global $wpdb;

//Beginn Originalcode
$table_name = $wpdb->prefix.'posts';

	//Datensätze zählen & Ausgabe Anzahl
	$count_query = "select count(*) from $table_name where post_status='publish' and post_type = 'post'";
	$num = $wpdb->get_var($count_query);
	echo $num."&nbsp Beiträge gefunden</br>";
	
//******************

//Alle Datensätze vom Typ post und published ausgeben
$alleposts = $wpdb->get_results( "SELECT * FROM ".$table_name."
								where post_status='publish' and post_type = 'post' order by post_title");


Das übliche Spiel wenn man die veröffentlichten Beiträge ausgeben will, man braucht in der Where-Klausel die Bedingung post_status=’publish‘ and post_type = ‚post‘. Und zugegeben, man könnte statt select * auch select post_title verwenden, das fällt mir erst jetzt auf.

Jetzt stecken alle veröffentlichten Beiträge als Array in der Variablen $alleposts. Durch dieses Array steppe ich jetzt mit foreach durch und nehme mir die einzelnen Einträge vor, die werden mit Hilfe der Funktion explode() am Leerzeichen gesplittet, mit preg_replace() von Sonderzeichen bereinigt und mit ctype_upper auf Groß/Kleinschreibung überprüft, ich nehme nur die groß geschriebenen Einträge. Das ist willkürlich festgelegt, produziert aber eine sehr brauchbare Stichwortliste. Schließlich wird der gefundene Eintrag mit array_push() in die Variable $stichwortliste weggeschrieben.

$stichwortliste = array(); 
//Durch alle gefundenen Datensätze durchsteppen
$zaehler = 0;
foreach ( $alleposts as $einpost ) 
{ 
  //ersten gefundenen Titel in array aufsplitten
  $liste = explode(" ", $einpost->post_title);
  
  //Durch das Array durchsteppen
   foreach ($liste as $einwort)
  {
	  //Prüfen, ob Wort groß geschrieben ist
	  $wortanfang = substr($einwort,0,1);
	  
	  //Sonderzeichen entfernen (nach Bedarf editieren)
	  $einwort = preg_replace('/[0-9\@\.\;\" "\(\)\:\?\!\,]+/', '', $einwort);
	  
	  //nur ausgeben wenn Groß geschrieben
	  if (ctype_upper($wortanfang)){
		 
		  $zaehler = $zaehler+1;
		  
		  //Hier kommt der Knackpunkt: Neues Stichwort in Array schreiben
		  //***********************************
		  array_push($stichwortliste, $einwort);
		  //***********************************
	  }// ende von ctype_upper
  }// ende von liste as einwort

  
}//ende von alleposts as einpost und array befüllen

Es folgt noch ein bisschen Kosmetik, und ganz am Ende gibt unsere Funktion das gebrauchsfertige Array zurück:

//Dubletten entfernen
$stichwortliste= array_unique($stichwortliste);

//Array sortieren
sort($stichwortliste);

//Ausgabe Anzahlen erzeugter Stichwörter
echo "Anzahl Stichwörter in den Rohdaten: ".$zaehler."</br>";
echo "Grösse des sortierten und Dubletten-bereinigten Arrays: ".count($stichwortliste)."</br>";
echo "<h2>Erzeuge neue Stichwortliste aus der Tabelle: ".$table_name."</h2>";

return $stichwortliste;
}// ende array erzeugen_function

Noch alle mit mir beieinander? Fehlt noch was? Ach ja, die Erzeugung der CSV-Datei mit Hilfe der Funktion erzeuge_csv(), damit halte ich mich jetzt nicht lange auf, die ist einigermassen selbsterklärend:

function erzeuge_csv($liste){
	
	global $wpdb;
	
	echo "Ich erzeuge jetzt ein csv: ";
	
	//***************
	// Verzeichis des aktuellen Plugins ermitteln
	$dir = plugin_dir_path( __FILE__ );
	$aktVerzeichnis = $dir;
	//Dateiname fest verdrahtet	
	$fileName = $aktVerzeichnis.'stichwortliste.csv';
	echo $fileName."</br>";
	
if(file_exists($fileName)){
	echo "Die alte Datei wird überschrieben</br>";
	}
    
	//Gnadenlos überschreiben, der Parameter 'w' ersetzt den alten Dateiinhalt
	
    $csvFile = fopen($fileName,'w');
    $head = ["Wort"];
    fputcsv($csvFile,$head);

// Variable mit den Listeneinträgen befüllen
foreach ($liste as $einwort){
$data = [
    ["$einwort"],
    
];

//Durch alle data-Einträge durchsteppen und in Datei schreiben

foreach($data as $row){
    fputcsv($csvFile,$row);
}
}
fclose($csvFile);

 //Debug-Ausgabe aller Stichworte
$anzahl = sizeof($liste);
echo "<h2>Testausgabe: ".$anzahl." Stichwörter erzeugt</h2>";

foreach ($liste as $stichwort){
	
	echo $stichwort."</br>";
	
}
		
}// Ende function erzeuge csv
//*****************************************

Falls die Datei nicht existiert, wird sie neu angelegt. Falls sie schon existiert, wird der Inhalt überschrieben. So das wars. Jetzt einen Kaffee und sacken lassen. Und dann Hurra auf zu neuen Ufern, jetzt kommt der Teil mit dem Shortcode. Aber dazu gibts einen neuen Beitrag.

Da knarzt es im Gebälk: ich brauche einen PAP für mein Stichwortverzeichnis

Also, ich hab ja jetzt schon ein paar Tage Gehirnschmalz in das Stichwortverzeichnis investiert, und stelle fest dass die Sache schon hübsch komplex wird. Vor allem muss ich mir Gedanken machen, wer was wann macht (machen darf) und was wohin gehört. Ich mach mal ein Brainstorming:

  • es soll ein WordPress-Plugin (PHP) werden, ich möchte ohne Datenimport/Export in MYSQL arbeiten
  • Auf der WordPress-Adminseite soll es einen neuen Menüpunkt geben: „Stichworttabelle neu erstellen“ . Hier soll erst eine Sicherung der alten Stichworttabelle (falls vorhanden) angelegt werden, dann die Tabelle quelle erst geleert und dann mit der aktuell aus der Tabelle wp_posts (Feld wp_title) neu erstellten Stichwortliste neu befüllt werden.
  • Es soll ein Shortcode mitgeliefert werden [Stichwortverzeichnis], der an beliebiger Stelle auf einer Seite oder in einem Beitrag eingefügt werden kann und der da ein komplettes Stichwortverzeichnis (mit Unterseite) generiert.
  • Es soll eine Positiv- und Negativliste geben, für Wörter die auf jeden Fall/auf keinen Fall im Stichwortverzeichnis auftauchen sollen (nice to have)

Ich seh schon, ich muss mich erst mal wieder mit dem good old WordPress auseinandersetzen, das ist verdammt lang her dass ich was mit Plugins und Admin-Menüs gemacht habe. OK, ich geh mal googlen… bis dann!

Update am Montagmittag: nachdem mir der Webserver noch einige Male unter lautem Jubel abgerauscht ist, schmeisse ich den PAP nochmal über den Haufen. Anscheinend sind die vielen PHP-gesteuerten MySQL-Kommandos zuviel für das gute alte WordPress. Ich machs jetzt ganz anders, ich lege die Stichwörter in eine CSV-Datei. Die sollte man eigentlich gefahrlos wieder auslesen können – ich bin da recht vorsichtig geworden.

Update am Montagabend: Das mit dem CSV war der Schlüssel zum Erfolg, jetzt läuft die ganze Chose stabil. Die Erzeugung einer Stichwortdatei aus den Beitragstiteln der wp_posts läuft einwandfrei, und dauert nicht mal lang. Morgen bastel ich dann den Shortcode, der eben jene CSV-Datei wieder ausliest und das Stichwortverzeichnis an beliebiger Stelle in einem Beitrag oder auf einer Seite aufbaut. Mal sehen ob das ohne grössere Unfälle funkt. Hach, Programmieren ist so eine kurzweilige Sache! 😉

Ein ehrgeiziges Projekt: Stichwortverzeichnis

Meine beiden mit Abstand am häufigsten gebrauchten Kochbücher sind „Das Bayrische Kochbuch“ und „Joy of Cooking“. Und bei beiden ist das am Meisten genutzte Feature das Stichwortverzeichnis, da findet man alles! Es eignet sich auch hervorragend zum kreuz- und querschmökern, man findet dabei Rezepte die man sonst nie gesehen hätte. Langer Rede kurzer Sinn, ein Stichwortverzeichnis (Volltext-Index) wäre ein schickes Feature für mein Inselfisch-Kochbuch. Und dazu möchte ich nicht das Stichwort-Feature von WordPress nutzen, das ist mir viel zu umständlich zu bedienen und zu schlecht auszuwerten.

Dazu waren einige Vorüberlegungen nötig. Zunächst muss ich mal festlegen, woher ich die Stichwörter nehme. Ich habe in meinem Inselfisch-Kochbuch knappe 400 Rezepte, in denen relevanter Text in zwei Feldern steht, einmal in post_title und einmal in post_content. Der Titel ist meist zwischen 5 und 10 Wörter lang, der Content kann wesentlich länger sein, bis zu einer ganzen DIN A 4 Seite und mehr, also auf jeden Fall mehr als 100 Wörter. Ich möchte meine Stichwortbasis natürlich maschinell erzeugen, dazu muss ich irgendwie einzelne Wörter aus meiner Datenbasis extrahieren. Dazu muss ich meinen Quelltext aufsplitten (ob mit PHP oder VBA wird sich noch zeigen) und in eine Tabelle schreiben. Diese Tabelle (ich nenne sie mal Rohdaten) soll am Ende nur alle Stichwörter und eine ID (Autowert) enthalten. Man sieht schon: mit dem Content, das wird uferlos, das können leicht mehrere Zehntausend Wörter werden. Ich beschränke mich also auf die Wörter aus dem post_title, das ist besser zu handeln. Wir machen das mal als erste Annäherung und schauen uns dann an, was wir mit den extrahierten potentiellen Stichworten anfangen können.

Wie ich das in MS Access angehe: ich importiere mir die gesamte Tabelle wp_posts aus dem Original-Inselfischkochbuch über CSV-Export aus phpmyadmin. Dann schreibe ich mir eine Abfrage,, die nur den post_title enthält und als where-Klausel post_Type = post und post_status = publish bekommt, damit ich nur die echt veröffentlichten Rezepte in der Datenbasis habe. Die Abfrage heißt quelle und sieht so aus:

Screenshot quelle

265 Datensätze a drei bis zehn Wörter, damit kann man arbeiten. Ich lege ausserdem fest, dass ich nur Großgeschriebene Wörter im Stichwortverzeichnis haben möchte. Das ist willkürlich, aber doch recht sinnvoll, weil damit die ganzen kleinen Füllwörter rausfallen.

Dann gehts rund: Ich lege mir eine Tabelle namens ziel an, die nur zwei Felder hat: ID(AutoWert) und Wort(Text). Sie bleibt zunächst leer. Dann bastle ich mir ein VBA-Modul. Hier lege ich zwei Recordsets an, rstquelle das ist die Abfrage Quelle, und rstziel, das ist die Tabelle Ziel.

Jetzt gehe ich zum ersten Datensatz in rstquelle und lese mir den Inhalt des Feldes post_title ein. Dann verwende ich die VBA-Funktion split(), die zerlegt das Feld in einzelne Wörter, die in ein Array geschrieben werden.  Ich laufe durch dieses Array und prüfe zunächst, ob das Wort Groß oder klein geschrieben ist:

Asc(Left(liste(i), 1) >= 65) And (Asc(Left(liste(i), 1)) <= 90)

Mit dieser Funktion bin ich nicht so recht glücklich, weil sie unerklärlicherweise manche Wörter mit Kleinbuchstaben doch durchrutschen läßt, aber ich hab noch nichts besseres gefunden.

Dann werden noch evtl vorhandene Sonderzeichen entfernt, dazu gibts eine Funktion die Folgende Zeichenkette durchläuft:

Const strSonderzeichen As String = „.,:;#+’*?=)(/%$§!~\}][{“

Dann schreibe jeweils ein gefundenes, geputztes Wort in die Zieltabelle. Dann gehe ich zum nächsten Datensatz der Quelltabelle und wiederhole den Vorgang. das mache ich, bis EOF der Quelltabelle erreicht ist.

Hurra! 669 Datensätze, beim ersten Drüberschauen sieht es schon mal ganz gut aus. Noch die Dubletten ausblenden, das geht mit einer Abfrage mit Gruppierung ganz easy. Sortieren, man sieht noch ein bisschen Datenschmutz ganz oben, das bereinigt man per Hand.

abfrage quelle

Es bleiben 496 recht manierliche Stichworte übrig. Damit könnte ich jetzt schon nach MySQL und WordPress gehen und die Webseite aufbauen, aber ich halte mich noch ein wenig in Access auf und teste nochmal, mit der „wackeligen“ Asc-Funktion bin ich nicht zufrieden.

WordPress 5.0 und Gutenberg – der erste Eindruck

Was soll ich sagen? Gerade WordPress 5.0 installiert, und gleich beim ersten Versuch mit dem neuen Editor Gutenberg einen Bug produziert. Ich hab einfach mal rumgeklickt und einen „Drop Cap“ angewählt, also ein Initial, und dazu eine Hintergrundfarbe. Das sah dann erstmal so aus:

dropcap_bug

dropcap_bug

Ist jetzt irgendwie nicht so ideal, oder?

Das neue Theme Twenty Nineteen ist ausserdem so ziemlich das häßlichste Theme, das mir je untergekommen ist. Das Design ist absolut grottig, die Schriften sind für meinen Geschmack lieblos zusammengeklatscht, und statt eines schönen Titelbilds ist nur ein minikleines rundes Logo vorgesehen. Die Startseite sieht dann z.B. so aus:

schriften

schriften

Weiter unten ist es auch nicht schöner, der Widget-Bereich ist vom Layout her so schön wie eine billige Einwurfzeitung:

widgetarea

widgetarea

Dann wollte ich ein Bild einfügen – hab erstmal nur die Option „Beitragsbild“ gefunden, das stellt sich dann so dar, blaugetönt und über die ganze Seite ausgebreitet:

beitragsbild

beitragsbild

Finde ich jetzt auch nicht wirklich prickelnd…

Aber ein Theme kann man wechseln, ich hör da mal auf zu meckern und nehm das Twenty Sixteen, damit bin ich eigentlich immer gut gefahren. Wollen doch mal sehen, wie sich der neue Editor benimmt.

Ich möchte gerne eine Liste mit Bullets, erster Ansatz: ich schreib mal meine Listenpunkte untereinander hin, mach jeweils ein Return am Ende. Und jetzt? Noch nichts weiter in Sicht. Ich markiere mal meine drei Listenpunkte, dann ändert sich das Bild. Anscheinend wird für jeden Listenpunkt ein Block angelegt.

drei_blocks

drei_blocks

Ah, guxtu! Wenn man auf das Paragraph-Zeichen drauffährt, kommt auch ein Tooltip, der sagt „Change Block Type“, und hier kriege ich schließlich die Auswahl Liste oder Zitat:

transform_to_list

transform_to_list

Ah, geschafft! Anscheinend brauche ich für jeden Listenpunkt einen eigenen Block, so läuft der Hase.

liste

liste

Dann werde ich wohl für ein Bild auch einen eigenen Block brauchen, schätze ich mal. Ich mach da mal unterhalb der Liste weiter. Wenn man da ganz genau hinguckt, aber wirklich ganz genau, sieht man drei ausgegraute Icons, das mittlere davon könnte evtl. für ein Bild sein:

graue_icons

graue_icons

Sehen sie die Icons in der rechten unteren Ecke? Also, ohne Brille hätte ich da keine Chance. Na gut, klicken wir mal auf das Bild-Icon. Hurra, da kommt der Media-Uploader!

media_uploader

media_uploader

Wenn ich das Bild eingefügt habe, erscheinen rechts im Editorfenster die Bildeigenschaften, das ist OK:

bildeigenschaften

bildeigenschaften

Wenn ich jetzt rechts neben dem Bild Text weiterlaufen lassen will, geht das wieder nur mit einem neuen Block. Hier vermisse ich die Oprion „Als Text einfügen“, die hab ich einfach nicht gefunden. Wenn ich jetzt z.B. aus Word einen Text mit einer Überschrift reinkopiere, baut er mir gleich wieder zwei Blocks, einen für die Überschrift und einen für den Textkörper. Langsam wirds hier unübersichtlich. Ausserdem fehlen im Text etliche Leerzeichen, das ist nicht schön:

leerzeichen_fehlen

leerzeichen_fehlen

Jetzt möchte ich gern noch ein Video einfügen, also frisch auf, ein neuer Block. Klick auf das Icon „Add file“, dann gehts wieder in die Mediathek oder zum Upload und wird defaultmässig zum Download angeboten, das ist ganz OK.

file_download

file_download

Man kann aber auch mit „Change Block Type“ das ganze in ein eingebettetes Video konvertieren, wer das möchte ist auch gut bedient.

Ich lasse es hier mal gut sein, für einen ersten Eindruck reicht das. Das man für jeden Pfiffkaas einen eigenen Block braucht, finde ich dann doch etwas gewöhnungsbedürftig. Man hat dann quasi den Bildschirm voll mit lauter kleinen spezialisierten Editorfenstern, die einem immer nur die Optionen anbieten, die für den jeweiligen Blocktype gültig sind. Na ja. Das kann man mögen oder nicht, ich finde es ziemlich gewöhnungsbedürftig. Was mich definitiv stört: ich bin mehrfach in eine „Keyboard Trap“ gefallen, wo die Tab- und Pfeiltasten nicht mehr so durch den Artikel navigieren, wie man es erwarten würde. Das ist natürlich total grottenschlecht für Benutzer, die Gutenberg nicht mit der Maus, sondern über die Tastatur bedienen möchten. Aber das geht schon stark ans Thema Barrierefreiheit, und sprengt den Rahmen dieses ersten subjektiven Eindrucks.  Mein Fazit: geht so. Ich sehe keinen großen Vorteil im Block-Konzept, aber man kanns wahrscheinlich doch recht schnell lernen. Man kann mit Gutenberg arbeiten, aber wo der grosse bahnbrechende Innovationsvorsprung liegt, hat sich mir nic.ht erschlossen.

Wie lange braucht man, um eine neue Programmiersprache zu lernen?

Das selbsternannte Javascript-Genie

Ich hatte mal einen Teamkollegen in einem sehr explosiven Projekt, der hielt sehr grosse Stücke auf sich. Er codierte ellenlange Module, war ein furchtbarer Geheimniskrämer und ließ sich nicht in die Karten schauen. Er war auch kein Teamplayer, und seine Codeschnipsel arbeiteten nie so mit den Codeschnipsel der anderen Teamkollegen zusammen, dass man sie verwenden konnte. Ich musste eines Tages an einem Algorithmus mit ihm zusammenarbeiten, und das war eine mittlere Katastrophe. Er verkündete: „Ich habe mir Javascript selbst beigebracht, deswegen bin ich so erfolgreich und kann von meinem Know-How in diesem Job gut leben! Ich teile mein Wissen nicht mit dir, schau wie du zurechtkommst!“ und schnappte zu wie eine beleidigte Auster.

Ich schrieb mir dann die notwendigen Routinen selber, statt mich mit seinem Spaghetti-Code herumzuschlagen, und brachte mir dafür ebenfalls Javascript selber bei – in ein paar Tagen, das hat keine Woche gedauert. Warum ich das erzähle? Weil es mich immer wieder erstaunt, dass es Leute gibt die tatsächlich nur eine einzige Programmiersprache beherrschen und sich doch als Developer auf dem Markt behaupten können. Und weil es mich auch immer wieder noch mehr erstaunt, welches Brimborium verantaltet wird, wenn es darum geht, eine neue Programmiersprache zu erlernen.

Gutenberg und React.js

Nehmen wir nur mal als Besipiel den Zinnober, der um den neuen WordPress Editor Gutenberg gemacht wird. Der ist komplett neu programmiert worden, in React.js. Ich habe (noch) keine Ahnung von React.js, vielleicht handelt es sich ja wirklich um eine sehr schwierig zu erlernende und komplizierte Sprache… aber ich schweife ab.

Was ich eigentlich erzählen wollte: als WordPress Accessibility Team Lead Rian Rietveld kürzlich ihren Rücktritt wegen der Querelen um Gutenbergs schlechtes Abschneiden in den Accessiility Audits erklärte, nannte sie als eine der Hauptschwierigkeiten, dass es im Accessibility Team niemanden gab, der sich mit React.js auskannte, und es in der knappen Zeit auch nicht möglich war, einen externen React-Programmierer anzuheuern.

Was kann denn da so schwierig sein?

Ja Donnerlittchen, dachte ich mir, dieses React muss aber ein harter Brocken sein. Ich meine, wenn ich ein Projekt in einer neuen Programmiersprache vor die Nase gesetzt bekomme, hocke ich mich ein paar Tage auf den Hosenboden und arbeite mich da ein, und gut ists.

Ich lerne jetzt seit bald 30 Jahren regelmäßig neue Programmiersprachen, und die Hauptschwierigkeit dabei ist, dass die Syntax von Sprache zu Sprache ein bisschen unterschiedlich ist und man hier ein einfaches oder ein doppeltes Hochkomma, da ein Komma oder ein Semikolon, und dort eine eckige oder geschweifte Klammer braucht.

Aber die Sprachelemente sind fast überall gleich oder zumindest sehr ähnlich. Datentypen sind Datentypen, ein Array ist ein Array, ein Objekt ist ein Objekt, und all die FORs, WHILEs, SWITCHes und wie sie alle heissen, folgen in allen Programmiersprachen der selben Logik. Wenn man die Grundlagen einmal draufhat, ist es auch nicht weiter schwer, sich die Semantik einer neuen Programmiersprache einzuverleiben, die Konstrukte gleichen sich ja doch.

Wieso zum Dunnerkeil hat sich also nicht jemand aus dem Accessibility Team hingesetzt und sich dieses verflixte React.js schnell mal reingezogen? Ich kann es mir nur so erklären: das sind wohl alles keine Programmierer, sondern „nur“ Barrierefreiheits-Experten, die mit Codierung nichts am Hut haben. Denn für einen alter Programmierer ist es eine der leichteren Übungen noch eine Programmiersprache zu lernen, egal wie modern und hyper die auch immer sein mag.

Wenn mich der Teufel reitet, ziehe ich mir mal auf FreeCodeCamp die React-Challenges rein, und ich wette dass ich damit in wenigen Tagen durch bin und dann sehr wohl weiß, was React macht und tut und wie man es anwendet. Echte Programmierer sind nämlich keine One-Trick-Ponys, sondern immer auch ein bisschen Universalgenies. Aber das ist unser Betriebsgeheimnis …

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.

 

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!