Archiv der Kategorie: Shortcodes

Shortcodes: echo vs. return

Ich arbeite ja gern mit Shortcodes und packe da auch oft komplexere Funktionalitäten rein, weil sie so praktisch sind. Wenn man allerdings Shortcodes in Beiträge einbinden will, die auch noch Text enthalten, muss man ein bisschen aufpassen mit den Ausgaben, wo man echo und wo man return verwendet, sonst kann es zu unerwünschten Effekten kommen. Ich mach mal ein einfaches Beispiel.

Simpler Shortcode mit return:

function el_harmlosertext(){
    return "<strong>Ich bin ein komplett harmloser ShortcodeText</strong>";
}
add_shortcode('harmlos','el_harmlosertext');

Den kann man im Fliesstext platzieren wo man will, er wird an der richtigen Stelle ausgeführt. Im Editor sieht das so aus:

editor

Das erzeugt diese Bildschirmausgabe:

bildschirm

Ändert man jedoch den Shortcode und macht aus dem return ein echo, funktioniert das nicht mehr, die Ausgabe erfolgt vor dem Fliesstext des Artikels.

vor_fliesstext

Das ist etwas irritierend, und komplett lästig wird es, wenn man zum Beispiel die Ergebnisse einer Datenbankabfrage ausgeben möchte, die nicht so ohne weiteres in ein return-Statement zu packen sind. Ich stricke mal eine kurze Liste aller bisher veröffentlichten Posts, und möchte diese am Ende meines Beitrags ausgeben. Der Shortcode sieht erstmal so aus:

function el_mit_datenbankabfrage(){
    
     global $wpdb;
            
      //Bisherige Anzahl posts holen
        $alleposts = $wpdb->get_results( "SELECT * from wp_posts where post_status like 'publish'");
        $anzahl = $wpdb->num_rows;
        echo $anzahl." Datensätze gefunden und mit echo ausgegeben<br>";
        $ausgabe = array();
        $i=0;
        foreach($alleposts as $einpost){
            echo $einpost->post_title."<br>";
            
        }
       
}
add_shortcode('db_abfrage','el_mit_datenbankabfrage');

Hier kann man das echo nicht einfach mit einem return ersetzen, weil sonst der foreach nach dem ersten Durchgang abbricht. So lassen kann man es aber auch nicht, weil die Liste so wie der Shortcode jetzt aussieht immer vor dem Fliesstext des Artikels ausgegeben wird:

echo_vor_text

Abhilfe: wir packen die Ausgaben des foreach in einen String und verketten den innerhalb der Schleife. Die Funktion des Shortcodes wird wie folgt geändert:

function el_mit_datenbankabfrage(){
    
     global $wpdb;
            
      //Bisherige Anzahl posts holen
        $alleposts = $wpdb->get_results( "SELECT * from wp_posts where post_status like 'publish'");
        $anzahl = $wpdb->num_rows;
        echo $anzahl." Datensätze gefunden und mit echo ausgegeben<br>";
        $ausgabe = "";
       
        foreach($alleposts as $einpost){
            $ausgabe=$ausgabe.$einpost->post_title."<br>";
            
        }
        
    return "Mit return ausgegeben:<br>".$ausgabe;
}

Diesen String gebe ich dann mit dem return der Shortcode-Funktion zurück, und meine Liste wird brav ans Ende des Beitrags gestellt, da wo ich sie auch haben will.

return

Ich könnte die Ausgabe auch mitten im Text platzieren, funktioniert auch. Man sieht hier auch noch, dass die mit echo ausgegebene Anzahl der Datensätze gnadenlos vor dem Beitragstext landet:

mitten_im_text

Das ist alles natürlich nur relevant, wenn man den Shortcode auf einer Seite oder auf einem Beitrag platzieren möchte, die sonst auch noch Text enthalten, bei sonst leeren Posts/Pages ist es egal. Wissen muss man halt, dass return und echo hier völlig unterschiedliche Effekte in der Ausgabe erzielen, dann kann man auch gegensteuern.

Rezeptecounter revisited: für WordPress-Puristen

Ich arbeite ja gern mit eigenen Tabellen, aber die WordPress-Puristen schreien da immer gleich Zetermordio und wollen eine WordPress-konforme Lösung sehen. Deswegen stricke ich die Logik für das Wegschreiben des Rezeptezählers nochmal um und verstaue die relevanten Daten in der wp_options. Ich habe zu jedem Datensatz drei relevante Kennzahlen: die ID des Rezeptes, den Titel und den Zählerstand – wobei man den Titel auch nachträglich über die ID dazujoinen könnte, der ist hier eigentlich redundant. Diese drei packe ich in ein Array, und mit diesem Array füttere ich die Option. Das Ganze sieht dann so aus:

function el_rezeptcounter() {
 
 if(is_single()) {
 
 //id und titel abholen
 $akt_id = get_the_id();
 $akt_titel = get_the_title();
 
 //option nachschauen
 $meineOption = get_option('zaehler_'.$akt_id.'');
 $o_zaehler = $meineOption['zaehler'];
 
 if ($o_zaehler == ''){$zahl = 0;}else{$zahl = $o_zaehler;}
 
 echo "Dieses Rezept wurde bisher ".$zahl." mal aufgerufen";
 
 if($o_zaehler == ''){
 
 //neu eintragen
 $myOptions = array(
 'zaehler' => 1,
 'id' => $akt_id,
 'titel' => html_entity_decode($akt_titel)
 );
 
 update_option('zaehler_'.$akt_id, $myOptions);
 
 }else{
 
 //Zähler updaten
 $o_zaehler = $o_zaehler +1;
 
 $myOptions = array(
 'zaehler' => $o_zaehler,
 'id' => $akt_id,
 'titel' => html_entity_decode($akt_titel)
 );
 
 update_option('zaehler_'.$akt_id, $myOptions); 
 }
 
 } //End von if( is_single)
 
}

Genau genommen könnte man sich die if-else-Konstruktion sparen und in jedem Fall einen Update mit Zähler+1 machen, da WordPress mit update_option die Option neu anlegt, falls sie noch nicht existieren sollte.

WordPress macht aus den Arrays serialisierte Strings, da sieht dann der option_value zum Beispiel so aus:

a:3:{s:7:"zaehler";i:4;s:2:"id";i:1392;s:5:"titel";s:20:"Test für Backwerk";}

Das kann man Klartext lesen:

