Archiv der Kategorie: Allgemein

Joomla-Modul ein bisschen aufgebohrt – mit Benutzereingaben

Ich hab ja in diesem Artikel ein WordPress-Widget erstellt, das die Gesamtzahl der veröffentlichten Rezepte sowie die Anzahl der Rezepte einer frei wählbaren Kategorie anzeigt. So nach dem Muster:

312 Rezepte insgesamt

46 davon Vegetarisch

Ob das mit unserem Joomla-Modul auch hinzukriegen ist?

Anzahl der Beiträge der Kategorie Rezepte

Meine Rezeptkategorie hat die ID 8, das kann man in der Tabelle #__categories nachschauen. Dazu hab ich folgendes Code Snippet gefunden:

$model = JModelLegacy::getInstance('Articles', 'ContentModel');
        $model->setState('filter.category_id', 8); // Set category ID here
        $articles = $model->getItems();

        $num_articles = count($articles); // Returns the number of articles in category

Kommt mir ein bisschen arg umständlich vor, aber wenns funktioniert…

Ich möchte jetzt aber natürlich auswählen können, zu welcher Kategorie die Gesamtzahl der Beiträge ausgegeben werden soll, weil ich in Joomla so schöne Möglichkeiten habe, über die Kategorisierung meine Ausgabe auf der Webseite zu strukturieren. Das heißt aber, wir brauchen ein Eingabefeld (Dropdown), in dem der Benutzer anwählen kann, welche Kategorie ausgegeben werden soll.

Eingabefelder für eigene Module in Joomla

Sind nicht arg schwer zu realisieren, die Joomla-Doku zu dem Thema ist schon mal recht gut, schaut mal hier rein:

https://docs.joomla.org/J3.x:Creating_a_simple_module/Adding_Form_Fields

Ich machs aber hier nochmal step by step, damit man es auch nachvollziehen kann. Wir setzen auf unser Hallo-Welt Modul aus dem vorigen Beitrag auf und erweitern die mod_helloworld.xml, in der kann man ein einfaches Texteingabefeld so erstellen:

 <config>
    <fields name="params">
        <fieldset name="basic">
            <field name="param1" type="text" default="" label="Bitte Titel eingeben" description=""></field>
           </fieldset>
    </fields>
    </config>

Die Felddefinition muss innerhalb der config-Tags stehen. Wenn man sich jetzt mal das Modul aschaut, müsste das Feld eigentlich schon da sein:

texteingabefeld

texteingabefeld

Wie kommt man jetzt an den Inhalt des Feldes ran, den unser Benutzer eiingegeben hat? Das passiert in der mod_helloworld.php, und zwar so:

$variable = $params->get('param1');

Die $variable kann man jetzt an die helper-Klasse übergeben:

$hello = modHelloWorldHelper::getHello($variable);

Und da kann man dann damit weiterarbeiten. Bevor ich da noch weiter darauf eingehe, erstmal:

Die Anforderungen

Den Titel des Moduls kann der Anwender beim Erstellen unter Erweiterungen->Module->neu->Mein Hallo-Welt Modul selber eingeben, den fragen wir nicht nochmal extra ab. Dafür brauchen wir aber ein Dropdown-Feld, in dem die Kategorie (z.B. „Rezepte“) ausgewählt werden kann, für die die Gesamtzahl der Beiträge ausgegeben soll. Und wir brauchen noch ein zweites Dropdownfeld für das „featured tag“ (z.B. „Vegetarisch“, aber dazu kommen wir später. Jetzt werfen wir erstmal einen Blick auf:

Die vordefinierten Form Field Types

Da bietet Joomla etwas wirklich praktisches an, es gibt eine ganz Latte von vordefinierten Formularfeldern, hier die Doku dazu: https://docs.joomla.org/Standard_form_field_types

Da klemmen wir uns gleich mal den Formularfeldtyp „Kategorie„, der macht nämlich genau das was wir brauchen. In der XML-Datei sieht das so aus:

<field name="mycategory" type="category" extension="com_content" label="Eine Kategorie auswählen" description="" />

In der mod_helloworld.php holen wir uns den Inhalt mit:

$kat = $params->get('mycategory');

Und im Modul-Backend kriegen wir unsere Dropdown-Liste mit den Kategorien:

dropdown_kategorien

dropdown_kategorien

In der übergebenen Variablen steckt übrigens die numerische ID der Kategorie Rezepte, die können wir gleich direkt weiterverwerten, und zwar in der helper.php:

public static function getHello($params)
    {
        $model = JModelLegacy::getInstance('Articles', 'ContentModel');
        $model->setState('filter.category_id', $params); // Set category ID here
        $articles = $model->getItems();

        $num_articles = count($articles); // Returns the number of articles in category
        
        echo "Insgesamt ".$num_articles." Rezepte<br>";    
        
        
        
    }

Voraussetzung dafür ist natürlich, dass wir sie in der mod_helloworld.php auch als Parameter an die Helper-Klasse übergeben haben, aber dazu gleich mehr, zuerst schauen wir uns mal die Ausgabe an:

insgesamt_rezepte

insgesamt_rezepte

Das paßt soweit, jetzt müssen wir nur noch den Ausgabetext dynamisch anpassen, es kann ja auch jemand die Kategorie „Kochbücher“ angewählt haben, dann darf da nicht „Rezepte“ stehen. Das machen wir so:

//Name der Kategorie zur ID holen
        $db = JFactory::getDbo();
        $db->setQuery("SELECT cat.title FROM #__categories cat WHERE cat.id='".$params->kat."'"); 
        $category_title = $db->loadResult();
        
        echo "Insgesamt ".$num_articles." ".$category_title."<br>";

Nicht dran stören dass hier „.$params->kat.“ steht, das kommt daher, dass ich ein Array von Parametern übergeben habe, mehr dazu gleich. Jedenfalls wird jetzt auch der richtige Kategoriename angezeigt:

2kochbuecher

2kochbuecher

Mehr als ein Formularfeld, mehrere Parameter zum Übergeben

Wir brauchen aber noch ein zweites Formularfeld für die Tags, und dazu werfen wir einen kurzen Blick darauf, wie wir mehr als eine Variable an die Helper-Klasse übergeben können. Kurze Erinnerung, wie die zwei Felddefinitionen in der XML-Datei aussehen:

<fields name="params">
        <fieldset name="basic">
            <field name="param1" type="text" default="" label="Bitte Text eingeben" description=""></field>
            
                
            <field name="mycategory" type="category" extension="com_content" label="Eine Kategorie auswählen" description="" />
            
           </fieldset>
    </fields>

Die Inhalte der Felder holen wir uns in der mod_helloworld.php über die Feldnamen:

$kat = $params->get('mycategory');
$variable = $params->get('param1');

Dann packen wir sie in ein Standardobjekt und übergeben dieses an die Helper-Klasse:

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

        
$hello = modHelloWorldHelper::getHello($data);

In der helper.php holen wir uns die übergebenen Variablen, die ja in unserem Objekt stecken, mit ihrem Namen, also z.B. $params->kat. Das $params stammt aus der Funktionsdefinition der public static function getHello($params)) wer da etwas anderes stehen hat, muss das entsprechend anpassen. Hier nochmal die komplette function:

