Archiv der Kategorie: Datenbank (Joomla)

Das hab ich bislang unterschlagen: benutzerdefinierte Felder

Analog zu den Custom Fields in WordPress kann man auch in Joomla selbstdefinierte Felder zu den Artikeln anlegen. Ich bin da gleich mal reingerasselt, weil ich zu den Kochbüchern ein Feld „Unverbindliche Preisempfehlung“ haben wollte. Schauen sie mal unter Inhalte/Felder/Neu die Liste der Feldtypen an – da ist alles dabei, bloß keine Währung, der einzige verfügbare Zahlentyp ist Integer. Ein Datumsfeld sucht man auch erstmal, es versteckt sich hinter dem Feldtyp „Kalender“. Ansonsten stecken in den Feldtypen jede Menge Angaben, die ich für Spielerei halte, unter anderem auch ein Feldtyp „Farbe“, man sehe und staune:

rgb_feld

rgb_feld

Damit kann man sich im Frontend den RGB-Code der gewählten Farbe anzeigen lassen, wofür das auch immer gut sein soll.

Wenigstens kann man beim Anlegen der Felder angeben ob es sich um ein Pflichtfeld handelt, dann kriegt man beim Ausfüllen der Beiträge einen Hinweis, wenn was fehlt. Wo sich die Felder und die Feldinhalte wiederfinden lassen, dazu gibts einen:

Blick auf die Datenbank

Man kann auch noch Feldgruppen anlegen, aber das lassen wir mal aussen vor, sonst wirds zu kompliziert. Ich möchte jetzt einfach in einem Artikel den Wert eines benutzerdefinierten Feldes anzeigen, und zwar an beliebiger Stelle im Inhalt. Und – da bin ich ein bißchen eigen – ich möchte das auf relativ einfachen Weg in einem Sourcerer Codesnippet tun, ohne Overrides und Module.

Dafür tun wir mal einen beherzten Griff in die Datenbank. Die relevanten Tabellen sind die #__contents, aus der brauchen wir die ID des Artikels, die Tabelle #__fields, aus der holen wir uns den Feldnamen und nach Belieben auch die Feld-ID, und schliesslich die #__fields_values, in der stecken schlussendlich die Werte der Felder. Ich habs mal kurz nach Access reingeschubst, da stellen sich die Beziehungen so dar:

fields_beziehungen

fields_beziehungen

Also, frisch auf, einen Join über alle drei Tabellen gebastelt, wichtig ist hier die item_id, die identifiziert unseren Artikel:

felder_join_alle_drei

felder_join_alle_drei

Der Select dazu sieht so aus und ist relativ straightforward:

SELECT Fields_values.field_id, Fields.name, Fields_values.item_id, Fields_values.value
FROM Fields INNER JOIN (Content INNER JOIN Fields_values ON Content.[id] = Fields_values.[item_id]) ON Fields.[id] = Fields_values.[field_id];

Wir wollen aber nur die Feldinhalte zum aktuellen Artikel ausgeben, ich nehm mal den mit der ID 22 und klemm noch eine Where-Klausel dran. Dann können wir uns auch den Join auf die #__contents noch sparen, die ID des Artikels ist ja erstmal fest.

SELECT Fields_values.field_id, Fields.name, Fields_values.item_id, Fields_values.value
FROM Fields INNER JOIN Fields_values ON Fields.[id] = Fields_values.[field_id]
WHERE (((Fields_values.item_id)=“22″));

Ergebnis wie erwartet:

felder_nur22

felder_nur22

Und jetzt kann man sich anhand der field_id oder dem field name ein benutzerdefiniertes Feld herauspicken, ich nehm mal den Namen:

SELECT Fields_values.field_id, Fields.name, Fields_values.item_id, Fields_values.value
FROM Fields INNER JOIN Fields_values ON Fields.[id] = Fields_values.[field_id]
WHERE (((Fields.name) Like „farbtest“) AND ((Fields_values.item_id)=“22„));

Schon haben wir den Datensatz mit dem richtigen Feldwert eingekreist:

felder_nurfarbtest

felder_nurfarbtest

Na bitte, geht doch!

Und wo kriegen wir jetzt die aktuelle Artikel-ID her?

Das ist eine berechtigte Frage, man kommt ihr aber mit folgender Konstruktion bei:

$article_id = JFactory::getApplication()->input->get('id');

Jetzt basteln wir uns wie gehabt ein neues Datenzugriffsobjekt in der Variablen $db, dazu muss man noch ein bisschen bei den doppelten und einfachen Hochkommata aufpassen und das Präfix #__ nicht vergessen, aber das sollte eigentlich problemlos klappen.:

$db = JFactory::getDBO();

