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.

 

Alphabetische Paginierung aus Array: die Tücken des PHP-sort()

Eigentlich hats mich ja nur interessiert, ob das recht aufwendig ist, aber das hielt sich in Grenzen, deswegen mach ich es noch der Vollständigkeit halber. Voraussetzung ist wie im letzten Beitrag, dass die auszugebenden Daten in Form eines Arrays vorliegen, ich nehme wieder meine 334 Kochrezepte als JSON, so wie im letzten Beitrag zur nummerischen Pagination. Nach dem json_decode sieht die Struktur des Arrays wie gehabt wie folgt aus:

array(1) 
{ ["rezepte"]=> array(334) {
 [0]=> array(3) { ["ID"]=> string(4) "1828" ["post_title"]=> string(31) "Pudding nach Art des Hauses Leu" ["post_content"]=> string(37) "Vanille oder Schoko oder Johannisbeer" }
 [1]=> array(3) { ["ID"]=> string(4) "1827" ["post_title"]=> string(5) "Milch" ["post_content"]=> string(23) "reicht nicht bis morgen" } 
 [2]=> array(3) { ["ID"]=> string(4) "1825" ["post_title"]=> string(14) "Petersilwurzel" ["post_content"]=> string(29) "hab ich abgeerntet, ist nicht" }

Jetzt interessieren mich aber eigentlich nur die post_title, die krieg ich mit:

$akt_titel = $dataObject['rezepte'][$i]['post_title'];

Und die Titel der Rezepte möchte ich nach Buchstaben seitenweise sortiert ausgeben. Also, pack’mas.

Das Formular mit den Buttons

Dafür fülle ich mir erst einmal ein Array mit den Buchstaben a-z, daraus baue ich dann das Formular:

//Buchstaben a-z in Array schreiben
$letters = array();
for ($i = 'a', $j = 1; $j <= 26; $i++, $j++) {
    $letters[$j] = $i;    
}
//Formular mit Buttons a-z erzeugen
echo "<form action = '#' method = 'post'>";

for ($i=1; $i <=26; $i++){
    echo "<input type='submit' id='el_button' name='".$letters[$i]."' value='".$letters[$i]."'>";
}
    echo "</form>";

Das sieht jetzt erstmal so aus:

alfa_buttons

alfa_buttons

Dann ermittle ich, welcher Buchstabe angeklickt wurde, und rufe mit diesem Buchstaben als Parameter meine Ausgabefunktion auf:

//Ermitteln welcher Buchstabe angeklickt wurde und Ausgabefunktion aufrufen
for ($j = 1; $j <= 26; $j++){    
        if (isset($_POST[''.$letters[$j].''])){
            
            return el_aufruf("".$letters[$j]."");
        }
        
    }

In der Ausgabefunktion hole ich mir mein Array mit allen Daten, steppe es ganz durch und picke mir mit dem if nur die Einträge heraus, wo der post_title mit dem als Parameter übergebenen Buchstaben anfängt. Diese werden mit array_push einer nach dem anderen an mein Hilfsarray $ausgabe angehängt.

function el_aufruf($stabe){
            
    //JSON alle Rezepte abholen und in Array umwandeln
    $json = file_get_contents('http://localhost/kleine_api/rezepte/rezeptelesen.php');
    $dataObject = json_decode($json,true);
    $anzahl = count($dataObject['rezepte']);
    echo "Rezepte insgesamt = ".$anzahl."<br>";
            
    //Hilfsarray für Ausgabe     
    $ausgabe = array();
        
        for ($i=0; $i<$anzahl; $i++){
            //Ersten Buchstaben vergleichen
            if (strtoupper(substr(($dataObject['rezepte'][$i]['post_title']), 0, 1))== strtoupper($stabe)){
                //Hilfsarray mit Titeln zum aktuellen Buchstaben füllen
                array_push($ausgabe, $dataObject['rezepte'][$i]['post_title']);
            }
        }

Das Hilfsarray sortiere ich mir noch mit dem einfachen sort() und gebe es zeilenweise aus:

//Array sortieren und ausgeben
    sort($ausgabe);
    foreach($ausgabe as $out){
        echo $out."<br>";
    }
} //end function el_aufruf

Die Ausgabe sieht dann beispielsweise so aus:

buchstabe_c

buchstabe_c

Kleiner Pferdefuß: die Umlauts und Sonderzeichen

Der PHP sort() ist nicht dazu zu bewegen, die deutschen Umlaute anderswo als am Ende einer Liste nach dem Buchstaben Z einzusortieren. Auch Sonderzeichen wie z.B. mit Accents (Béchamel) landen gnadenlos am Ende. Das sieht man ganz deutlich am Ende der Liste zum Buchstaben B:

buchstabe_b

buchstabe_b

Da müsste man jetzt hingehen und eine eigene sort-Funktion schreiben, die aus den deutschen Umlauts Diphtonge mach (ä=ae, ö=oe…) und erst danach sortieren, vor der Ausgabe aber die Umlaute wieder einsetzen. Ach nö Leute, das ist mir echt zu stressig. Ich lebe mal mit der Ausgabe der Umlaute am Ende, vielleicht begegnet mir ja beim Googlen noch irgendwo eine elegantere Lösung.

Und prompt hab ich was gefunden: Sortierung der Umlauts wie im Telefonbuch

Auf der Webseite von Marco Krings habe ich folgende interessante Sortierfunktion gefunden:

http://www.marcokrings.de/arrays-sortieren-mit-umlauten/

Er arbeitet mit zwei Arrays für die Umlaute und die entsprechenden Diphtonge. Diese Arrays könnte man jetzt noch um die Accent-Zeichen wie z.B. é ergänzen, ich hab das mal ausprobiert:

$aSearch   = array("Ä","ä","Ö","ö","Ü","ü","ß","-","é");
    $aReplace  = array("Ae","ae","Oe","oe","Ue","ue","ss"," ","e");

Funktioniert eins a!

Meine Ausgabe wird jetzt noch um Marcos Funktion ArraySort() erweitert:

//Array sortieren und ausgeben
    //sort($ausgabe);
    $umlauts = ArraySort($ausgabe);
    foreach($umlauts as $out){
        echo $out."<br>";
    }

Jetzt paßt die Sache. die Umlaute und das é werden richtig einsortiert:

e_accent

e_accent

Das ist ausbaufähig! Vielen Dank an Marco für die geniale Vorlage.

Nachtrag: woher nehm ich jetzt die ID?

Ich habe in meiner alfabetischen Ausgabe bis jetzt nur die Titel der Rezepte verarbeitet, das reicht aber unter Umständen nicht. Für manche Zwecke wäre es schick, wenn man auch noch die ID mitnehmen könnte, zum Beispiel in WordPress für die Ausgabe des Permalinks. Man könnte jetzt auf die Idee kommen, in der for-Schleife den array_push umzustricken, so dass ein mehrdimensionales Array mit Titel und ID aufgebaut wird… ja Pustekuchen, dann fällt unser schöner Sortieralgorithmus auf die Nase, das geht leider nicht. Ich hab mir da eine quick&dirty-Lösung einfallen lassen: ich hänge die ID einfach an den Titel mit dran, und setze dazwischen als Trennzeichen ein #. Kann ich so machen, weil in meinen Rezepttiteln das Zeichen # sonst garantiert nirgendwo vorkommt. Die for-Schleife sieht dann so aus:

for ($i=0; $i<$anzahl; $i++){
  //Ersten Buchstaben vergleichen
if (strtoupper(substr(($dataObject['rezepte'][$i]['post_title']), 0, 1))== strtoupper($stabe)){
//Hilfsarray mit Titeln und ID zum aktuellen Buchstaben füllen (Trennzeichen#)
array_push($ausgabe, $dataObject['rezepte'][$i]['post_title']."#".$dataObject['rezepte'][$i]['ID']);
   }
}

Dann sieht die Ausgabe erstmal so aus:

id_angehaengt

id_angehaengt

Das zerpflücke ich mir jetzt noch in die Teilstrings vor und nach dem #, gebe nur den Titel aus und kann dann mit der ID noch was anderes anfangen. Die Ausgabeschleife sieht dann so aus:

foreach($umlauts as $out){
        
        //alle Zeichen vor dem # = Titel
        $hilf_titel = substr($out, 0, strpos($out, '#', 0));
        echo $hilf_titel."<br>";
        
        //alle Zeichen nach dem # = ID
        $hilf_id = substr(strrchr($out, "#"), 1);
        //hier kann man mit der ID weiterarbeiten
        }

Wie gesagt, das ist ein wenig quick&dirty, aber es funktioniert, und ich kann den schicken Sortieralgorithmus von Marco einwandfrei weiterverwenden.

Nummerische Pagination mit Werten aus Array (pure PHP)

Das hat jetzt mit WordPress nur noch insofern etwas zu tun, als es einem auch hier mal unterkommen kann, dass die Daten für eine seitenweise nummerierte Ausgabe in Form eines Arrays ankommen und nicht direkt mit SQL aus der Datenbank abgefragt werden. Typischerweise passiert sowas, wenn man über eine API auf die Datenbank zugreift und die Ergebnisse der Abfrage als JSON zurückgegeben werden. Das kann man mit Hilfe von json_decode() flugs in ein Array umwandeln und mit einem foreach() wie gehabt seitenweise ausgeben. Wenn allerdings die Datensätze pro Seite einen Rest ergeben, fliegt PHP bei der letzten Seite auf die Nase und spuckt so etwas aus:

Notice: Undefined offset: 334 in C:\xampp\htdocs\kleine_api\err_num_page.php on line 74

Die kleine Tücke: der Rest

Wir haben, sagen wir mal, 334 Datensätze. Und wir legen die Anzahl der Datensätze pro Seite auf 10 fest. Das gibt 33 ganze Seiten a 10 Datensätze, und auf der letzten Seite haben wir nur noch vier Datensätze. Da muss man jetzt eine Sonderbehandlung für den Rest einbauen, weil unser Array ja nur einen Index bis 333 zuläßt – Offset by one, den 334. Array-Entrag gibt es nicht mehr. Dieses Dilemma hat man nicht, wenn man direkt auf die Datenbank zugreift und mit einem SQL-Limit arbeiten kann, da ist es egal wenn am Ende die Seite nicht ganz voll wird, es gibt keine Fehlermeldung.

Aber, wir arbeiten ja mit einem Array, und da muss man die ganze Logik ein bisschen umstricken. Also, frisch ans Werk!

Das Array

… enthält 334 Kochrezepte und sieht nach einem json_decode in etwa so aus:

array(1) 
{ ["rezepte"]=> array(334) {
 [0]=> array(3) { ["ID"]=> string(4) "1828" ["post_title"]=> string(31) "Pudding nach Art des Hauses Leu" ["post_content"]=> string(37) "Vanille oder Schoko oder Johannisbeer" }
 [1]=> array(3) { ["ID"]=> string(4) "1827" ["post_title"]=> string(5) "Milch" ["post_content"]=> string(23) "reicht nicht bis morgen" } 
 [2]=> array(3) { ["ID"]=> string(4) "1825" ["post_title"]=> string(14) "Petersilwurzel" ["post_content"]=> string(29) "hab ich abgeerntet, ist nicht" }

Das heißt, um beispielsweise an die ID und den Titel eines Datensatzes heranzukommen, muss ich folgende Syntax verwenden:

$akt_id = $dataObject['rezepte'][$i]['ID'];
$akt_titel = $dataObject['rezepte'][$i]['post_title'];

Das ist jetzt noch nicht weiter tragisch, ich muss nur daran denken dass mein Array bei 0 anfängt, das heißt bei einer Anzahl Datensätze pro Seite von X darf ich nur von 0 bis X-1 ausgeben. Praktisch sieht das z.B.bei 10 Datensätzen pro Seite so aus:

Seite 1: Datensätze 0…9
Seite 2: Datensätze 10…19
Seite 3: Datensätze 20…29

letzte Seite: der Rest

Das heisst aber, ich muss für meine ganzen Seiten eine andere Logik anwenden als für die letzte Seite, auf der auch weniger als 10 Datensätze stehen können.

Aber fangen wir erstmal vorne an:

Ermitteln der Seitenzahl und des Restes

Mein Array mit den 334 Datensätzen heißt $dataObject und wurde aus einem JSON in ein Array umgewandelt. Jetzt rechne ich erstmal aus, wieviele ganze Seiten das ergibt, wenn ich hier beispielsweise 10 Datensätze pro Seite ausgebe, und welcher Rest bleibt.

<?php

//JSON alle Rezepte abholen und in Array umwandeln
$json = file_get_contents('http://localhost/kleine_api/rezepte/rezeptelesen.php');
$dataObject = json_decode($json,true);

//Rezepte pro Seite ausrechnen
$pro_seite = 10; //Wert kann beliebig geändert werden
$anzahl = count($dataObject['rezepte']);
echo "Datens&auml;tze gesamt = ".$anzahl."<br>";
echo "Das macht ".floor($anzahl/$pro_seite)." ganze Seiten
 bei ".$pro_seite." Rezepten pro Seite, Rest: ".$anzahl%$pro_seite."<br>";

Ich habe mit Absicht eine sehr geschwätzige echo-Ausgabe eingebaut, zur besseren Kontrolle. Der Output sieht jetzt mal so aus:

echo_kennzahlen

echo_kennzahlen

Damit kann ich mir jetzt schon mal die Buttons für die einzelnen Seiten zusammenbauen. Das mache ich wieder mit einem Formular. Ich zähle mein i von Seite 1 bis zur letzten Seite inklusive hoch, als Value kriegt jeder Button den aktuellen Wert von i. Ausserdem kriegt jeder Button noch eine ID, die brauchen wir später noch.

//Formular mit Buttons für die Seitenzahlen, Start 1, Ende: nächsthöhere Ganzzahl
for ($i=1; $i <=ceil($anzahl/$pro_seite); $i++){
    echo "<form action = 'array_num_page.php' method = 'get'>";
    echo "<input type='submit' id='el_num_button_".$i."' name=akt_i value='".$i."'>";
}
echo "</form>";

Das sieht jetzt schonmal so aus:

buttons

buttons

Jetzt gehts daran zu ermitteln, welche Seite gerade aktuell ist. Ich starte als Default mit der 1, und je nachdem welchen Button der Anwender angeklickt hat hole ich mir den Wert aus dem Formular.

//Checken ob eine Seite geklickt wurde
$seitenstart=1;
if (isset($_GET['akt_i'])){
    $seitenstart = $_GET['akt_i'];
    }else{
    $seitenstart=1;
    }
//versteckte Ausgabe für farbige Markierung der aktuellen Seite mit Script    
echo "<div id ='seitenstart' style='display:none;'>".$seitenstart."</div>";

Meinen Seitenstart schreibe ich mir noch in eine versteckte Div, die brauche ich nachher für die farbige Markierung der aktuellen Seite.

Jetzt gehts erst mal an die Ausgabe.

Die ganzen Seiten

Hier darf ich nur bis zur letzten ganzen Seite hochzählen, die letzte Seite mit den weniger Datensätzen kommt später dran:

//Ausgabe aller ganzen Seiten von 1 bis zum letzten ganzzahligen Vielfachen
if (($seitenstart > 0) and ($seitenstart < floor($anzahl/$pro_seite))){

//Tabelle für Ausgabe aller Rezepte zusammenbauen
echo "<table border : 1px>";
echo "<th>ID</th><th>Titel</th><th>Content</th> 
/*Ausgabe als Tabelle*/

Jetzt wird es ein bisschen knifflig. Ich bleibe mal bei einem Wert pro Seite von 10 Datensätzen, es klappt aber auch mit jedem anderen Wert.

Auf Seite eins muss ich bei 0 anfangen und bis eins weniger als die Anzahl der Datensätze pro Seite hochzählen, also bis 9. Auf Seite zwei muss ich bei 10 anfangen und bis 19 hochzählen, usw.:

//Bei 0 anfangen, bis max. eins weniger als die Anzahl der ganzen Seiten hochzählen (0..9, 10..19 usw...)
for ($i=($seitenstart-1)*$pro_seite; $i <= $pro_seite*$seitenstart-1; $i++){

Die ganze for-Schleife mit der Ausgabe der einzelnen Werte aus dem Array in Tabellenzeilen sieht so aus:

//Bei 0 anfangen, bis max. eins weniger als die Anzahl der ganzen Seiten hochzählen (0..9, 10..19 usw...)
for ($i=($seitenstart-1)*$pro_seite; $i <= $pro_seite*$seitenstart-1; $i++){

echo "<tr>";
//Werte aus dem Array auf Var. legen
$akt_id = $dataObject['rezepte'][$i]['ID'];
$akt_titel = $dataObject['rezepte'][$i]['post_title'];
//Content tags raus und auf 100 Zeichen kürzen
$akt_content = substr(strip_tags($dataObject['rezepte'][$i]['post_content']),0,200);

echo "<td>".$akt_id."</td><td>".$akt_titel."</td><td>".$akt_content."</td>";
echo "</tr>";
}

Damit haben wir die Ausgabe aller ganzen Seiten erledigt. Jetzt kümmern wir uns um den Rest. Da nehmen wir nur noch die Indizes aus dem Array, die grösser als der letzte Wert vor dem letzten ganzzahligen Vielfachen der Seitenzahl sind, und marschieren nach oben durch bis 1 vor der Gesamtzahl der Datensätze.

//****Ausgabe Rest wenn Seitenzahl grösser als das letzte ganzzahlige Vielfache ist
if($seitenstart > floor($anzahl/$pro_seite)){
...

//starten beim letzten ganzzahligen Vielfachen der Gesamt-Seitenzahl, 
//stoppen eins unter Gesamtzahl
for ($i=floor($anzahl/$pro_seite)*$pro_seite; $i < $anzahl; $i++){

Voila, das wars! Der ganze Code mit Ausgabe der Tabelle sieht so aus:

//**************************Ausgabe Rest wenn Seitenzahl grösser als das letzte ganzzahlige Vielfache ist
if($seitenstart > floor($anzahl/$pro_seite)){
    

//Tabelle für Ausgabe des Rests zusammenbauen
echo "<table border : 1px>";
echo "<th>ID</th><th>Titel</th><th>Content</th>";

//starten beim letzten ganzzahligen Vielfachen der Gesamt-Seitenzahl, stoppen eins unter Gesamtzahl
for ($i=floor($anzahl/$pro_seite)*$pro_seite; $i < $anzahl; $i++){

echo "<tr>";
//Werte aus dem Array auf Var. legen
$akt_id = $dataObject['rezepte'][$i]['ID'];
$akt_titel = $dataObject['rezepte'][$i]['post_title'];
//Content tags raus und auf 100 Zeichen kürzen
$akt_content = substr(strip_tags($dataObject['rezepte'][$i]['post_content']),0,200);

echo "<td>".$akt_id."</td><td>".$akt_titel."</td><td>".$akt_content."</td>";
echo "</tr>";
}
echo "</table>";
    
}

Noch ein Javascript-Zuckerl: aktuelle Seite farbig markieren

Ich hab mir ja zu jedem Seitenzahl-Button eine ID generiert, das sah so aus:

echo "<input type='submit' id='el_num_button_".$i."' name=akt_i value='".$i."'>";

Und ich habe mir den Wert der aktuellen Seite (default 1) in eine versteckte div geschrieben:

//versteckte Ausgabe für farbige Markierung der aktuellen Seite mit Script    
echo "<div id ='seitenstart' style='display:none;'>".$seitenstart."</div>";

Damit habe ich mir ein kleines Javascripterl gebastelt, das die aktuelle Seite farbig markiert:

<script>

    $(document).ready(function() {
    var dieid = document.getElementById('seitenstart').innerHTML;
    //alert(dieid);
    document.getElementById('el_num_button_'+dieid).style.backgroundColor = "lightgreen";
    }); 


</script>

Ich klaube mir die aktuelle Seitenzahl aus der verstecken Div und spreche damit die zugehörige Button-ID an, die style ich mir nach Belieben, das war auch schon alles. Hübscher kleiner Effekt!

seite_farbig

seite_farbig

 

Kontrastfarbe automatisch berechnen mit jquery/Javascript

Das hat jetzt mit WordPress nur insoweit was zu tun, als ich eine Anforderung vom Kunden hatte, ein Info-Widget mit in zufälligen Intervallen wechselnden Farben zu hinterlegen, der wollte das halt gern so haben. Dabei stellte sich aber gleich die Herausforderung, dass der Text (default schwarz) bei dunklen Hintergrundfarben natürlich schlecht bis gar nicht zu lesen war. Will heissen, die Textfarbe sollte dann auch dynamisch angepasst werden, und das mach ich mit jquery/Javascript. Dafür hab ich mir eine Lösungsstrategie zusammengegooglet, die man vielleicht mal irgendwo anders brauchen kann, deswegen kommt sie hier rein.

Zufällige Farbe für den Hintergrund bestimmen

Dafür habe ich mir dieses recht überschaubare Snippet ergooglet, das sehr zuverlässig funktioniert:

//******Zufällige Hex-Farbe erzeugen*********************/
    function randomColor(){
    
    var x=Math.round(0xffffff * Math.random()).toString(16);
    var y=(6-x.length);
    var z="000000";
    var z1 = z.substring(0,y);
    var color= "#" + z1 + x;
    
    return color;
    }

Relative (wahrgenommene) Helligkeit einer Farbe bestimmen

Dafür gibt es vom w3c eine Faustformel, die ich für den Kontrast bei barrierefreien Seiten immer wieder mal brauche, die geht so:

//***********relative Helligkeit von r,g,b bestimmen
    function Brightness(r, g, b)
    {
       return Math.sqrt(
          r * r * .241 + 
          g * g * .691 + 
          b * b * .068);
    }

Man füttert sie mit den RGB-Werten einer Farbe und kriegt einen Wert zwischen 0 und 255 heraus, der die relative Helligkeit einer Farbe bezeichnet. Man nimmt dann als Kontrastfarbe für die untere Hälfte des Farbspektrums weiß, für die obere Hälfte schwarz. Den Schwellwert von 130 kann man nach Geschmack noch ein bisschen nach oben oder unten anpassen.

//****************Textfarbe je nach Schwellwert zurückgeben
    function textfarbe(helligkeit){
    if (helligkeit > 130){return 'black'}
    if (helligkeit <= 130){return 'white'}

    }

Wir haben Hex und brauchen RGB

Deswegen gibts noch eine Umwandlungsfunktion, die uns den Hex-String zerlegt und die RGB_Werte liefert:

//************rgb-Werte aus hex holen
    function hexToR(h) {return parseInt((cutHex(h)).substring(0,2),16)}
    function hexToG(h) {return parseInt((cutHex(h)).substring(2,4),16)}
    function hexToB(h) {return parseInt((cutHex(h)).substring(4,6),16)}
    function cutHex(h) {return (h.charAt(0)=="#") ? h.substring(1,7):h}

var R = hexToR(aktfarbe);
var G = hexToG(aktfarbe);
var B = hexToB(aktfarbe);

Mit den drei Variablen kann man dann die Funktion Brightness() aufrufen, und mit der wiederum die Funktion textfarbe(), die uns dann schlussendlich die passende Kontrastfarbe für unsere zufällige Hintergrundfarbe liefert. Ich gebe zu es ist ein bisschen von hinten durch die Brust ins Auge, aber es funktioniert. Hier mal das ganze Script zum Nachvollziehen:

Das Script

<script>
    $(document).ready(function(){
    setInterval(farbwechsler, 5000)
    farbwechsler();
    
    //******Zufällige Hex-Farbe erzeugen*********************/
    function randomColor(){
    
    var x=Math.round(0xffffff * Math.random()).toString(16);
    var y=(6-x.length);
    var z="000000";
    var z1 = z.substring(0,y);
    var color= "#" + z1 + x;
    
    return color;
    }

    //************rgb-Werte aus hex holen
    function hexToR(h) {return parseInt((cutHex(h)).substring(0,2),16)}
    function hexToG(h) {return parseInt((cutHex(h)).substring(2,4),16)}
    function hexToB(h) {return parseInt((cutHex(h)).substring(4,6),16)}
    function cutHex(h) {return (h.charAt(0)=="#") ? h.substring(1,7):h}
    
    //***********relative Helligkeit von r,g,b bestimmen
    function Brightness(r, g, b)
    {
       return Math.sqrt(
          r * r * .241 + 
          g * g * .691 + 
          b * b * .068);
    }
    
    //****************Textfarbe je nach Schwellwert zurückgeben
    function textfarbe(helligkeit){
    if (helligkeit > 130){return 'black'}
    if (helligkeit < 130){return 'white'}

    }
        
function farbwechsler(){

var aktfarbe = randomColor();

var R = hexToR(aktfarbe);
var G = hexToG(aktfarbe);
var B = hexToB(aktfarbe);


           document.getElementById("zufall").style.backgroundColor = aktfarbe;
           document.getElementById("inhalt").innerHTML ="Hex: "+ aktfarbe;
           document.getElementById("rgb").innerHTML = "rgb: "+R+", "+G+", "+B;
           document.getElementById("brightness").innerHTML ="Helligkeit: "+ Brightness(R,G,B);
           document.getElementById("schrift").style.backgroundColor = aktfarbe;
           document.getElementById("schrift").style.color = textfarbe(Brightness(R,G,B));
           }

    
  })
</script>

Ich hab mal die Funktion farbwechsler() auf alle 5 Sekunden gesetzt, für den Demo-Effekt.

Und hier noch das passende HTML zum Ausprobieren:

<body>

<h1>Beispiel Contrast Colors mit Javascript</h1>
<div id = "zufall">Schriftfarbe statisch</div>
<div id="inhalt">...</div>
<div id="rgb">...</div>
<div id="brightness">...</div>
<div id="schrift"><h1>Schriftfarbe dynamisch</h1></div>

</body>

Das wars! So gibt es immer lesbare Schrift auch auf zufällig generierten Hintergrundfarben.