public static function getHello($params)
    {
        //Anzahl der Artikel zur übergebenen Kategorie-ID holen
        $model = JModelLegacy::getInstance('Articles', 'ContentModel');
        $model->setState('filter.category_id', $params->kat); // Set category ID here
        $articles = $model->getItems();

        $num_articles = count($articles); // Returns the number of articles in category
        
        //Name der Kategorie zur ID holen
        $db = JFactory::getDbo();
        $db->setQuery("SELECT cat.title FROM #__categories cat WHERE cat.id='".$params->kat."'"); 
        $category_title = $db->loadResult();
            
        echo "Insgesamt ".$num_articles." ".$category_title."<br>";
        
        
    }

Das sieht jetzt schon ziemlich gut aus. Leider habe ich für die Tags keinen vordefinierten Formularfeldtyp gefunden, da müssen wir was basteln, aber dazu gibt es einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

WordPress, Joomla und Drupal: Theme-Erstellung im Vergleich

Also, ich hab ja kürzlich das Anlegen eigener Templates/Themes in allen drei CMS ein bisschen angerissen und die Basics zusammengeschrieben. Da bietet es sich an ein Resumee zu ziehen, was ich hiermit versuche. Mein völlig subjektiver Winner ist:

Joomla – so einfach kann es sein

Sobald man den Zusammenhang der definierenden XML-Datei templateDetails.xml und den Modulpositionen in der index.php überrissen hat, kann man schon richtig loslegen. Kein Gewühle in unverständlichem PHP-Code, kein umständliches Einbinden externer Skripte. Dadurch, dass man in Joomla über die Kategorien und Module im Backend nahezu unendliche Konfigurationsmöglichkeiten hat, ist es gar nicht notwendig tiefer in die Template-Logik einzusteigen, man kann fast alles über die Administrationsoberfläche einstellen. Dabei kann man sich allerdings auch ganz schön verzetteln – eine gute Doku ist hier wirklich unabdingbar, sonst kann man nie nachvollziehen warum, wie und weshalb wer an welchen Schräubchen gedreht hat.

Was ein bisschen übersichtlicher sein könnte: die Modulzuordnung in der Admin-Oberfläche. Da fehlt eine Möglichkeit, sich nur die Modulpositionen eines bestimmten Templates anzeigen zu lassen (oder ich hab sie nicht gefunden). So wie es ist muss man sich bei der Modulpositionierung durch eine fusselige Liste aller Templates mit allen Modulpositionen durchscrollen, da sind Fehlklicks vorprogrammiert.

Das wird allerdings beinahe ausgeglichen durch die hervorragende Möglichkeit, sich die Modulpositionen auf der Webseite anzeigen zu lassen. Das geht, indem man im Browser an die URL den Parameter ?tp=1 anhängt, das sieht dann z. B. so aus: http://localhost/jsite/?tp=1, damit kriegt man einen anschaulichen Überblick, wo man auch gleich erkennt wenn am css noch was nicht stimmt.

joomla_tp

joomla_tp

Alles in allem ist die Erstellung eines eigenen Templates in Joomla ein recht vergnüglicher Prozess, das Positionieren der benötigten Module geht recht flott von der Hand und die Feineinstellungsmöglichkeiten über die Adminoberfläche sind sehr weitreichend, ohne dass man in den Templatecode eingreifen muss. Ich kann auch jedem die kurze und knackige Joomla-Dokumentation zum Thema ein einfaches Template erstellen empfehlen, damit geht echt ein Schnellstart!

Ein guter zweiter Platz: Drupal mit Views

Ohne Views geht nämlich nahezu gar nichts, wenn man seine Inhalte auch übersichtlich ausgeben möchte. A propos Inhalte: die selbstdefinierten Inhaltstypen sind eine der grossen Stärken von Drupal, wenn man die vernünftig nutzt spart man sich einen Haufen Template-Gefiddel. Ein eigenes Template anzulegen ist jetzt eigentlich auch nicht weiter schwierig, wenn man als Vorlage die generische page.tpl.php nutzt und keine Scheu davor hat, darin Elemente herumzuschubsen und umzugruppieren. Auch in Drupal kommt einem eine Vorschau der Template-Elemente zu Hilfe, unter Struktur->Blöcke->Blockregionen veranschaulichen kann man schnell überprüfen ob das Layout passt:

blockregionen

blockregionen

Da man alle Views auch als Blöcke definieren und ins Layout einpassen kann, ist man in der Ausgabe der gewünschten Daten nahezu unendlich flexibel, da bleibt so gut wie kein Wunsch offen. Besonders die Multiblog-Funktionalität über die unterschiedlichen Inhaltstypen und Taxonomien ist easy in der Realisierung und macht es einem leicht, die Seite sauber zu strukturieren.

Ich hätte mir höchstens eine einfachere Möglichkeit des Seitendesigns gewünscht als die page.tpl.php anzupassen, die ist doch ein bisschen unübersichtlich und tendiert zum div-Wildwuchs. Und noch etwas, was wirklich nervt: man kommt bei der Template-Entwicklung nicht darum herum, ständig den Cache zu leeren, weil man seine Änderungen sonst im Zweifelsfall erstmal nicht sieht. Das kostet Zeit und nervt, da wäre es wünschenswert, wenn man eine Möglichkeit hätte so etwas wie einen Entwicklermodus einzuschalten, in dem das Caching abgeschaltet werden kann.

Das gute alte WordPress auf Rang drei