$query = „SELECT #__fields_values.field_id, #__fields.name, #__fields_values.item_id, #__fields_values.value
FROM #__fields INNER JOIN #__fields_values ON #__fields.id = #__fields_values.field_id
WHERE (#__fields_values.item_id = „.$article_id.“ ) and (#__fields.name like ‚farbtest‚);“;

Die Variable $article_id schubsen wir in unseren Select rein, den Namen des benutzerdefinierten Feldes kann man auch auf eine Variable legen, oder man verdrahtet es fest wie ich es getan habe. Das war schon der ganze Zauber!

Query zuweisen und ausführen:

$db->setQuery($query);
$result = $db->execute();

Objektliste laden, auch wenn wir nur 1 Zeile im result haben:

$results = $db->loadObjectList();

Ausgabe des Wertes aus dem Feld value mit foreach(), :

foreach ($results as $zeile) :
echo $zeile->value;
endforeach;

Das wars, da haben wir den Wert unseres benutzerdefinierten Feldes, und der kann an beliebiger Stelle im Artikel positioniert werden. Die anderen benutzerdefinierten Felder kann man natürlich auch mit dem Namen ansprechen, das geht ganz genau so wie hier vorgeführt.

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Ein Blick auf die Datenbank: Content und Konsorten

Einen Überblick über die in Joomla enthaltenen Tabellen kann man hier in der Joomla Documentation zum Thema Tables finden. Da werden allerdings nur die Tabellenstruktur und die Felddefinitionen aus der Datenbank zusammengefasst und keine weitere Erklärung dazu geliefert – das meiste davon könnte man auch im phpmyadmin herausfinden. Zur Tabelle contents heißt es zum Beispiel nur lapidar: „This table is used to store the content of your Joomla! core articles.“ Ah ja. Das hätte man sich evtl. selber denken können.

Also ist es vielleicht ganz interessant, mal ein bißchen hinter die Kulissen zu gucken, aber mit über 70 Tabellen macht es einem Joomla da nicht gerade einfach. Trotzdem, fangen wir mal an.

Die Tabelle contents

Wie wir am Anfang schon gesehen haben, macht Joomla im Gegensatz zu WordPress keinen Unterschied zwischen Beiträgen und Seiten, es ist zunächst mal alles Content. Das ist auch völlig legitim, da sehr fein gesteuert werden kann, ob ein Element einen Kategorieblog, einen einzelnen Artikel, ein Modul oder sonst etwas enthalten soll.

Fangen wir mal von vorne an:

id klar, AutoIncrement und Primärschlüssel

asset_id Fremdschlüssel auf die assets-Tabelle, dazu später mehr

title auch klar, der Titel des Artikels, wie er im Frontend angezeigt wird

alias sanitized Form des Titels für die sprechende URL

introtext und fulltext: da machen wir mal einen kleinen Break und eine Erklärung.

Introtext und Fulltext

Joomla bietet eine sehr komfortable Möglichkeit, im Artikeleditor ein „Weiterlesen“-Tag an beliebiger Stelle im Text einzufügen:

weiterlesen

weiterlesen

Das hat den Effekt, dass in der Blog-Ansicht nur der Text vor dem Tag angezeigt wird und ein Button zum (eben!) weiterlesen angezeigt wird:

weiterlesen_screenshot

weiterlesen_screenshot

Was da im Hintergrund auf der Datenbank passiert, ist recht kurios. Sobald man das Weiterlesen-Tag eingefügt hat, landet der Text vor dem Tag im Feld introtext, der Rest im Feld fulltext, der Artikeltext wird also auf zwei Datenbankfelder aufgeteilt. Nimmt man das Tag wieder heraus (Editor auf Textmodus umschalten und das Tag <hr id=“system-readmore“ /> löschen), wird wieder der gesamte Text im Feld introtext gespeichert, das Feld fulltext ist dann wieder leer.

Weiter gehts mit den Feldern der Tabelle content:

state entspricht dem post_status von WordPress, hier gilt für Joomla 3.x, soweit ich das eruieren konnte:

  • 0 = unpublished
  • 1 = published
  • 2 = archived
  • -2 = marked for deletion

catid ist die ID der Kategorie und ein Fremdschlüssel auf die categories-Tabelle.

created_by ist die UserID und ein Fremdschlüssel aus der #__users-Tabelle

Dann folgen noch ein paar Timestamps, deren Feldnamen recht selbsterklärend sind, und weiter hinten als kleines Zuckerl für SEOler ein  Feld hits, in dem die Anzahl der Zugriffe auf den betreffenden Artikel hochgezählt wird.

Lassen sie sich vom Feld images nicht aufs Glatteis führen, da steht nichts weiter drin, wenn sie kein Einleitungsbild oder komplettes Beitragsbild ausgewählt haben. Bilder, die sie im Artikeleditor eingefügt haben, stehen wie in WordPress gehabt als img-tag im Beitragstext, default Pfad ist das images-Verzeichnis: <img src=“images/avocado.jpg“ alt=““ />

Na, und was seh ich da? Der alt-Text ist leer, Schlamperei! Aber das ist eine andere Baustelle, und ich wette, das Verwirrspiel um die alt-Texte ist derselbe systemimmanente Bug wie in WordPress. Aber zur Bilderverwaltung in Joomla gibts ein andermal mehr!

Haben sie auch ein Deja vu?

Mit den hier vorgestellten Feldern aus der contents wäre es schon mal ein leichtes Spiel, einen einfachen WordPress-Beitrags-Datensatz zusammenzubauen. Vielleicht ist das der Grund, warum es eine Menge Konverter von Joomla nach WordPress schon gibt, googlen sie mal nach „joomla to wordpress converter“. Der Weg von WordPress nach Joomla ist da schon steiniger, weil die Joomla-Artikel wesentlich komplexer aufgebaut sind, aber darüber habe ich mich bereits in diesem Artikel ausgelassen. Ich bleibe dran…

Damit lassen wir es mal gut sein mit der Contents-Tabelle, und werfen als nächstes einen Blick auf die Bilderverwaltung in Joomla.

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend