Archiv der Kategorie: Themes

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.

Ein eigenes WordPress-Theme 2: Widget-fähige zweite Sidebar einbinden

Also, das war jetzt einfacher als ich dachte, deswegen kommts hier heute noch rein. Ich hatte ja in meinem dreispaltigen Template ursprünglich eine statische linke Seitenleiste definiert, und mit einer eigenen kleinen Funktion zur Anzeige der 10 neuesten Rezepte gefüllt, das sah in der index.php so aus:

<div id = "sidebar-left">
    
    <h2>Die neuesten Rezepte</h2>
        <ul>
            <?php $liste = wp_get_recent_posts();
            
            foreach($liste as $item){
                echo '<li><a href="' . get_permalink($item["ID"]) . '">' . $item["post_title"].'</a> </li>';
            }    
            ?>
        </ul> 
 
  </div> <!-- sidebar-left-->

Natürlich gibts aber das Widget „Neueste Beiträge“ schon, und das wollen wir auch nutzen, indem wir die linke Sidebar widgetfähig machen.

Eine neue Datei für die linke Sidebar anlegen

Die heißt sidebar-links.php (oder sidebar-xy.php) und enthält folgenden Code:

<div id="sidebar" class="widget-area">
<?php dynamic_sidebar( 'sidebar-2' ); ?>

</div><!-- #sidebar .widget-area -->

Damit WordPress nun auch eine dynamische Sidebar namens sidebar-2 kennt, kommt folgender Eintrag in die functions.php, dabei passt man den name, die id und die description an:

register_sidebar( array (
        'name' => __( 'Linke Sidebar'),
        'id' => 'sidebar-2',
        'description' => __( 'Widgets in der linken Sidebar anordnen.'),
        'before_widget' => '<aside id="%1$s" class="widget %2$s">',
        'after_widget' => "</aside>",
        'before_title' => '<h3 class="widget-title">',
        'after_title' => '</h3>',
    ) );

In der index.php ersetzt man nun den gesamten Code der statischen Sidebar durch den Aufruf:

<div id = "sidebar-left">
    
    <?php get_sidebar('links'); ?>
 
  </div> <!-- sidebar-left-->

Tückisch ist hier das kleine Wörtchen „links“, das muss genauso heissen wie man es oben im Namen der sidebar-links.php (oder sidebar-xy.php) definiert hat.

Das wars aber auch schon, unsere linke Sidebar taucht jetzt in der Widget-Verwaltung auf und kann bestückt werden:

widgets_linke_sidebar

widgets_linke_sidebar

Ein eigenes Widget erstellen: kurz und knackig

Ich habe hier bei blog.unkonsorten.com die ultimative Kurzanleitung zum Erstellen eines eigenen Widgets gefunden, die möchte ich euch nicht vorenthalten( Beim Code kopieren auf die „“ und “ aufpassen, die muss man korrigieren).

Damit es etwas Interessanteres ausgibt als „Hallo Welt“ habe ich mal die Anzahl der veröffentlichten Rezepte eingebaut, die kriegt man so :

function widget_sidebar() {
// Hier kann man eigenen Code einfuegen
echo "<h3>Rezepte insgesamt: ".wp_count_posts()->publish."</h3>";
}

Das wars auch schon – Have fun with Widgets!

Sag niemals nie: ein einfaches WordPress-Theme erstellen

Ich hab ja am Anfang dieses Blogs steif und fest behauptet, ich werd hier nie nix zur Erstellung eines eigenen Themes erzählen, weil es a) Zillionen von Themes für jeden Zweck und Geschmack schon gibt und b) Hunderte von hervorragenden Tutorials zum Thema bereits existieren. Aber wenn ich schon die Theme-Erstellung für Drupal und Joomla behandelt habe, darf WordPress eigentlich nicht fehlen, schon aus Gründen der Vergleichbarkeit.

Das tolle Tutorial von Christian Strang

Mit eins der besten Tutorials zur Erstellung eines eigenen WordPress-Themes ist das von Christian Strang auf Lernen hoch 2, und statt bei ihm abzuschreiben kann ich nur jedem ans Herz legen, es durchzuarbeiten und selber zu sehen und zu staunen, wie ausführlich er alles erklärt und wie hervorragend nachvollziehbar die ganze Sache ist. Ich gehe mal davon aus, dass jeder ein eigenes Theme nach Christians Anleitung hinkriegt, und setze nur noch ein paar Kleinigkeiten obendrauf.

Die Vorlage: dreispaltig (wenns geht) mit grossem Headerbild

Das Theme-Layout soll ganz schlicht werden, mal sehen wie weit wir damit kommen:

scribble

scribble

Wenn man sich durch Christians Tutorial durchgearbeitet hat, sollte man jetzt ungefähr dieses Layout erreicht haben:

tutorial_layout

tutorial_layout

Hier wird nur eine (die rechte) Sidebar genutzt, und die ist auch nach Christians Vorlage Widget-fähig, das ist die WordPress-Vorgabe und am einfachsten zu realisieren.

Eine zweite Sidebar

Ich hätte aber gern auch noch eine linke Sidebar, in die sollen meine neuesten Rezepte rein. Das geht nicht weiter kompliziert und auch ohne Widget. Ich füge in der index.php vor die div für den content noch eine div sidebar-left ein und nutze die WordPress-Funktion wp_get_recent_posts(), um mir die neuesten Beiträge ausgeben zu lassen. Das machen wir gleich mit Link zum Beitrag, dafür gibts den get_permalink():

 <div id = "sidebar-left">
    
    <h2>Die neuesten Rezepte<7h2>
        <ul>
            <?php $liste = wp_get_recent_posts();
            
            foreach($liste as $item){
                echo '<li><a href="' . get_permalink($item["ID"]) . '">' . $item["post_title"].'</a> </li>';
            }    
            ?>
        </ul> 
 
  </div> <!-- sidebar-left-->

In der style.css habe ich die divs für sidebar-left, main und sidebar-right nebeneinander positioniert:

#main       {width: 600px; padding: 20px; float: left;}

#sidebar-left   {width: 200px; padding: 10px;float: left;}

#sidebar-right   {width: 200px; padding: 10px;float: left;}

Die Ausgabe ist schon ganz passabel:

die_neuesten_rezepte

die_neuesten_rezepte

Ein Header-Bild wär jetzt noch schön

Dafür gibt es die sehr komfortable Funktionalität

add_theme_support( 'custom-header' );

Diese Zeile kommt in die functions.php

Dann gibt man ihr noch ein paar Argumente mit:

$args = array(
 'width'         => 1260,
 'height'        => 350,
 'default-image' => get_template_directory_uri() . '/images/header.jpg',
 'uploads'       => true,
 );
 add_theme_support( 'custom-header', $args );

Die width und heigth Angaben tauchen dann im Customizer als empfohlene Größe auf, das kann sich jeder selbst einstellen wie es zu seinem Layout paßt. In der header.php wird jetzt folgender Code an oberster Stelle nach der öffnenden div für den wrapper folgender Code eingesetzt:

<img src="<?php header_image(); ?>" 
    height="<?php echo get_custom_header()->height; ?>" width="<?php echo get_custom_header()->width; ?>" alt="" />

Jetzt noch das Header-Bild hochladen und ggf. zuschneiden, dann sollte es auch schon sichtbar sein:

headerbild

headerbild

Ich hab mir gleich noch das Blau des Himmels rausgemessen und in der style.css als background-color für die div header gesetzt, damit das schön zusammenpasst.

Jetzt fehlen mir eigentlich nur noch ein paar Schriftformatierungen, die mach ich in einem Rutsch:

#navlist li
{
font-family:    Times;
font-variant:small-caps;
font-size:      25px;
display: inline;
list-style-type: none;
padding-right: 20px;

}

body {
  margin: 0;
  padding: 0;
  font-family: Helvetica;
  font-size: 14px;    
  font-weight: normal;
  line-height: 24px;
  color: #43473b;
}


h1, h2, h3, h4, h5, h6 {
  font-family: Times;
  font-weight: normal;
  color: #43473b;
}

h1 { font-size: 45px; font-variant:small-caps;}
h2 { font-size: 30px; font-variant:small-caps;}
h3 { font-size: 22px; font-variant:small-caps;}

a { color: #43473b; 
    text-decoration: none;
}
a:hover { color: #fc737b; 
        }

Fertig ist mein Übungsstheme!

finish

finish

Jetzt wärs natürlich schick, wenn die linke sidebar auch Widgetfähig wäre, aber man kanns auch übertreiben… ich geh mal gucken, vielleicht finde ich da noch was dazu.

 

 

Erstellen wir jetzt endlich mal ein eigenes Theme?

Nein.

Und das ist mein letztes Wort, ehrlich. Themes gibt es wie Sand am Meer, da ist echt für jeden Geschmack, Zweck und Funktionsumfang was dabei. Themes sind ein Konzept, das auch vom Enduser (im Zweifelsfall meinem Kunden) leicht begriffen wird, nach Themes kann jeder selber suchen und sich aus den vielen bunten Bildchen das heraussuchen, was ihm am besten gefällt. Und glauben sie mir: es wird ihm erst das eine Theme gefallen, und dann das Nächste und dann noch das Übernächste. Was bei einem Themewechsel auf sie zukommt, da haben sich andere Leute schon schlaue Gedanken gemacht, siehe z.B. dieser Artikel vom elbnetz. Bestenfalls passen nur ein paar Bildformate nicht mehr, schlimmstenfalls zerhackt es ihnen die ganzen Seitenlayouts und die ganzen schönen kundenspezifischen Funktionen.

Bedenken sie immer: als Entwickler kommen sie bei einem Themewechsel in Teufels Küche, wenn sie abhängig von einem bestimmten Theme programmiert haben, und der Kunde möchte jetzt aber unbedingt ein anderes.

Ich editiere Page Templates nur im äußersten Notfall