Da merkt man halt schon, dass die Software etwas in die Jahre gekommen ist. Mit einem einfachen Seitenaufbau mit einem Kopfbereich, einer Inhaltszone mit ein paar statischen Seiten, einem Blog und einer Sidebar ist man recht schnell dabei, aber wenn man mehr will, gehts gleich ans Eingemachte. Entweder man arbeitet sich selber in die WordPress-API ein (und die ist eine Wissenschaft für sich) oder man verläßt sich auf die Funktionalitäten zusätzlicher Plugins. Von denen gibt es zwar unzählige für jeden Zweck und Geschmack, aber ich kauf nicht so gern die Katze im Sack, und die meisten Plugins sind grottenschlecht bis gar nicht dokumentiert. Da hat man leicht mal eins installiert, das einem die ganze Site lahmlegt oder unerklärliche Fehlfunktionen auslöst, und dann hat man das Gfrett herauszufinden wer denn jetzt wirklich der schwarze Peter war.

Auch eine komfortable Datenbank-Abfragemöglichkeit wie Drupals Views oder eine fein differenzierte Einstellmöglichkeit nahezu aller Parameter für die Anzeige wie in Joomla sucht man vergebens, man muss sich im Zweifelsfall selber in die vorhandenen Theme-Dateien einarbeiten und sie nach eigenem Bedarf anpassen, und eigene Plugins und Widgets entwickeln. Das war vor ein paar Jahren noch akzeptabel, jetzt aber laufen die beiden jüngeren CMS dem alten WordPress da um Längen den Rang ab.

Nur einen nicht so leicht zu schlagenden Vorteil hat WordPress: für kleinere, einfachere Webseiten ist es immer noch das Anwenderfreundlichste, am Leichtesten zu bedienende CMS auf dem Markt. Start Blogging – das ist kein leerer Werbespruch, das ist nach wie vor WordPress‘ grosse Stärke! Für den Einzelunternehmer, Handwerker, Arzt oder Anwalt, der seine Firma mit einer Visitenkarte im Web vorstellen möchte, ist WordPress nach wie vor die ideale Lösung. Auch für mittlere Benutzergruppen wie Vereine, kleinere Behörden und soziale Dienstleister ist es ideal, weil kostengünstig in der Realisierung und leicht zu pflegen. Der Markt für WordPress als „kleine“ Lösung für den Webauftritt ist riesengross und wird es aller Voraussicht nach noch lange bleiben.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

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.

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Ein einfaches Joomla-Template erstellen

Eine hervorragende Anleitung zum Erstellen eines einfachen Joomla-Templates findet man hier bei http://joomla-templates-erstellen.de, und auch die Joomla-Doku gibt einiges her zm Thema Understanding Joomla Templates. Ich versuche hier trotzdem einmal eine Zusammenfassung der absoluten Basics, damit man mal einen kurzen Überblick bekommt.

Die Vorlage: ein TwentyFourteen-Scribble

Mein Template soll am Ende so aussehen wie mein geliebtes WordPress-Theme Twenty-Fourteen, das ist schön schlicht und ohne Schnickschnack. Das Layout ist simpel:

scribble

scribble

Die Inhalte leihe ich mir mal beim Inselfisch-Kochbuch. Das Logo = Headerbild soll die gesamte Breite von 1260 px einnehmen, darunter kommt der Titel der Seite, evtl. auch der Untertitel = Slogan. Ich habe nur ein einfaches lineares Menü ohne Untermenüs. In die rechte Seitenleiste sollen die neuesten Beiträge, in die linke Seitenleiste meine Rezeptkategorien. In die Mitte kommt der jeweilige Content, der Footer schliesst die Sache nach unten ab. Das war schon alles, auf wieterführende Features wie Breadcrumb Navi oder sekundäres Menü verzichte ich großzügig, der Übersicht halber.

Schritt 1: Die Verzeichnisstruktur erstellen

Zunächst geht das erstmal im Trockenkurs, es gibt einiges an Vorarbeit zu erledigen, ehe man sich die Ergebnisse auch wirklich in Joomla anschauen kann. Wir fangen mal mit dem leichten Teil an: zwei Screenshots von unserem Templateentwurf für die Vorschau im Template-Manager. Einen nenne ich template_preview.png, 400x300px, den zweiten template_thumbnail.png, 200×50 px. Beide kommen in mein Template-Verzeichnis, das hat den Arbeitstitel Evis2014.

template_preview

template_preview

Dann lege ich noch einen Unterordner namens css und einen zweiten namens images an. Das wäre schonmal die komplette Verzeichnisstruktur.

verzeichnisstruktur

verzeichnisstruktur

Die erste Template-Datei: templateDetails.xml

Dreh- und Angelpunkt unseres neuen Templates ist die definierende xml-Datei. Wie die für die einzelnen Joomla-Versionen aussehen sollte, ist hier bei joomla-templates hervorragend dokumentiert, dort ist vor allem auch erklärt welche Komponenten Pflicht sind und welche nur kann.

Meine templateDetails.xml ist sehr schlicht gehalten, Den Header habe ich mir bei joomla-templates kopiert:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE install PUBLIC "-//Joomla! 1.6//DTD template 1.0//EN" "http://www.joomla.org/xml/dtd/1.6/template-install.dtd">
<extension version="3.0" type="template" client="site">

Darauf folgen die persönlichen Informationen über Templatenamen und Author:

<name>Evis2014</name>
<author>Evi Leu</author>
<creationDate>30. März 2018</creationDate>
<description>Mein Joomla-Nachbau des WordPress-Templates Twenty Fourteen</description>

Jetzt wirds gehaltvoller: man muss Joomla mitteilen, welche Dateien mit im Spiel sind (die Liste werden wir nachher noch abspecken):

<files>
<filename>component.php</filename>
<filename>error.php</filename>
<filename>index.html</filename>
<filename>index.php</filename>
<filename>offline.php</filename>
<filename>template_preview.png</filename>
<filename>template_thumbnail.png</filename>
<filename>templateDetails.xml</filename>

<filename>css/formate.css</filename>
<filename>images/logo.png</filename>

</files>


Die Dateien existieren natürlich noch gar nicht alle, aber wir werden sie jetzt der Reihe nach anlegen.