a für Array, Länge drei{s für string: Länge7:wert „zaehler“; i für integer:Wert 4…

… und so weiter. Um jetzt zum Beispiel an den Wert des Zählers heranzukommen, verwendet man folgende Syntax:

$meineOption = get_option('[name_der_option]');
 $zaehler = $meineOption['zaehler'];

Da $meineOption hier ein Array zurückgibt, könnte man auch über die Einträge iterieren und alle ausgeben, wenn man es braucht.

Jedenfalls haben wir jetzt unsere relevanten Daten WordPress-konform in der wp_options gespeichert. Wie aber kommen wir jetzt an die Auswertung? Mit einem SQL sind die serialisierten Werte nicht zu packen, da muss eine andere Lösung her. Na ja, pack’mas.

Auswertung des Rezeptecounters aus der wp_options

Dafür holt man sich mit einem Select.. WHERE option_name like ‚zaehler_%‘ alle relevanten Einträge aus der wp_options. Die Werte kann man schon mal mit einem foreach ausgeben:

function el_opcounter_hitparade(){
 
 //Bisher gespeicherte Rezepte holen
 global $wpdb;
 $alleposts = $wpdb->get_results( "SELECT * from iii_wpoptions where option_name like 'zaehler_%'");
 $anzahl = $wpdb->num_rows;
 echo "Anzahl gefunden= ".$anzahl."<br>";
 
 
 foreach($alleposts as $einpost){
 
 //Optionswerte auslesen 
 $meineOption = get_option($einpost->option_name);
 $o_zaehler = $meineOption['zaehler'];
 $o_titel = $meineOption['titel'];
 $o_id = $meineOption['id'];
 echo $o_id." ".$o_titel." ".$o_zaehler."<br>";
 }
 
}

Damit kriegt man schon mal die Liste.

unsortiert

Die hätte ich jetzt aber gern nach der Anzahl der Aufrufe absteigend sortiert, aber hier geht nix mit Order by, mit SQL ist das leider nicht zu packen. Das muss mit PHP, und das ist nicht ohne, dafür muss man einen multisort bemühen. Für den lesen wir unsere Daten in ein Array ein, das machen wir so:

Einlesen der Rohdaten in ein Array

Dafür kann unser Select nochmal herhalten:

//Bisher gespeicherte Rezepte holen
 global $wpdb;
 $alleposts = $wpdb->get_results( "SELECT * from iii_wpoptions where option_name like 'zaehler_%'");
 $anzahl = $wpdb->num_rows;
 echo "Anzahl gefunden= ".$anzahl."<br>";
 
 $rohdaten = array();
 $i=0;
 foreach($alleposts as $einpost){
 
 //Optionswerte auslesen 
 $meineOption = get_option($einpost->option_name);
 $o_zaehler = $meineOption['zaehler'];
 $o_titel = $meineOption['titel'];
 $o_id = $meineOption['id'];
 //debug unsortierte Ausgabe
 //echo $o_titel." ".$o_zaehler."<br>";
 
 //Array befüllen
 $rohdaten[$i]['zaehler']= $o_zaehler;
 $rohdaten[$i]['titel']= $o_titel;
 $rohdaten[$i]['id']= $o_id;
 $i=$i+1;
 }

Jetzt wirds ein bisschen tricky. Ich hab mir folgende Lösung ergooglet:

Array als Parameter für den multisort

Unsere Daten stecken jetzt in dem Array $rohdaten. Jetzt brauchen wir aber noch ein zweites Array, um den array_multisort (s. PHP-Handbuch) damit zu bedienen, und zwar muss dieses die Spalte enthalten, nach der sortiert werden soll. Das Ganze sieht dann so aus:

$counter = array();
foreach ($rohdaten as $key => $row)
{
 $counter[$key] = $row['zaehler'];
}
array_multisort($counter, SORT_DESC, $rohdaten);

Damit werden die Rohdaten nach dem Zähler sortiert, und zwar DESC also absteigend. Jetzt können wir die ganze Chose als Hitparade ausgeben:

foreach($rohdaten as $roh){
 
 echo $roh['titel']." (".$roh['zaehler'].")<br>";
 
 }

Das sieht jetzt schon ganz gut aus.

hitparade

Natürlich kann man auch hier anhand der Rezept-IDs einen Link zum Rezept mit dem get_permalink einbauen, aber das spare ich mir jetzt. ~~Wenn man nur die ersten X Rezepte ausgeben möchte, den SQL um ein LIMIT X ergänzen.~~ Achtung, Denkfehler! Das klappt natürlich nicht, da der Select die Daten nicht vorsortiert ausgeben kann. Da muss man dann nur die ersten X Zeilen des Arrays ausgeben, sonst wird das nix. Ich pack das Ding doch noch in ein Widget mit Benutzereingabe für die X auszugebenden Rezepte! Kurze Lösung: man verwendet ein array_slice:

$hilf = array_slice($rohdaten, 0, 3);
foreach($hilf as $roh){
        
            echo $roh['titel']." (".$roh['zaehler'].")<br>";
            
            }

Ich finde den Aufwand zum Auswerten der serialisierten Daten schon recht kopflastig, das geht über die eigene Tabelle wesentlich komfortabler. Na ja, kann jeder selber entscheiden, welche Lösung er einsetzen möchte.

Noch eine Anmerkung am Schluss

Ich bin gefragt worden, warum ich den Code für das Wegschreiben des Rezeptezählers nicht in einen Filter gepackt habe, sondern als Shortcode in die single.php eingefügt habe. Das hat einen guten Grund: ich habe mit komplexeren Filtern bei WordPress schon schlechte Erfahrungen gemacht, insbesondre bei eingebauten Datenbankabfragen kann es da zu kuriosen Nebenwirkungen kommen. Jedenfalls ist der Shortcode-Aufruf in der single.php eine unkomplizierte Lösung und liefert korrekte Ergebnisse, damit kann ich ganz gut leben.

Alternative zum Besucherzähler: der Rezeptecounter

Tscha, der nette kleine Visitor Counter auf meinen Webseiten musste leider weg, weil der die IP-Adressen der Besucher bunkert, und das ist nach der neuen Datenschutz-Verordnung nicht mehr erlaubt, IP-Adressen zählen als schutzwürdige persönliche Daten und dürfen nicht mehr ungecrypted gespeichert werden. Mich interessiert aber trotzdem, was die Besucher auf meinen Seiten anzieht, und ich hab mir fürs Inselfisch-Kochbuch eine „kleine“ Alternative gebastelt.

Rezeptecounter ganz minimalistisch

Eigentlich ist es für mich am Interessantesten, welche Rezepte am öftesten aufgerufen werden, die Aufrufe der wenigen statischen Seiten interessieren mich eher weniger. Das könnte ich mir zwar aus den Logfiles meines Providers herausfieseln, aber der Aufwand ist doch relativ hoch. Das geht auch einfacher, dachte ich mir, da klemme ich eine kleine PHP-Funktion ans Ende jedes Rezeptes und schreibe mir die Aufrufe in eine eigene Tabelle. Damit habe ich eine prima kleine Rezepte-Hitparade und kann z.B. die 10 beliebtesten Rezepte ausgeben oder sonstwas damit anstellen.

Damit kann ich in der single.php ansetzen und mir da einen kleinen Zähler einbauen, der mir in die Datenbank bunkert wie oft das jeweilige Rezept schon aufgerufen wurde. Die Funktion kommt in einen Shortcode, und der wiederum kommt in ein Plugin, der Plugin-Aufruf kommt ins Child-Theme in die single.php nach dem Content.

Die Tabelle counter

ist ganz einfach strukturiert:

tabelle_counter

Eine Autowert-ID, und drei Felder für Rezept-ID, Titel und der Zähler für die Aufrufe, das wars schon.

Die Funktionalität des Shortcodes

… ist auch nicht weiter kompliziert. Ich hole mir ID und Titel des aktuellen Rezeptes ab und gehe mit der ID auf die Tabelle counter. Falls die ID da noch nicht vorhanden ist, mache ich einen Insert, falls sie schon da ist, setze ich den Zähler um eins hoch und mache einen Update. Das wars schon!

function el_rezeptcounter() {
    
  if(is_single()) {
      
      //id und titel abholen
      global $wpdb;
      $akt_id = get_the_id();
      $akt_titel = get_the_title();
      
      //Bisherige Anzahl holen
        $alleposts = $wpdb->get_results( "SELECT * from counter where rezeptid = ".$akt_id."");
        $anzahl = $wpdb->num_rows;
        
        $zaehler = 0;
        foreach($alleposts as $einpost){
            $zaehler = $einpost->zaehler;
        }
        
        echo "Dieses Rezept wurde bisher ".$zaehler." mal aufgerufen";
        
        if($anzahl == 0){
            
            //Neuen Aufruf eintragen
            $wpdb->insert('counter', array(
            'rezeptid' => $akt_id,
            //Sonderbehandlung für - und " usw.
            'titel' => html_entity_decode($akt_titel),
            'zaehler' => 1
            ));
            
        }else{
            
            //Zähler updaten
            $zaehler = $zaehler +1;
            
            $wpdb->update( 
                'counter', 
                array( 
                    'zaehler' => $zaehler  // int
                  ), 
                array( 'rezeptid' => $akt_id )
            );
                    
        }
        
  } //End von if( is_single)
  
}
add_shortcode ('counter', 'el_rezeptcounter');

Dabei kann man sich überlegen, ob man bei der Ausgabe der bereits erfolgten Aufrufe bei 0 oder bei 1 das zählen anfängt, das ist Geschmackssache. Korrekter ist es wahrscheinlich, mit dem aktuell erfolgten Aufruf bei 1 anzufangen, Dann sähe die Zeile mit dem Zähler für die Ausgabe so aus:

if ($o_zaehler == ''){$zahl = 1;}else{$zahl = $o_zaehler+1;}

Den html_entity_decode($akt_titel) brauchts, weil ich in meinen Titeln auch mal Zeichen wie – oder “ verwende, damit das in der Datenbank sauber ankommt.

Der Aufruf des Shortcodes in der single.php

… wird nach Wunsch vor oder nach dem Content platziert:

       <!--Shortcode für den Rezepte-Counter-->
       <?php echo do_shortcode("[counter]"); ?>

Und so sieht die Ausgabe aus:

4malaufgerufen

Update und Tipp:

Man kann die Counter-Funktionalität statt in einen Shortcode auch in einen Filter packen. Ich bin zwar mit komplexen Filtern in WordPress schon manchmal auf die Nase gefallen, aber hier scheint es stabil zu funktionieren. Der Code bleibt gleich, nur setze ich dann den Filter auf the_content:

function el_rezeptcounter($content) {
    
  if(is_single()) {
  ...
  ...(Hier kommt der Code wie oben)
  ...
      .
  } //End von if( is_single)
  return $content;
}
add_filter( 'the_content', 'el_rezeptcounter' );

Damit kann man sich den Umbau der single.php sparen.

Die Counter-Tabelle

Die Tabelle counter ist sehr übersichtlich, man kann sie sich gleich mal nach dem Zähler sortieren und sieht sofort, welche Rezepte die meisten Aufrufe haben.

counter_mit_eintraegen

Das kann man natürlich hübsch für eine Ausgabe z.B. als Rezept-Hitparade verwenden, dafür basteln wir uns:

Den Hitparaden-Shortcode

kann man sich selber dahin platzieren wo man ihn am liebsten hat, die Konstruktion ist denkbar einfach:

function el_rezepthitparade(){
    global $wpdb;
    echo "<h2>Die beliebtesten Rezepte</h2>";
    $alleposts = $wpdb->get_results( "SELECT * FROM counter ORDER BY zaehler DESC");
    foreach ($alleposts as $einpost){
        
        echo $einpost->titel." (".$einpost->zaehler.")<br>";
    }
}
add_shortcode('hitparade','el_rezepthitparade');

Ausgabe:

diebeliebtestenzezepte

Man kann jetzt noch die Anzahl der ausgegebenen Zeilen mit einem LIMIT steuern, aber man kann auch noch ganz was anderes machen, nämlich das Ganze in ein Widget packen und die Anzahl der auszugebenden Zeilen als Benutzereingabe abfragen. Aber das ist dann doch recht aufwendig, ich nehme hier mal lieber eine kleine Lösung:

Shortcode in Text-Widget packen

Dafür zieht man sich einfach ein Text-Widget an die passende Stelle und gibt hier nur den Shortcode ein, z.B.

Die beliebtesten Beiträge

Ein kleiner Chat in PHP – wieder mal was für Minimalisten (6243)
Noch mehr postmeta: benutzerdefinierte Felder in wooCommerce (4199)
Kraut und Rüben auf der Datenbank: wo wooCommerce die Produktdaten speichert (4077)
Kontrastfarbe automatisch berechnen mit jquery/Javascript (3994)
Joomla-Template 2: die index.php (3965)
Schmankerl für alte Datenbanker: Zugriff auf externe Daten mit dem wpdb-Objekt (3776)
Alphabetische Paginierung aus Array: die Tücken des PHP-sort() (3207)
Ein einfaches Joomla-Template erstellen (2741)
PHP 5.6 forever? (2727)
HTML5 Datalist Value – ganz so einfach ist es nicht (2689)
. Wenn das nicht funktioniert, sind die Shortcodes für Textwidgets noch nicht enabled, das geht aber mit einer Zeile im Plugin oder in der functions.php des Child-Themes:

add_filter('widget_text', 'do_shortcode');

Das sollte es gewesen sein. Wir hübschen die Ausgabe noch mit Links zu den Rezepten auf, das ist auch nicht weiter schwierig, wir haben ja die IDs und packen das mit in den foreach:

foreach ($alleposts as $einpost){
        
        $pfad = get_the_permalink($einpost->rezeptid);
        echo "<a href = '".$pfad."'>".$einpost->titel."</a> (".$einpost->zaehler.")<br>";
    }

Jetzt ist es aber schön genug!

widgetmit_links

Nachschlag für WordPress-Puristen

Ich bin darauf hingewiesen worden, dass man die Anzahlen der Rezeptaufrufe auch in der wp_options speichern könnte, das wäre die sauberere Lösung. Ja bittesehr, kann man, ist nicht besonders schwierig. Man muss sich halt überlegen, wie man die Options benennt, damit man sie nachher auch auswerten kann. Ich hab da mal einen Versuch gemacht und die Optionsnamen nach dem Muster zaehler_[beitragsid] zusammengeschraubt. D:ie Funktion zum Wegschreiben ist recht übersichtlich geworden:

function el_rezeptcounter() {
    
  if(is_single()) {
      
      //id und titel abholen
      $akt_id = get_the_id();
      $akt_titel = get_the_title();
      
      //option nachschauen
      $o_zaehler = get_option('zaehler_'.$akt_id.'');
        
        if ($o_zaehler == ''){$zahl = 0;}else{$zahl = $o_zaehler;}
        
        echo "Dieses Rezept wurde bisher ".$zahl." mal aufgerufen";
        
        if($o_zaehler == ''){
            
            update_option('zaehler_'.$akt_id, 1);
            
        }else{
            
            //Zähler updaten
            $o_zaehler = $o_zaehler +1;    
            update_option('zaehler_'.$akt_id, $o_zaehler);        
        }
        
  } //End von if( is_single)
  
}

Man kann hier ohne Gefahr update_option() verwenden, da es eine Option einfach neu anlegt, falls sie noch nicht vorhanden sein sollte. Das funktioniert soweit ganz gut und hat hier zum Testen etliche Einträge korrekt in meiner wp_options hinterlassen:

wp_options

Eine Übersicht bekäme man im ersten Ansatz mit diesem Select heraus:

( "SELECT * from wp_options where option_name like 'zaehler_%' 
ORDER BY option_value DESC");

Was mir an dieser Lösung allerdings nicht gefällt: wie wertet man das jetzt aus und kriegt die Rezepttitel mit zu den Zählerständen? Als Optionsnamen nur die Rezept-ID allein (ohne das zaehler_ vorneweg) zu vergeben wäre ein Lösungsansatz, aber das gefällt mir nicht so recht.

Man könnte natürlich in den option_value ein Array mit ID, Zähler und Titel packen und WordPress die Daten serialisieren lassen (hier bei wpengineer.com ein nettes Tutorial zu dem Thema), aber das ist mir eigentlich zu umständlich, da hat man dann das G’frett damit, die Daten wieder einzeln rauszufieseln. Da bleibe ich lieber bei meinem „kurzen Dienstweg“ mit der eigenen Tabelle.

Update

Ich bin gefragt worden, ob ich nicht ein Beispiel für das Wegschreiben der Options als Array bringen könnte. Ja OK, machen wir, aber dazu gibts einen neuen Beitrag.

WordPress und AJAX für Autocomplete – eine erste Annäherung

Einleitung

Ich hab mich kürzlich in einem Projekt mal ein bisschen mit den Grundlagen von AJAX beschäftigt, und finde es bietet wirklich faszinierende und in der Praxis gut anwendbare Möglichkeiten. Besonders g’wandt ist die Möglichkeit, zum Suchen bestimmter Datenbankeinträge ein Autocomplete oder Auto-Vervollständigen einzubauen. Der Benutzer tippt ein paar Buchstaben (in der Regel drei) in ein Textfeld ein, und man holt via AJAX die gematchten Einträge aus der Datenbank. Das, so hab ich mir gedacht, hätte ich gerne für eine komfortable Suche nach Rezepten im Inselfisch-Kochbuch, das sind nämlich mittlerweile über dreihundert und somit zuviel für ein Dropdown-Feld. Das könnte in etwa so aussehen:

form_leer

Man stellt ein kleines Formular zur Verfügung, in das der Benutzer Text eingeben kann. Sobald in der Datenbank passende Einträge gefunden werden, werden diese als Auswahlliste angezeigt. Ich geb mal sal ein, hier ist das Ergebnis:

suche_sal

Das ist doch schon mal ganz schick, oder? Und nicht über die Nummern (#152) wundern, die brauchen wir später noch. Wenn der Benutzer einen Eintrag ausgewählt hat und auf Return drückt, soll dann das Rezept angezeigt werden, aber bis dahin ist es noch ein Stückchen weit. WordPress stellt nämlich eine ganz eigene Logik für die Verwendung von AJAX zur Verfügung, und die ist ein bisschen widerborstig. Aber professionelle Hilfe ist geboten:

Super Tutorial zum Thema

…von David Nash: https://davidnash.com.au/create-an-auto-complete-field-in-wordpress/

David erklärt wirklich Step by Step und fantastisch nachvollziehbar, auf was es ankommt. Das kann sich wirklich jeder selber reinziehen, das funktioniert direkt auf Anhieb.

Benötigtes Helferlein: jquery autocomplete

Kann man sich hier herunterladen: https://goodies.pixabay.com/jquery/auto-complete/demo.html

Man braucht nur die beiden Dateien jquery.auto-complete.css und jquery-autocomplete.js.

Kleine Ergänzungen zu Davids Tutorial

Das Eingabeformular

Um das Ganze auch ausprobieren zu können, braucht man natürlich ein Eingabeformular. Ich hab eins als Shortcode angelegt, da sieht in meiner functions.php so aus:

 function auto_form(){
    
    echo "<h3>Beispiel Rezeptsuche Autocomplete</h3>";
    
    echo "<form action='#' method='post'>";
    echo "<input type='text' size='40' name = 'auswahl' id = 'rezepte_auswahl'>";
    
    echo "</form>";
    
        
    if (isset($_POST['auswahl'])){
    echo "Vielen Dank! Ihre Auswahl :".$_POST['auswahl']."<br>";
    
   
    } //end if isset
 }
 add_shortcode('a_form', 'auto_form');

Wichtig ist hier die id des Eingabefeldes, die wird dann in unserer js-Datei referenziert:

jQuery(document).ready(function($) {    
    
    $('#rezepte_auswahl').autoComplete({
        source: function(name, response) {
            $.ajax({
                type: 'POST',
                dataType: 'json',
                url: '/wordpress/wp-admin/admin-ajax.php',
                data: 'action=get_listing_names&name='+name,
                success: function(data) {
                    response(data);
                }
            });
        }
    });
 
});

Wichtig ist hier auch die URL der admin-ajax.php, die muss man gegebenenfalls anpassen.

Nachtrag: ich hab mir eine andere Lösung ergooglet

Man kann mithilfe der WordPress-Funktion wp_localize_script() den Pfad zum Admin-Verzeichnis als Variable an das Script übergeben. Dazu ergänzt man die function mysite_js() wie folgt:

function mysite_js() {
    wp_enqueue_script('autocomplete', get_stylesheet_directory_uri().'/js/jquery.auto-complete.js', array('jquery'), false, false);
    
    wp_enqueue_script('mysite-js', get_stylesheet_directory_uri().'/js/mysite.js', array('jquery', 'autocomplete'), false, false);
    
    wp_localize_script( 'mysite-js', 'my_ajaxurl', admin_url( 'admin-ajax.php' ) );
 
    wp_enqueue_style('autocomplete.css', get_stylesheet_directory_uri().'/js/jquery.auto-complete.css');
 
}
add_action('wp_enqueue_scripts', 'mysite_js');

Dann kann man im Script mysite.js für die URL einfach die Variable my_ajaxurl einsetzen:

jQuery(document).ready(function($) {    
    
    $('#rezepte_auswahl').autoComplete({
        source: function(name, response) {
            $.ajax({
                type: 'POST',
                dataType: 'json',
                url: my_ajaxurl,
                //url: '/wordpress/wp-admin/admin-ajax.php',
                data: 'action=get_listing_names&name='+name,
                success: function(data) {
                    response(data);
                }
            });
        }
    });
 
});

Das aber nur als kleiner Tipp am Rande.

Ich hole mir noch die Post-ID

Dazu passe ich die Funktion ajax_listings() ein bisschen an:

function ajax_listings() {
    global $wpdb; //get access to the WordPress database object variable
 
    //get names of all businesses
    $name = $wpdb->esc_like(stripslashes($_POST['name'])).'%'; //escape for use in LIKE statement
    
    $sql = "select post_title, ID 
        from $wpdb->posts 
        where post_title like %s 
        and post_type='post' and post_status='publish'";
 
    $sql = $wpdb->prepare($sql, $name);
    
    $results = $wpdb->get_results($sql);
 
    //copy the business titles to a simple array
    $titles = array();
    foreach( $results as $r )
        $titles[] = addslashes($r->post_title." #".$r->ID);
        
    echo json_encode($titles); //encode into JSON format and output
    
    die(); //stop "0" from being output
}

In den Select kommt noch die ID mit rein, und die hänge ich in der Foreach-Schleife auch noch mit an die Ausgabe dran, mit einem # vorneweg.

Extrahieren der ID im Formular

Wenn der Benutzer einen Listeneintrag ausgewählt und auf Return gedrückt hat, soll ja etwas passieren: nämlich das gewählte Rezept ausgegeben werden. Das „Return-Drücken“ erwischt man mit einem If (ISSET…), dann zerlege ich mir die entsprechende Variable und hole mir nur die Zahl nach dem #.

function auto_form(){
    echo "<a name='form'></a>"; 
    echo "<h3>Beispiel Rezeptsuche Autocomplete</h3>";
    
    echo "<form action='#form' method='post'>";
    echo "<input type='text' size='40' name = 'auswahl' id = 'rezepte_auswahl'>";
   
    echo "</form>";
    
        
    if (isset($_POST['auswahl'])){
    echo "Vielen Dank! Ihre Auswahl :".$_POST['auswahl']."<br>";
    
    //***********Action
    $text = strstr($_POST['auswahl'], '#');
    $text=substr($text,1); 
    echo "Ich bin die Nummer ".$text;
    ///*****end Action
    } //end if isset
 }

Jetzt liegt die ID des gewählten Rezeptes auf der Variablen $text, mit der arbeiten wir weiter und geben einfach den post_content aus:

global $wpdb;
    $sql = "select post_content, ID 
        from $wpdb->posts 
        where ID like ".$text." 
        ";
    
    $results = $wpdb->get_results($sql);
    
    foreach ($results as $r){echo $r->post_content;}

Damit wird das Rezept angezeigt, sobald der Benutzer seine Auswahl getroffen und auf Return gedrückt hat:

salatbowle

Man könnte natürlich auch einen Link zum Rezept einbauen, aber ich lasse es mal so, dann muss der Benutzer nicht woanders hin wechseln, wenn er noch ein Rezept suchen möchte.

Man könnte auch noch die Suche ein bisschen in der Funktionalität verändern, wenn man zum Beispiel nicht nur nach Einträgen suchen möchte, die mit der eingegebenen Zeichenfolge beginnen, sondern alle, in denen die Zeichenfolge enthalten ist. Dann kann man in der function ajax_listings() die Suchvariable einfach anpassen und die Wildcard % noch vornedran setzen:

$name = '%'.$wpdb->esc_like(stripslashes($_POST['name'])).'%';

Das findet z.B. alle Einträge mit salat im Titel, auch nicht unpraktisch:

instring_salat

Alles in allem: eine superpraktische Funktionalität, und dank des grossartigen Tutorials von David Nash einfach umzusetzen. Gefällt mir ausserordentlich gut!

Kleiner Tipp am Ende:

Wenn es zwischendurch so aussieht, als ob WordPress die eigentlich geladenen js-Scripts nicht mehr kennt – Browsercache löschen!

WordPress als führendes System für das Mitgliederverzeichnis: ein Anfang

Erstmal eine Hypothese

Ich habs ja sonst nicht so mit theoretischen Konstrukten, ich bin eher praktisch veranlagt. Aber der Turnverein Weiß-Blau möchte seine Mitgliederstammdaten in Zukunft mit WordPress verwalten, also an die Arbeit. Ich gehe mal davon aus, daß der Import zumindest der Adressdaten mit Custom Fields geklappt hat und unser bestehender Mitgliederstamm jetzt sauber in den WordPress-eigenen Tabellen abgelegt ist.Notfalls mit einem kostenpflichtigen Plugin, das wars uns jetzt wert.

Erstmal sehen sie: nichts.

Kurz zur Erinnerung: für jedes Mitglied gibt es einen eigenen Beitrag. Im Beitragstitel steht die Mitgliedsnummer und der Name. Im Beitragsinhalt möchten wir die Adressdaten sehen. Wieso möchten? Die haben wir doch importiert? Ja aaaber – nach dem Import sehen wir im Beitrag jetzt erst einmal – nichts. Nur wenn man im Dashboard auf „Alle Beiträge“ geht und da bei einem Beitrag „Bearbeiten“ wählt und dann ein bißchen runterscrollt, dann sieht man die Benutzerdefinierten Felder mit ihren Inhalten.

fridolin_CF

Das ist unser Editor für Bestandsdaten. Wenn sich an den Adressdaten eines Mitglieds etwas ändern sollte, suchen wir uns den entsprechenden Beitrag und gehen in den Bearbeitungsmodus, hier können wir unsere Änderungen direkt einpflegen. Kann ich damit leben, die Benutzer brauchen halt eine kurze Einweisung in den Beitragseditor und sollten auch nicht vergessen auf „Aktualisieren“ zu klicken, dann funktioniert das schon.

Und wenn es neue Mitglieder einzutragen gibt?

Natürlich könnte man einfach in WordPress einen neuen Beitrag erstellen und die Daten manuell eingeben, aber das ist dann schon ein bisschen sperriger in der Benutzerführung. Man muß nämlich die relevanten Benutzerdefinierten Felder einzeln hinzufügen, und das ist aufwendig und fehlerträchtig. Ausserdem muss man sich genau überlegen, woher man die Mitgliedsnummer nimmt, unsere so wichtige eindeutige ID. Was gibt es für Alternativen?

Man könnte die neuen Benutzer in der alten Excel-Liste eintragen, die Mitgliedsnummern fortlaufend weiterführen und einen neuen Import fahren, aber was passiert dann mit unseren Bestandsdaten? Werden die „alten“ Mitgliederdaten dann überschrieben? Was passiert mit Änderungen, die ich in den Bestandsdaten eventuell bereits gemacht habe? Wäre dann die Excel-Datei unser führendes System, und nicht WordPress? Lauter Fragen, auf die es so ad hoc keine einfachen Antworten gibt.

Noch ’ne Hypothese

Viele CSV-Import-Plugins, die ich ausprobiert habe, bieten zumindest in der Pro Edition ein Feature, mit dem man auswählen kann ob bereits bestehende Datensätze upgedated werden sollen oder nicht. Ausprobieren konnte ich das nicht, aber es scheint mir die einzig praktikable Lösung zu sein, wenn man neue Mitglieder-Datensätze nicht einzeln manuell eingeben, sondern per neuem Import hinzufügen möchte. Das würde natürlich bedeuten daß wir von unserer alten Excel-Tabelle nicht wegkommen, aber sei’s drum. Gehen wir mal davon aus, dass das funktioniert mit dem selektiven Import, und kümmern wir uns mal um das nächstliegende Problem:

Die immer noch unsichtbaren Custom Fields

Man sieht die benutzerdefinierten Felder ja nach wie vor nur im Beitragseditor, und das soll sich jetzt schnellstens ändern. Eine sehr kurze und praktische Lösung ist ein Shortcode, den wir wie gewohnt in die functions.php unseres Child-Themes setzen. Der kann zum Beispiel so aussehen:

function ms(){
    
    $aktID=get_the_id();
    $strassehsnr= get_post_meta($aktID, 'strassehausnummer', true);
    echo $strassehsnr;
        
}
add_shortcode('meinshortcode','ms');

Ich habs ein bisschen ausführlicher als unbedingt nötig hingeschrieben, aber so läßt sichs besser erklären. Die Funktion ms() macht Folgendes:

get_the_id() holt die WordPress-ID des aktuellen Beitrags
get_post_meta() holt zur aktuellen Beitrags-ID den Wert des Custom Field namens „strassehausnummer“, das „true“ am Ende bewirkt, daß eine Einzelvariable ausgegeben wird und kein Array
echo gibt die ganze Chose aus.

Fertig! Shortcode in einen Beitrag einsetzen, Beitrag ansehen und da steht sie, die Strasse und Hausnummer. Die anderen Custom Fields holt man sich mit genau der gleichen Mechanik, man muß halt nur den get_post_meta() mit dem korrekten Namen des Feldes füttern. Also, damit kann ich jetzt echt leben!

Verwendung im Theme

Man kann die Funktion get_post_meta() natürlich auch in einem Template nutzen, sie z.B. an geeigneter Stelle in ein Child seiner single.php einbauen, aber das ist sehr Theme-spezifisch, da muss jeder selber rumdoktern, das versuche ich zu vermeiden wo es nur geht. In der Praxis wird man sich wahrscheinlich einen benutzerdefinierten Post Type anlegen und dort die entsprechenden Ergänzungen vornehmen, aber davon laß ich hier mal die Finger, das sieht wie gesagt in jedem Theme anders aus. Mir reicht mein funktionaler Shortcode, der ist universell einsetzbar.

Ja, aber was ist jetzt mit dem Anlegen neuer Mitglieder?

Machen wir das echt im alten Excel?
Gute Frage, und ich glaube, dazu brauchts einen neuen Beitrag.

Tabelleneditor revisited: und jetzt das Ganze nochmal als Shortcode

Ja, ich weiß, ich habs unterschlagen. Wir haben uns einen hübschen kleinen Tabelleneditor im Admin Panel gebastelt, mit Unterseite und allem Pipapo. Aber da kamen schon die ersten Rückfragen. Was, wenn ich meinen Besuchern die Möglichkeit anbieten möchte, Tabellendaten auf meiner Webseite zu editieren? Wie sieht das dann die Verzweigung auf die Unterseite aus? Ein Anwendungsfall wäre es zum Beispiel, wenn ich meinen Nutzern das Editieren der eigenen Adressdaten ermöglichen möchte. Da wird man zwar im Zweifelsfall ein Login vorschalten, denkbar ist z.B. daß sich der Benutzer mit seiner Mitgliedsnummer anmeldet und diese beim Aufruf des Unterformulars abgefragt wird. Das führt mir aber jetzt entschieden zu weit, ich lasse es mal bei dem Formular mit den Edit-Buttons, sonst blickt hier keiner mehr durch. Die Funktionalität wird also die selbe sein wie beim Plugin Adressen Tabelle, nur diesmal auf der Blog-Oberfläche.

Wir basteln uns einen Shortcode

Der erste Teil ist simpel. Wir schnappen uns die Funktion pluginAdressenTabelle() und schieben sie in einen Shortcode. Für den legen wir uns eine neue Seite an und fügen ihn dort ein, ich hab ihn mal [adr_tabelle] genannt. Das müsste eigentlich ohne Änderungen klappen, das Ergebnis sollte etwa so aussehen:

shortcode_adresseneditor

Wenn man jetzt auf einen „Edit“-Button klickt, landet man (logischerweise) noch im Admin Panel, und das soll natürlich nicht sein, da brauchen wir was anderes. Nämlich eine Blogseite, die nicht im Menü erscheinen soll, sondern nur durch Klick auf den Edit-Button aus der aufrufenden Seite auftauchen darf.

Seite ohne Menüeintrag? Mit Menü!

Man legt eine neue Seite an, benennt sie entsprechend, z.B. Adresseneditor Unterseite. Dann legt man unter Design/Menüs ein neues Menü an, in das man alle Seiten ausser der eben erstellten einträgt (alle markieren und dann bei der Einzelseite das Häkchen entfernen). Ist ein bißchen von hinten durch die Brust ins Auge, aber so funktionierts.

Aufzurufende Seite bei Formular-Action hinterlegen

Wir klemmen uns einfach den Permalink der soeben erstellten Unterseite und legen sie auf die Variable für den Action-Tag, das sieht dann z.B. so aus:

$meinplugin_URL = „http://localhost/turnverein/adresseneditor/adresseneditor-unterseite/“;

Das wars schon.

Wie kommt jetzt unsere Editor-Funktionalität in die Unterseite?

Per Shortcode! Mein Freund und Lieblingshelfer, ich sags immer wieder. Wir erstellen einen neuen Shortcode, mit aussagekräftigen Namen, z.B.:

add_shortcode (‚mein_adr_editor‘, ‚meinAdressenEditor‘);

Dann brauchen wir natürlich noch die Funktion zum Shortcode, die heißt jetzt meinAdressenEditor(). In diese kopieren wir uns den ganzen Inhalt der Funktion AdresseEditAusgabe() aus dem Plugin, das wir vorher erstellt haben. Nicht vergessen unten den Link zurück auf die aufrufende Seite zu aktualisieren, der sollte jetzt etwa so ausehen:

echo „<a href = ‚http://localhost/turnverein/adresseneditor/’/><h1>Zurück zur Adressenliste</h1></a>“;

Den soeben erstellten Shortcode [mein_adr_editor] in die Unterseite einfügen, speichern und feddisch, das wars! Die Bildschirmausgabe sollte etwa so aussehen:

adresseneditor_unterseite

Übrigens nicht wundern: wenn man sich die Unterseite „allein“ anschaut, also aus dem Edit-Modus mit „Seite ansehen“, sieht man – nichts. Da fehlt der Parameter mit der ID, also ergibt unser Select eine leere Ausgabe, und dann sieht mal halt nichts, punktum.

So, jetzt hab ich aber alle Aspekte des Tabelleneditors erschöpfend behandelt – hoffe ich zumindest. Wenn jetzt noch Rückfragen kommen – ich bin unbekannt verreist 😉

Mein Freund, der Shortcode – auch auf Knopfdruck mit Button

Warum ich Shortcodes so nützlich finde

Ganz einfach, weil sie die volle Funktionalität von PHP mit all den vielfältigen Möglichkeiten von WordPress vereinen. Ich glaube, daß Shortcodes eins der meistunterschätzten programmiertechnischen Werkzeuge von WordPress sind. Alle Welt schreit immer nach Plugins, aber die sind nicht immer der Weisheit letzter Schluß. Gerade wenn man Ausgaben und Ereignisse auf der für den Benutzer sichtbaren Oberfläche einer Webseite steuern will, sind Shortcodes ein mächtiges Werkzeug und nahezu universell einsetzbar. Sie erlauben durch das wpdb-Objekt vollen Datenbankzugriff (übrigens auf jede beliebige Datenbank, für die man den Connect hat), sie erlauben einem das Einsetzen von Formularen mit all den ausgefuchsten Feinheiten von PHP, sie erlauben die Abfrage der Eigenschaften und die Manipulation nahezu aller WordPress-Objekte, und vieles mehr. Kurz gesagt, sie sind das geniale Universal-Schweizermesser wenn man WordPress programmiererisch zuleibe rücken möchte. Jetzt aber genug der Lobeshymne, heute Abend hab ich noch ein nettes Zuckerl:

Shortcodes auf Knopfdruck mit Buttons

Manchmal wäre es ganz nett, wenn ein Shortcode auf einer Seite oder in einem Beitrag nicht sofort beim Aufruf loslegen würde, besonders dann nicht, wenn man mehrere Shortcodes im selben Objekt einsetzen möchte, das wird schnell unübersichtlich. Dann wäre es ganz nützlich, wenn man erst einmal auf ein entsprechend beschriftetes Knöpfchen drücken könnte, und der Shortcode erst dann ausgeführt wird. Das ist nicht schwer zu realisieren, und die Lösung ist (wie könnte es anders sein) selbst ein Shortcode.

Formular für den Button

Um einen klickbaren Button zu erhalten, lege ich ein kleines Formular an, das nichts ausser einem submit-Button enthält, das sieht so aus:

echo ‚<form method=“post“>‘;
echo ‚<input type=“submit“ name = „senden“ value=“Shortcode abrufen“/>‘;
echo „</form>“;

Was passieren soll, wenn auf den Button geklickt wird, wird wie üblich mit ISSET bestimmt, und hier kommt auch gleich der Witz an der ganzen Sache:

if (isset($_POST[’senden‘]))
{
    //Hier Shortcode einsetzen, wichtig: einfache Hochkommas
    $inhalt = „[form id=’26‘ title=’Anmeldung‘]“;
    echo do_shortcode($inhalt);
}

Die Variable $inhalt wird einfach mit dem String des aufzurufenden Shortcodes belegt, und das kann wirklich ein x-beliebiger Shortcode sein, ob selbst definiert, oder der Shortcode eines Contact-Form-7-Formulars, oder ein MetaSlider-Shortcode oder was einem sonst gerade einfällt. Wichtig ist nur, dass man die doppelten Anführungszeichen in den Shortcode-Parametern durch einfache Hochkommas ersetzt. Mehr ist nicht dran, so sieht das Ganze am Stück aus:
function button_shortcode(){

//Begin Formular
echo ‚<form method=“post“>‘;
echo ‚<input type=“submit“ name = „senden“ value=“Shortcode abrufen“/>‘.“<br>“;
echo „</form>“;
// End Formular

if (isset($_POST[’senden‘]))
{
    //Hier Shortcode einsetzen, wichtig: einfache Hochkommas
    $inhalt = „[form id=’26‘ title=’Anmeldung‘]“;
    echo do_shortcode($inhalt);
}

}
add_shortcode(‚button‘, ‚button_shortcode‘);

An der gewünschten Stelle im Beitrag oder auf einer Seite den Shortcode [button] einsetzen, und voila, sie haben ihren Shortcode auf Knopfdruck!

Was wir mit Bildern können, können wir mit Posts schon lange!

Alle veröffentlichten Beiträge

Es wird wieder Zeit für ein bißchen Spaß auf der Datenbank! Wir gehen wieder zurück zu unserer zentralen Tabelle wp_posts und picken uns diesmal alle veröffentlichten Beiträge heraus. Das haben wir schonmal gemacht, bei der Ausgabe der Beitragsbilder ganz am Anfang, wissen sie noch? Der Select ist supersimpel:

SELECT * from wp_posts where post_status = ‚publish‘ and post_type = ‚post‘

Die könnten wir jetzt einfach mal alle ausgeben so wie sie daherkommen, nämlich einfach nacheinander aufsteigend Datum. Das sähe dann aber der Beitragsseite (nur mit umgekehrter Sortierung) verdammt ähnlich und hätte weiter keinen Närwert, deshalb geben wir die Beiträge jetzt erst mal gekürzt und in Divs gepackt als Übersicht aus. Unser foreach für diesen Zweck ist auch denkbar einfach, ich gebe fürs erste nur den Titel und den Inhalt aus:

foreach ( $alleposts as $einpost ) 
            { 
            echo "<div class = 'post_ausgabe'>";
                echo "<h1>".$einpost->post_title."</h1>";
                echo $einpost->post_content."</br>";
            echo "</div>";    
            }

Ich habe mir eine neue Klasse von Div, die post_ausgabe definiert, weil ich die Formatierung etwas anders als bei der Bilderausgabe gestalten möchte. Der CSS-Eintrag sieht so aus:

.post_ausgabe{
    
    float:left;
    height: 300px;
    width: 30%;
    overflow: hidden;
    border: 1px solid blue;
    margin: 2px;
    padding:2px;    
    
}

Wichtig ist der overflow: hidden; damit die Sache leserlich bleibt. Und die Ausgabe? Ich nehme mal wieder das Inselfisch-Kochbuch, da sind richtig schön viele Beiträge drin, und das sieht jetzt erstmal so aus:

post_ausgabe

Zugegeben, das könnte hübscher sein, aber darum kümmern wir uns später. Falls sie sich wundern, daß hier überrall „Einleitung“ als Untertitel steht: das ist völlig korrekt so, weil bei mir (fast) jedes Rezept mit einer Einleitung beginnt. Erinnern sie sich? Da war was mit der Textstrukturierung wegen der Barrierefreiheit. Deswegen kommt als erster Text im post_content das Wörtchen „Einleitung“, als h2-Überschrift formatiert. Die Ausgabe ist also völlig richtig.

Link auf den Beitrag

Jetzt fehlt natürlich der Link auf den Beitrag, den holen wir uns wieder mal mit get_permalink(ID) und machen einen a href auf die Überschrift daraus. Der foreach folgt sogleich:

foreach ( $alleposts as $einpost ) 
            { 
            $akt_link = get_permalink($einpost->ID);
            
            echo "<div class = 'post_ausgabe'>";
                echo "<a href = '".$akt_link."'><h1>".$einpost->post_title."</h1></a>";
                echo $einpost->post_content."</br>";
            echo "</div>";    
            
            }

Jetzt sitzen die Links auf den Überschriften, wo sie hingehören.

alle_posts_mit_links

Wieder das Spiel mit dem Limit und der Zufallszahl

Man kann natürlich auch hier die Anzahl der auszugebenden Beiträge limitieren, und mit Rand() eine zufällige Auswahl der Beiträge erzeugen, und man kann den ganzen Shortcode natürlich auch wieder ins Text-Widget packen und z.B. in die Seitenleiste verschieben, da kann jeder selber damit spielen.

Was noch nicht schön ist

Der abgeschnittene Text stört mich, und der -zigfache Text Einleitung. Da letzteres aber sozusagen mein Privatvergnügen ist, gibts dafür einen neuen Beitrag.

Mit ’nem kleinen Dreh: Shortcodes mit Parameter

Shortcodes sind eine praktische Sache, wie wir gesehen haben, es lassen sich alle möglichen PHP-Funktionen sauber hineinpacken und an nahezu beliebiger Stelle ausgeben. Jetzt wärs aber doch auch schick, wenn man der Funktion auch noch bestimmte Werte mitgeben könnte, und der alte Programmierer nickt sofort und sagt: au ja, Parameter!

Parameterübergabe an Shortcodes

Ich nehm mir nochmal meinen Hallo-Evi-Shortcode her, und möchte jetzt den Namen als Parameter übergeben, so daß die Funktion dann „Hallo liebe xyz“ ausgibt. Im Shortcode-Aufruf sieht das so aus:

[mhs name = „Evi Silvia“]

Die eckigen Klammern weisen WordPress an, nach einer passenden Funktion zu suchen, das mhs ist der Shortcode der Funktion, die wir in der functions.php definiert haben. name ist der Bezeichner unseres Parameters, und der Wert des Parameters wird mit = zugewiesen. Parameter sind in WordPress-Shortcodes immer Strings, deswegen in Gäsefüßchen „Evi Silvia“.

Damit unsere Funktion jetzt den Parameter auch entgegennimmt, müssen wir den Funktionskopf ändern, das sieht jetzt so aus:

function mein_hallo_shortcode($param)

Dabei ist $param ein beliebiger PHP-Variablenname. Wer hat hier gesagt: echo „Hallo liebe $param“?
Nicht ganz, wenn man es so macht, kommt nämlich Folgendes heraus:

Hallo liebe Array

Parameter als Array

Die Parameter des Shortcodes werden nämlich als Array übergeben. Dabei bildet jede Zeile ein Wertepaar aus Bezeichner und Wert ab. In unserem Fall ist das nur eine Zeile, weil wir ja nur einen Parameter ausgeben. Um jetzt an den Wert des Parameters heranzukommen, muß man das Array auslesen, und das geht so:

function mein_hallo_shortcode($param) {

$aktName = $param[’name‘];
echo „<h1>Hallo liebe „.$aktName.“</h1>“;
}

Das $param[’name‘] liest den Wert („Evi Silvia“) zum Bezeichner name aus. Auch nicht so schlimm, man muß es nur wissen. Der Vorteil bei dieser Methode ist, daß man beim Aufruf eines Shortcodes eine ganze Latte von Parametern mitgeben kann und über die Bezeichner freien Zugriff darauf hat, die Reihenfolge der Parameter ist dabei prinzipiell egal.

Mehrere Parameter übergeben

Der Funktionsaufruf sähe dann z.B. so aus:

[mhs vorname = „Evi“ nachname = „Leu“]

Ensprechend wird die Funktion angepaßt:

$aktVorname =  $param['vorname'];
$aktNachname =  $param['nachname'];


echo "Hallo liebe".$aktVorname." ".$aktNachname;

Ausgabe: Hallo liebe Evi Leu

Alles klar? Wenn man weiß wie, ist die Parameterübergabe eine nützliche und flexible Angelegenheit.

Spiel&Spaß mit Shortcodes

Haben sie sich die Bilderausgabe auch schon in einen Shortcode gepackt? Ja fein, dann wirds Zeit für ein bißchen Spielerei am Sonntag Nachmittag

Anzahl der Bilder limitieren und Zufallszahl einbauen

Man will ja vielleicht nicht immer gleich alle Bilder ausgeben, sondern nur eine kleine Auswahl. Das ist ganz simpel, wir ergänzen das SQL-Statement einfach um eine LIMIT-Anweisung. Und damit nicht immer die selben Bilder herauskommen, ergänzen wir die Sache um die Zufallsfunktion RAND(). Das kommt ans Ende des SQL, vor den letzten schließenden Gänsefüßchen:

…ORDER BY RAND() LIMIT 6″ );

Ergebnis:

6_bilder_screenshot

Ab in die Seitenleiste

Und damit man die Bilderausgabe auch mal an anderer Stelle unterbringt, setzen wir den Shortcode ins Text-Widget und ziehen dieses in die rechte Seitenleiste. Sieht auch sauber aus:

6_bilder_seitenleiste

Ich hab auch mal das Inhaltsverzeichnis in die Seitenleiset gepackt, das sieht dann so aus:

ivz_in_der_seitenleiste

Wie und wo die Platzierung des Shortcodes Sinn macht, hängt natürlich vom verwendeten Theme und von der Art der Ausgabe ab, aber ich denke sie haben jetzt die Möglichkeiten ein bißchen gesehen. Nur zu, viel Spaß beim rumprobieren! Es darf naturlich auch noch ein wenig am CSS geschraubt werden, ich rücke hier mal die Bilder näher zusammen (den Margin einfach rausnehmen):

6_bilder _ohne_margin

Also, viel Vergnügen beim Ausprobieren!