Weil ich aus langjähriger leidgeprüfter Praxis genau weiß, dass sich der Kunde früher oder später für ein anderes Theme entscheiden wird, greife ich wenn möglich gar nicht in die Page Templates ein. Die Arbeit ist bei einem Themewechsel grad für die Katz‘, und es ist auch nicht gesagt daß ihre Anpassungen in einem anderem Theme auch genauso funktionieren werden, dazu sind die Templates einfach zu uneinheitlich konstruiert.

Aber was ist, wenn man ein Child Theme verwendet?

Das selbe in Grün, ich setze hier keine modifizierten Page Templates ein, wenn es nicht unbedingt sein muss. Ich verwende (ausser bei ganz, ganz einfachen Blogs) immer ein Child Theme. In den seltenen Fällen, wo ich es nicht von Anfang an eingerichtet habe, kam immer früher oder später der Zeitpunkt wo ich doch eins gebraucht habe.

Die einzigen Dateien, an denen ich Änderungen vornehme, sind üblicherweise die functions.php (ganz wichtig für unsere Shortcodes) und seltener noch die style.css des Child Themes. Und das wird dann (verdammtnochmal!) ordentlich und ausführlich dokumentiert, damit man die Funktionalität im Falle des Falles ohne Beinbruch in ein neues Theme übertragen kann.

Ausnahmen bestätigen die Regel

Und falls doch mal eine Änderung an einem Template fällig ist: immer im Child Theme, und immer gut dokumentieren. Ich habe zum Beispiel auf der Seite des Turnvereins Weiß-Blau die Beitragsseiten als Mitgliederverzeichnis umgestaltet, da war ein Eingriff in die single.php notwendig, um die Daten aus der eigenen Tabelle mit den Mitglieder-Stammdaten anzeigen zu lassen. Aber ich wette mit mir selber, dass ich das auch mit einem Shortcode lösen könnte – da mach ich mir bei Gelegenheit mal mehr Gedanken drüber.

Auch wenn man bestimmte Teile des Themes loswerden möchte (keine Sidebar, kein Footer etc…) kommt man um eine Änderung der entsprechenden Templates kaum herum, aber auch hier gilt: immer im Child Theme, und immer gut aufpassen was man da wirklich macht. Die Themes sind ja, wie bereits gesagt, so uneinheitlich konstruiert (und so lausig dokumentiert, das muss auch mal gesagt werden!), dass sich hier kaum allgemeingültige Regeln aufstellen lassen, welche Änderung welchen Effekt bewirkt. Da ist immer viel Trial and Error dabei.

Änderungen in der style.css nur mikrochirurgisch

Natürlich kann man sich hier spielen und die Layouts für nahezu alle WordPress-Elemente nach eigenem Gusto verändern. Aber ich bin Fachinformatikerin, keine Webdesignerin, und überlasse das passende Styling denen, die’s gelernt haben, und das sind im Zweifelsfall nun mal die Theme-Designer. Ich greife mal ein, wenn z.B. die Umrandungen von Formularfeldern unsichtbar sind (beliebtes Manko), oder die Beschriftung von Buttons unleserlich ist. Aber das wars dann schon. Alles andere lasse ich wie es ist, die Leute vom Design haben ja schließlich grosse Mühe darauf verwendet, dass alles zusammen ein stimmiges Bild ergibt, und ich als Design-Laie kann hier bestenfalls verschlimmbessern.

Theme-unabhängig programmieren, das geht!

Sogar sehr schmerzlos. Mit Shortcodes und Plugins, Filtern und Action Hooks läßt sich fast alles  erreichen, was der Kunde anfordert, und hier kann man wirklich Theme-unabhängig arbeiten, wenn man ein bisschen aufpasst.

Grosse Styling-Änderungen reden wir unserem Kunden einfach aus, da suchen wir ihm lieber ein anderes Theme. Wir sind schließlich (ich sags nochmal) alte Programmierer und keine Designer.

WordPress möchte doch so gern ein CMS sein

Da fehlts zwar noch ein paar Meter, aber das gute alte WordPress nimmt ja für sich in Anspruch, ein vollwertiges CMS werden zu wollen. Und da ist die Trennung von Funktion und Design unverzichtbar! Will heissen, eigentlich sollte man die Themes wechseln können wie die frischen Socken, ohne dass an den Inhalten überhaupt Nacharbeiten anfallen.

Davon sind wir zwar im Moment noch einiges entfernt, aber mit der Multisite-Technologie gehts schon in die richtige Richtung, besonders wenn man geeignete Plugins zum Beispiel zum Clonen von ganzen Blogseiten einsetzt. Damit kommen zwar auch wieder neue Herausforderungen – wie schreibe ich ein Multisite-fähiges Plugin? – aber die Richtung stimmt wie gesagt schon. Ich beobachte diese Entwicklung mit grossem Interesse, und werde hier sicher noch den einen oder anderen Beitrag zum Thema CMS reinstellen. Aber ein eigenes Theme – no way Josè, das wirds hier bei mir nie geben.