Der letzte Abschnitt: die Template Positions (eine Arbeitsversion, das wird sich später noch etwas ändern:

<positions>
<position>oben</position>
<position>left</position>
<position>breadcrumb</position>
<position>search</position>
<position>right</position>
<position>footer</position>
</positions>

Fehlt noch das schliessende Tag für die Extension:

</extension>

Das wars erstmal, und jetzt gehen wir dran, unsere Dateien auch anzulegen.

Die weiteren Template-Dateien

  • index.html: eine leere HTML-Seite
  • component.php, error.php, offline.php : kann man sich von einem anderen Joomla-Template kopieren oder auch weglassen (dazu später mehr)
  • css/formate.css legen wir zunächst als leere Datei im Ordner css an
  • images/logo.png wird unser Headerbild, das sollte 1260px breit sein.

Das sollte für den Anfang mal genügen. Für die index.php, das Grundgerüst unserer Seite, gibts einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Von Joomla nach WordPress umziehen – der Vollständigkeit halber

Ich habe drüben im Drupal-Blog ausführlich beschrieben, wie man Inhalte aus Drupal in WordPress-Beiträge überführt, nachzulesen hier. Das selbe machen wir jetzt noch mit Joomla, und zwar möchte ich die Beiträge aus einer bestimmten Kategorie nach WordPress exportieren. Meine ausgewählte Kategorie sind natürlich die Rezepte, mit der Kategorie-ID 8 (im Zweifelsfall nachschlagen in der Tabelle #__categories).

Wie kommen wir an Titel und Inhalt der Rezepte?

Aus der Tabelle #__content. Die holen wir uns nach Access rüber und schauen sie mal näher an.

content

content

Die id und den title nehmen wir mit, den alias lassen wir aus. Dann brauchen wir noch den introtext und den fulltext (beide!), weil Joomla den Beitragstext in diese beiden Felder aufteilt, sobald man einen Weiterlesen-Tag eingefügt hat. Das sieht man hier im Screenshot oben bei den ids 4 bis 8, so sieht das dann aus.

Den state müssen wir filtern, -2 bedeutet „marked for deletion“, 1 ist veröffentlicht, wir nehmen nur die 1er. Und die catid filtern wir auch, auf die 8 für Rezepte. (Bei mir ist noch ein Haufen Schrott vom Testen mit drin, ich nehm mal noch die Datensätze 9-47 raus). Übrig bleibt die folgende Tabelle:

content_gefiltert

content_gefiltert

Die specken wir noch ab, die Felder introtext und fulltext werden zu einem Feld namens bodytext zusammengefügt, die catid und der state fliegen raus.

Jetzt fehlen noch die Tags für die Kategorien

Kleine Erinnerung: ich hatte die Rezeptkategorien aus WordPress auf Joomla-Tags ohne Schachtelung abgebildet. Die holen wir uns jetzt wieder zurück, und zwar aus der Tabelle #__tags.

tags

tags

Der erste Eintrag für root fliegt raus, vom Rest übernehmen wir id und title. Parent_id ist überall leer, weil nicht geschachtelt, published = 1 passt auch. Um jetzt die Tags den Rezepten (hier in der Tabelle id_title_bodytext) zuzuordnen, verknüpfen wir über die Tabelle contentitem_tag_map. Beim Importieren nach Access darauf achten, dass content_item_id und tag_id als Integer rüberkommen! Das sieht dann so aus:

tags_beziehungen

tags_beziehungen

Darüber basteln wir uns eine Abfrage, in der zunächst mal jedes Rezept so oft vorkommt, wie es Tags zugeordnet hat:

abfrage_tags

abfrage_tags

Kurzer Blick über die Tabelle: ich habe zu keinem Rezept mehr als 2 Tags zugeordnet, aber das passt schon, ist korrekt.

Zuordnen der Tags zu WordPress-Kategorien

Dafür zieht man sich alle gültigen Tags aus der #–tags ab und importiert sie als Kategorien nach WordPress, wie das geht habe ich in diesem Artikel unter Schritt 1: Anlegen der Kategorien in WordPress im Drupal-Blog ausführlich beschrieben.

Dann habe ich mir die entstandene Tabelle wp_terms nach Access rübergeholt:

wp_terms

wp_terms

Hier kann ich jetzt über den name des Terms auf den title des tags verknüpfen, weil die Schreibweise identisch ist:

join_term_name

join_term_name

Damit bekomme ich die WordPress-Kategorie-IDs zu den Rezepten.

term_id

term_id

Das hatten wir so ähnlich schonmal, jedes Rezept taucht jetzt so oft auf, wie es Kategorien/Tags hat. Jetzt Gruppieren wir noch, und nehmen den ersten und letzten Wert der Term-ID. Diese sind bei den Datensätzen gleich, die nur eine Kategorie zugeordnet haben, das ist schon richtig so.

ersterwert_letzterwert

ersterwert_letzterwert

So, das wars. Diese Tabelle kann man nach WordPress importieren, und zwar genau so wie ich es in diesem Artikel beschrieben habe:

DRUPAL NACH WORDPRESS: BEITRÄGE MIT KATEGORIEN ERZEUGEN

Dabei muss man wahrscheinlich noch eine kleine Abfrage einbauen, was passieren soll wenn erster und letzte Wert der term_id gleich sind, aber prinzipiell funktioniert die Sache so einwandfrei, die Beiträge werden in WordPress angelegt und mit Kategorien versehen.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Was mir an Joomla gut gefällt – und was weniger

Zum Ende meiner Serie über Joomla für alte Programmierer gehört natürlich ein Fazit her, und das wird ganz persönlich und erhebt keinen Anspruch auf allgemeine Gültigkeit. Ich fang mal damit an, was mir im Vergleich zu WordPress als erstes auffällt.

Weniger intuitive Bedienung

In WordPress kann ja wirklich jeder halbwegs computeraffine Anwender gleich loslegen, das „Start Blogging!“ ist durchaus realistisch. Ganz so einfach macht es einem Joomla nicht, man muss sich erst einmal mit der Menüerstellung anfreunden, und die ist für einen Neuling nicht gerade intuitiv. Auch das Konzept der Joomla-Kategorien sollte man erst einmal verinnerlichen, sonst wird das nix. Wenn man nur eine einfache Blog-Homepage aufbauen will, oder eine „Visitenkarte“ im Web, ist Joomla meiner Ansicht nach zu schweres Geschütz, das sollte man mit WordPress machen, dafür reicht es völlig.

Bilderverwaltung ist ein Stiefkind

Dadurch, dass es in Joomla keine Funktionalität zum Skalieren von Bildern beim Hochladen gibt, ist man ohne entsprechende Erweiterungen drauf angewiesen, die Bilder vor dem Upload auf ein vernünftiges Mass zu verkleinern. Auch die Zuordnung von Alt-Texten, Bildtiteln etc. ist eher stiefmütterlich geraten, das ist eher noch schlechter als in WordPress gelöst, und das will was heissen. Ich würde mir für beide Programme wünschen, dass die Entwickler da mal rangehen und die Medienverwaltung auf vernünftige Füsse stellen.

Multiblog-Funktionalität dank Kategorien

Über die Kategorien hat man in Joomla eine feine Möglichkeit, eine Multiblog-Site zu erstellen, und das hab ich mir in WordPress schon oft gewünscht. Sobald sie auf einer Seite Beiträge aus unterschiedlichen Ressorts logisch schön getrennt aufbereitet darstellen wollen, ist Joomla sicher der bessere Weg. So wie ich meine Rezepte und meine Kochbücher in getrennte Kategorien gepackt habe, lassen sich auch unendlich viele andere Beitragstypen in Kategorien abbilden. Das erleichtert die Strukturierung auch komplexerer Seiten enorm! Was mir allerdings fehlt (vielleicht hab ich es nur nicht gefunden) : eine Möglichkeit, für jede Artikelkategorie ein eigenes Layout zu anzulegen. Man hat zwar die Möglichkeit mit Alternativen Layouts zu arbeiten, aber die muss man bei der Artikelerstellung explizit auswählen. Ich hätte lieber eine automatische Zuordnung selbstdefinierter Layouts zu den einzelnen Kategorien. Wenn da jemand eine gute Lösung parat hat, wäre ich für Hinweise dankbar!

Unendliche Konfigurierbarkeit – auf Kosten der Übersichtlichkeit

Was mir sehr, sehr gut gefällt sind die nahezu unendlichen Möglichkeiten, die Seitendarstellung nach eigenen Wünschen zu konfigurieren ohne auch nur eine Zeile programmieren zu müssen. Ob es um die Darstellung einzelner Artikel, Menüeinträge, Module oder sonstwas geht, man hat in Joomla über das Kontrollzentrum schier unendliche Möglichkeiten der individuellen Konfiguration. Man muss die entsprechenden Optionen nur finden, und das ist manchmal gar nicht so einfach.

Es gibt weniger OpenSource-Plugins

Ich bin beim Testen immer wieder darüber gefallen, dass Joomla-Erweiterungen mit der benötigten Funktionalität nur als Paid Downloads erhältlich sind, die Auswahl kostenloser Zusatzmodule ist erheblich beschränkter als bei WordPress. Insbesondre im Bereich Datenimport/Export ist das Angebot kläglich bis nichtexistent, deswegen hab ich ja den ganzen Bauchaufzug mit dem WordPress-Import selber aufgestellt.

Auch das führende Formular-Plugin Breezing Forms kann in der Free-Version mit dem guten alten ContactForm 7 nicht mithalten. Die Erstellung einfacher Formulare geht ja noch, aber sobald man versteckte Felder oder Systemvariable braucht, ist man komplett aufgeschmissen. Das ist ein derartiger Verhau undokumentierter Optionen und Konfigurationsmöglichkeiten mit denen sich kein Schwein auskennt, das finde ich einfach völlig unmöglich.

Der Support ist ziemlich gut

Ich habe sowohl im deutschsprachigen Joomla-Forum (https://forum.joomla.de/) als auch auf Stackexchange (https://joomla.stackexchange.com/) viele wertvolle Hinweise und Lösungen bekommen, wenn ich mal gar nicht weiterwusste. Joomla hat offenbar eine sehr aktive Support-Community, da werden sie im Zweifelsfall schon geholfen 🙂

Eigenentwicklung von Komponenten und Modulen

…ist in Joomla eine Wissenschaft für sich. Man kommt nicht darum herum, sich mit dem Model-View-Controller (MVC) Modell auseinanderzusetzen, und das ist zwar recht gut dokumentiert, aber auch derart umfangreich, dass man nicht um eine intensive und langwierige Einarbeitung herumkommt. Mal eben schnell ein Plugin auf die Füße stellen wie in WordPress geht so nicht, wer sich näher dafür interessiert kann mal hier anfangen: Entwicklung einer MVC-Komponente

Aber sagt nicht, ich hätte euch nicht gewarnt!

Das Datenbankmodell ist der reine Overkill

Mit über 70 lausig dokumentierten Tabellen gönnt sich Joomla da ein Datenmodell, das nur für jahrelang geübte Joomla-Experten zu durchblicken ist. Erschwerend kommt hinzu, dass selbst so vermeintlich einfache Konzepte wie die Tags/Schlagwörter auf eine Tabelle mit 30 Einträgen abgebildet werden. Wozu, frag ich mich, braucht ein Tag images, urls, hits, publish-up und downtime und den ganzen Russ? Da läuft was aus dem Ruder, da sind den Entwicklern die Objekte wesentlich zu aufgeblasen aus dem Nest gefallen. Hier wäre Einiges an Verschlankung möglich, zu Gunsten der Verstehbarkeit.

Schlußbemerkung

Was mir an Joola so richtig ans Herz gewachsen ist sind die vielfältigen Konfigurationsmöglichkeiten über das Kontrollzentrum, was ich absolut überzogen finde ist der Aufwand, den man treiben muss, um eigene Komponenten oder Module aufzustellen.  Ich halte Joomla für eine sehr gute Alternative, wenn man das Kategorienmodell richtig einsetzt, auch wenn das etwas mehr Planungsaufwand als beim Erstellen einer neuen Seite mit WordPress bedeutet. Joomla ist meiner Meinung nach das modernere, vielseitigere CMS, man muss nur aufpassen dass man beim praktischen Einsatz nicht mit Kanonen auf Spatzen schiesst. Oft sind „kleine“ Lösungen über den Sourcerer oder die PHP-Bridge möglich, bevor man tiefer in das MVC-Modell einsteigen muss. Insgesamt aber ist Joomla ein sehr faszinierendes und vielseitiges Werkzeug für Webdesigner, das ich in Zukunft sicher für etliche Projekte empfehlen und einsetzen werde.

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Erweiterungen installieren: kleines Beispiel

Da fehlte doch noch was im Joomla-Inselfischkochbuch: das Zufallsrezept geht noch ab! Kurzes Googlen ergab, dass „Random Article“ von Artur Alves genau das können sollte, was ich brauchte. Also los:

Erweiterung installieren

Erweiterungen->Verwalten-> Installieren, hier sollte man sich bequemerweise den Tab „Aus Webkatalog installieren“ aktivieren, dann gehts genauso wie in WordPress mit dem Plugin-Verzeichnis. Erweiterung mit dem Namen suchen, wenn man die richtige gefunden hat wird man vom Assistenten durch die Installation geführt.

Modul anlegen

Mit Erweiterungen->Module->Neu->Random Article kann man sich jetzt ein eigenes Modul für den zufällig ausgewählten Artikel anlegen. Unter „Article Source Options“ wählt man sich die Kategorie aus, aus der der Zufallsartikel kommen soll, man könnte hier auch Subkategorien einbeziehen, aber die habe ich (noch) nicht. Namen für das Modul vergeben, darf ruhig „Zufallsrezept“ heissen, speichern.

Neuen Menüeintrag und Beitrag anlegen

Viele Wege führen in diesem Fall nach Rom, ich packe das neue Modul wieder in einen eigenen Beitrag und ordne diesem einem Menüeintrag zu.

Menüs->Main Menu->Neuer Menüeintrag-> Name „Zufallsrezept“, Menüeintragstyp einzelner Beitrag, den kann man hier gleich neu anlegen. Im Beitragseditor die Option Module anklicken und hier unser eben neu erstelltes Modul auswählen, beliebigen Text dazuschreiben, speichern und fertig. Wenn alles richtig geklappt hat, steht im Editor jetzt ungefähr sowas:

{loadmodule mod_random-article,Zufallsrezept}

Das kann man sich schon mal merken, diese Syntax wird uns noch öfter begegnen. Das wars jetzt aber auch schon, wir haben unser Zufallsrezept jetzt auch eingebaut.

Meckerpunkt am Rande: die Erweiterungs-Verwaltung

Wenn man unter Erweiterungen->Verwalten sowas wie den Pluginmanager erwartet, guckt man zuerst mal ganz schön, da springen einem neun Seiten mit mehr oder weniger kryptischen Einträgen entgegen. Weil hier nämlich auch die systeminternen Erweiterungen, Module und Komponenten mit angezeigt werden, und da fasst man tunlichst erstmal gar nichts an. Benutzerfreundlich ist das nicht, hier hätte ich mir eine übersichtlichere Lösung gewünscht!

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Kontaktformular in Joomla mit Bordmitteln

Ich liebe ja mein Contact Form 7 und benutze es auf nahezu jeder WordPress-Webseite, und jetzt wollen wir mal sehen ob Joomla da Vergleichbares zu bieten hat. Wir brauchen ja zumindest auf der Kontakt/Impressum-Seite ein kleines Kontaktformular mit den relevanten Daten und der Möglichkeit, mir eine E-Mail zu schicken.

Die Joomla-eigene Kontaktverwaltung

Über Komponenten->Kontakte->Kontakte hat man die Möglichkeit, aus den vorhandenen Benutzern eine beliebig umfangreiche Liste mit Kontakten zu generieren. Das ist für meine Zwecke mit Kanonen auf Spatzen geschossen, hier gibt es nur einen Benutzer (mich, den Super User) und eine einzige Kontaktperson, nämlich die Evi S. Leu. Macht aber nix, lege ich halt den einen einzigen Kontakt an und fülle ihn mit den korrekten Informationen, essentiell ist hier die Zuordnung des verknüpften Benutzers:

kontakt_evi

kontakt_evi

Ein Bild kann man auch noch hinzufügen, dann speichern und schliessen.

Kontakt in Beitrag einfügen

Für den Menüpunkt Kontakt/Impressum hatte ich einen einzelnen Beitrag verknüpft, den geh ich jetzt bearbeiten. Über die Option „Kontakte“ kann ich jetzt den soeben erstellten Kontakt in den Beitrag einfügen.

kontakt_einfuegen

kontakt_einfuegen

Ich formatiere mir den Kontakt schön groß (36pt) und unterstrichen, damit er auch ins Auge fällt, der Default ist nämlich in meinem Template zu winzig und unauffällig. Speichern, und jetzt gehen wir uns die Seite Kontakt/Impressum mal ansehen:

kontaktimpressum

kontaktimpressum

Zugegeben, man muss jetzt erstmal auf die Idee kommen, den Kontakt auch anzuklicken, aber so abwegig ist das nicht, oder?

Klick auf „Kontakt Evi S. Leu“ ergibt:

kontakt_screenshot

kontakt_screenshot

Juppidu, und da versteckt sich auch die Option „Kontaktformular“! Das sieht dann so aus:

kontaktformular

kontaktformular

Na, da haben wir doch alles was wir brauchen. Zugegeben, das Nachricht-Feld hätte ein wenig grösser ausfallen können (man kann es aufziehen), aber sonst ist alles in Butter, wir haben unser eigenes Kontaktformular mit wenigen Klicks mit Bordmitteln zusammengebastelt.

Jetzt wollen wir mal sehen, ob es uns auch gelingt ein wirklich benutzerdefiniertes Formular zusammenzubasteln, aber dafür gibt es einen neuen Beitrag. Sobald ich dazugekommen bin, mir das Breezing Forms mal näher anzuschauen, das scheint der Formulareditor der Wahl für Joomla zu sein. Kann ein Weilchen dauern!

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Andere Eltern haben auch schöne Kinder: Joomla für alte Programmierer

Oder sollte es Joomla für alte WordPressler heissen?

Wie dem auch sei, ich hatte gerade in einem aktuellen Projekt die Gelegenheit, mir Joomla in Aktion näher anzugucken, und habe beschlossen, eine kleine Serie für WordPress-Umsteiger darüber zu schreiben. Joomla liegt in der Rangliste der gängigen CMS laut statista,com aktuell mit 6,5 % Marktanteil auf Platz 2 hinter WordPress (60%, mit ca. 19,500,000 aktiven Websites), zwar weit abgeschlagen, aber mit rund 2 Millionen Installationen weltweit ist das noch ein respektabler Rang, der das nähere Hingucken rechtfertigt.

Die Installation

Joomla ist genauso einfach zu installieren wie WordPress und wird ohnehin bei den meisten Hostern als One-Klick-Installation oder dergleichen fertig vorkonfiguriert angeboten, so dass man es leicht „mal schnell ausprobieren“ kann. Ich konzentriere mich hier auf den Versionszweig 3.x, die technischen Voraussetzungen können sie hier bei Joomla Downloads nachlesen. Bei mir läuft Joomla 3.8.4 lokal auf Xampp 7.2.1, allerdings mit einigen kleinen „Glitches“, die aber beim Testen nicht weiter stören. Die Installation läuft prinzipiell nicht anders als bei WordPress, die heruntergeladene Zip-Datei entpackt man in ein eigenes Unterverzeichnis auf dem Server und wird dann von einem Installationsassistenten durch den Prozess geführt, schauen sie mal hier bei joomla.org für detaillierte Informationen zur Installation. Joomla benötigt eine Mysql-Datenbank, es besteht aber auch die Möglichkeit wie bei WordPress über ein Tabellen-Präfix mehrere Joomla-Instanzen innerhalb einer Datenbank zu betreiben. Sie können bei der Installation auswählen, ob sie Joomla mit Beispieldaten installieren möchten oder ohne, ich habe mir dafür einfach zwei Instanzen angelegt.

Der erste Eindruck

Ein kurzer Blick auf die Datenbank: Joomla gönnt sich 72 Tabellen. Die wichtigsten werde ich im Laufe dieser Serie einzeln herauspicken und näher beleuchten, für den Anfang nehmen wir das erstmal so hin. Ansonsten gibt es viele Parallelen zu WordPress – schließlich sind beide Anwendungen datenbankbasierte CMS, da ist schon ein hoher Verwandschaftsgrad vorhanden. Es gibt auch in Joomla ein Frontend und ein Backend, letzteres heißt hier Kontrollzentrum. Es gibt auch eine ausgefeilte Benutzerverwaltung, aber um die werde ich mich in Joomla genauso wenig kümmern wie in WordPress, einfach weil sie in meiner Praxis – beim Erstellen von Webseiten für kleine und mittlere Unternehmen – selten wirklich zum Einsatz kommt. Ich gehe im Zweifelsfall davon aus, dass mit der Erstellung und Pflege der Webseite nur der Administrator zu tun hat, und in den meisten Projekten läuft das auch so.

Zurück zum ersten Eindruck: wenn  man sich eine Joomla-Installation mit Inhalten geladen hat, sieht man auch schon mal ein nettes Frontend. Dessen Aussehen wird bestimmt von dem verwendeten Template, das entspricht ganz dem WordPress-Theme. Default-mäßig wird das Template protostar verwendet, ich habe mir für meine Testseite das Template pixel in der Free Edition ausgesucht, weil das Layout einigermassen zu meinen Anforderungen passt. Man kann Templates genauso einfach wechseln wie Themes in WordPress, und es gibt unzählige kostenlose Templates für alle möglichen Anforderungen im Web, suchen sie sich einfach eins aus, und dann legen wir los.

Das erste hübsche Feature: die Template-Positionsvorschau

Um sich einigermassen zu orientieren, was im verwendeten Template wohin paßt, bietet Joomla eine sehr praktische Funktionalität: sie können unter Erweiterungen/Temlates/Templates bei den Optionen einstellen, dass die Vorschau von Modulpositionen aktiviert wird. Wenn sie dann beim Aufruf ihres Frontends den Parameter ?tp=1 an die URL anhängen (z.B. „http://localhost/joomla30/?tp=1“), bekommen sie angezeigt, an welchen Stellen und unter welchen Positionsbezeichnungen sie in ihrem Template Inhalte einsetzen können, das sieht dann z.B. so aus:

modulpos_screenshot

modulpos_screenshot

So hat man gleich mal eine Übersicht, was im betreffenden Template wohin gesetzt werden kann, und welcher Style für die entsprechende Position verwendet wird. Ein sehr sympathisches Feature, finde ich.

And now start Blogging… nee, so schnell gehts leider nicht

Es ist ein wenig mehr Vorarbeit als in WordPress zu leisten, ehe man eigene Inhalte  sinnvoll online stellen kann. Wir fangen mal damit an, eine in WordPress vorhandene Webseite zu duplizieren, und ich nehme dafür – wie könnte es anders sein? – mein Inselfisch-Kochbuch. Das hat eine übersichtliche und in der Praxis bewährte Struktur und nicht zu viele Features, so dass man sich nicht verzettelt. Mal sehen, was sich in Joomla daraus machen läßt, aber dazu gibts einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Beitragskategorien aus der Datenbank abfassen

Für Spitzenklöppler: das WordPress-Kategorienmodell

Um an die Beitragskategorien heranzukommen, muss man sich mit sage und schreibe 5 Tabellen herumschlagen. Das kommt daher, weil die WordPress-Entwickler das Kategorienmodell unbedingt mehrstufig anlegen mussten. Das ist zwar wunderbar verschachtelbar und ergibt ganz eindrucksvolle Baumstrukturen, aber datenverarbeitungstechnisch ist es meiner Meinung nach mit Kanonen auf Spatzen geschossen. Mit einer winzigen Ausnahme (die Backrezepte im Inselfisch-Kochbuch) habe ich noch in keinem meiner Blogs eine Unterkategorien-Ebene gebraucht, und damit das hier nicht allzu unübersichtlich wird, lasse ich es auch bei der einen Ebene. Haben sie ein bißchen Zeit? dann wollen wir mal.

Die relevanten Tabellen

Erstens natürlich die wp_posts, aus der holen wir uns die ID, also den Primärschlüssel der Beiträge. Dann brauchen wir noch:

  • wp_term_relationships
  • wp_term_taxonomy
  • wp_terms
  • (wp_termmeta, nein, die brauchen wir nicht, nur der Vollständigkeit halber erwähnt)

Warum das ganze mit Term und nicht mit Category bezeichnet ist: rein theoretisch kann man sich auch noch eigene Taxonomien anlegen, die dann eben nicht Kategorie heissen sondern einen eigenen Namen kriegen. Sowas hab ich anno Dunnerkeil mal in meinem Bilderblog gemacht, da gabs eine eigene Taxonomie „Jahreszeiten“, die bestand aus genau vier Einträgen, nämlich „Frühling, Sommer, Herbst, Winter“. Bin ich wieder davon abgekommen, ich hab die Jahreszeiten einfach in die erste Kategorieebene mit aufgenommen, geht auch und ist wesentlich einfacher zu verwalten. Aber das nur am Rande bemerkt, wir holen uns die Tabellen jetzt mal ins Access rein und basteln uns die nötigen Verknüpfungen.

Das Datenmodell im Detail

Die ersten beiden Tabellen: wp_term_relationships und wp_posts

Wichtig ist hier erstens die object_id, das ist die ID des Beitrags aus der wp_posts. Einem Beitrag können ja mehrere Kategorien zugeordnet sein, deshalb tauchen die IDs hier auch mehrfach auf. Die term_taxonomy_id verweist auf die Kategorie. Die term_order könnte man für eine benutzerdefinierte Sortierung der Kategorien verwenden, aber das geht jetzt zu weit, das lassen wir weg.

screenshot_term_relationships

screenshot_term_relationships

Wir basteln uns also die erste Verknüpfung mit der object_id auf die wp_posts.

screenshot_beziehnungen_posts_relationships

screenshot_beziehnungen_posts_relationships

Die dritte Tabelle: wp_terms_taxonomy

Hier wird es schon ein bißchen undurchsichtiger. Die ersten drei Felder ID, term_taxonomy_id und term_id haben alle den selben Wert, da kann man nur raten wofür welches gut ist. Da wir nur die term_taxonomy_id aus der wp_term_relationships eindeutig zuordnen können, nehmen wir die halt, und merken uns als Hauptschlüssel die ID. Im Feld taxonomy steht immer der Wert category, wir haben ja nur diese eine Taxonomie, das können wir auch weglassen. Interessanter wäre da noch das Feld „parent“, das die übergeordnete Kategorie im Falle verschachtelter Kategorieebenen enthält, aber auch das lassen wir mal aussen vor, sonst blickt hier kein Schwein mehr durch.

Kleine Kuriosität am Rande: hier wird ein count mitgeführt, der die Anzahl der Beträge zu einer Kategorie wiederspiegelt. Kann man das nicht nachher im Rahmen einer Abfrage berechnen?

screenshot_term_taxonomies

screenshot_term_taxonomies

Unsere Beziehungen sollten jetzt so aussehen:

screenshot_beziehungen_3

screenshot_beziehungen_3

Die vierte Tabelle: wp_terms

Na gottseidank, da blickt man wenigstens halbwegs durch. Die term_id können wir aus der wp_term_taxonomy zuordnen, der name (na endlich!) ist der Name der Kategorie, slug ist auch klar, und die term_group ignorieren wir einfach.

screenshot_wp_terms

screenshot_wp_terms

Jetzt kommt endlich Butter bei die Fische, wir können unsere Beziehungen vervollständigen.

screenshot_beziehungen_4

screenshot_beziehungen_4

Haben wir da nicht noch was vergessen?

Die Tabelle wp_termmeta

Ja, die gibts auch noch, aber ehrlich gesagt weiß ich nicht so ganz genau, wofür man die verwenden könnte, die zieht nur wenn man mit mehreren Taxonomien arbeitet. Bei marketpress gibt es eine gelehrte Abhandlung dazu, ich hab sie allerdings nicht ganz verstanden, muss ich zugeben. Nachdem die Tabelle allerdings bei mir immer leer ist, ignoriere ich sie schlicht und ergreifend.

Sonst noch was? Ach ja, ich hätts beinah vergessen:

Die Tags = Schlagwörter stecken in der selben Logik

Und zwar wird für die Schlagwörter eine eigene Taxonomie „post_tag“ angelegt. Ich verwende prinzipiell keine Schlagwörter, wenn sie es getan haben lassen sie sich nicht irritieren, uns reichen die Beziehungen über die Kategorien.

Und jetzt: die Abfrage der Kategorien über alle vier Tabellen

Anmerkung: damit das hier nicht total uferlos wird, beschränke ich mich hier auf eine Kategorieebene. Sie sehen gleich, warum: Wir holen uns zunächst mal eine Auswahl relevanter Daten aus allen vier Tabellen, der SQL sieht dann so aus:

SELECT wp_posts.ID, wp_posts.post_title, wp_term_relationships.object_id, wp_term_relationships.term_taxonomy_id AS wp_term_relationships_term_taxonomy_id, wp_term_taxonomy.term_taxonomy_id AS wp_term_taxonomy_term_taxonomy_id, wp_term_taxonomy.term_id AS wp_term_taxonomy_term_id, wp_term_taxonomy.taxonomy, wp_term_taxonomy.count, wp_terms.term_id AS wp_terms_term_id, wp_terms.name
FROM wp_terms INNER JOIN ((wp_posts INNER JOIN wp_term_relationships ON wp_posts.[ID] = wp_term_relationships.[object_id]) INNER JOIN wp_term_taxonomy ON wp_term_relationships.[term_taxonomy_id] = wp_term_taxonomy.[term_taxonomy_id]) ON wp_terms.[term_id] = wp_term_taxonomy.[term_id];

Das Ergebnis: eine schon mal relativ übersichtliche Tabelle

Hier taucht jedes Rezept so oft auf, wie es Kategorien zugeordnet hat. Wenn wir jetzt ausser den Kategorien noch Schlagwörter mit drin hätten, müssten wir die herausfiltern, aber haben wir nicht, alles brav nur Kategorien.

screenshot_kategorien_rohdaten

screenshot_kategorien_rohdaten

Ein kleiner Kunstgriff: die Abfrage auf der Abfrage

Damit ich mir keinen Wolf parametrisiere, habe ich einfach auf die eben gezeigten Rohdaten (die Abfrage heisst auch kategorien_rohdaten) eine zweite Abfrage aufgesetzt, die ist schon übersichtlicher:

SELECT Count(kategorien_rohdaten.[ID]) AS AnzahlvonID, kategorien_rohdaten.[name]
FROM kategorien_rohdaten
GROUP BY kategorien_rohdaten.[name];

Auf Deutsch: ich zähle nur die Beitrags-IDs zu jeder genannten Kategorie, und fasse pro Kategorie die Summe zusammen. Das Ergebnis:

screenshot_kategorien_endergebnis

screenshot_kategorien_endergebnis

Na bitte, geht doch 🙂

Nur noch ein kleiner Glitch ist drin: die Summe beim Backwerk stimmt nicht. Das kommt daher, dass ich bei den Backwerken drei Unterkategorien angelegt habe, nämlich „Kuchen und Torten“, „Weihnachtsbäckerei“ und „Pikante Bäckereien“. Allerdings erlaubt es einem WordPress beim Erstellen oder Bearbeiten eines Beitrags, eine Unterkategorie anzugeben ohne auch die übergeordnete Hauptkategorie anzukreuzen, das habe ich offensichtlich einige Male gemacht, und daher stammt der Zählfehler. Die Korrektur ist einfach: ich entferne die Kategorie Backwerk und behandle die drei Unterkategorien wie Kategorien erster Ordnung, mein Excel für das Tortendiagramm kann mit Unterkategorien eh nix anfangen 🙂

Ich überlasse es jedem, der mit mehr als einer Kategorieebene gearbeitet hat selber, da die Logik entsprechend rauszupfriemeln, da muss man in der wp_terms_taxonomy den parent berücksichtigen, das ist mir jetzt hier zuviel Gedöns. Das hier langt jetzt nämlich echt für einen Beitrag, der hier ist lang genug – schließlich ist ja schon fast Feiertag!

 

 

 

 

 

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend