Archiv für den Monat: Februar 2018

Hätt ich doch beinah übersehen: das Bewertungsformular

Das wär mir doch beinah durch die Lappen gegangen, wir brauchen natürlich noch das Feedback-Formular bei den Rezepten. Im Original-Inselfischkochbuch sieht das so aus:

bewertungsformular_screenshot

bewertungsformular_screenshot

Ich habs in WordPress natürlich mit dem Contact Form 7 angelegt, und dann das Plugin WP Post Signature genutzt, um das Formular automatisch am Ende jedes Beitrags einzufügen. Wollen mal sehen, was sich in Joomla daraus machen läßt. Ich hab mal einen ersten Versuch mit BreezingForms gestartet, schauen wir mal wie weit wir kommen.

Die Anforderungen im Klartext:

  1. das Formular soll am Ende jedes Rezeptes automatisch angehängt werden
  2. damit ich weiß, welches Rezept bewertet wurde, muss der Titel (oder wenigstens die ID) aus der E-Mail hervorgehen

Zu 1.: das hört sich einfacher an als es ist, denn eigentlich sind es zwei Anforderungen, wenn nicht sogar drei.

Das BreezingForms-Plugin

Um ein BreezingForms-Formular überhaupt in einem Artikel anzeigen zu können, muss man das BreezingForms-Plugin installieren. Das findet man, wenn man das BreezingForms-ZIP entpackt hat, unter plg_breezingforms.zip . Nach der Installation muss es noch aktiviert werden, das geht unter Erweiterunge->Module-> Suche nach „breezing“, Pluginname BreezingForms aktivieren. Erst jetzt hat man die Möglichkeit, ein BreezingForms Formular auch in einen Artikel einbinden zu können, und zwar  mit der Syntax:

{ BreezingForms : formularname }

Das fett markierte ist der Name des Formulars. Aber damit haben wir noch nicht viel gewonnen, schließlich müßte man diesen Code am Ende jedes Rezeptes manuell einfügen, und das war nicht die Anforderung.

Wie wärs stattdessen mit einem Modul?

Dafür braucht man laut crosstec noch das extra-Modul, mod_breezingforms.zip. Nach der Installation freigeben nicht vergessen! Dann kann man ein neues Modul vom Typ „BreezingForms“ anlegen und das gewünschte Formular angeben. Falls es nicht angezeigt wird kann es sein dass in den Moduloptionen in der Menüzuweisung „auf keinen Seiten“ steht, das muss man natürlich auf „auf allen Seiten“ ändern.

So, und was hat uns das gebracht?

Auch das Modul muss man erstmal per Hand am Ende jedes Rezeptes einfügen, das ist noch kein grosser Fortschritt aber gemach, gemach, das wird schon noch.

Warum nicht einen Override anlegen?

Weil bei einer Änderung der default.php das Bewertungsformular unter allen Artikeln angezeigt werden würde, nicht nur unter den Rezepten. Wir machen stattdessen mal ein alternatives Layout, das ist mir sympathischer.  Dafür kopiert man sich in den Ordner /templates/dein-templates/dein-template/html/com_content/article die Datei default.php unter einem eigenen Namen, ich nenns mal meins.php. In dieser Datei sucht man dann nach dem Eintrag

<?php echo $this->item->text; ?>

Darunter kopiert man die folgende Zeile:

<?php echo JHtml::_(‚content.prepare‘, ‚{loadposition bewertungsformular}‘); ?>

Jetzt geht man nochmal in das Modul für das Bewertungsformular zurück und ändert die Modulposition in bewertungsformular – Schreibweise genau einhalten!

Daraufhin muss man noch in einem beliebigen Rezept unter dem Reiter Optionen das Layout auf „meins“ stellen, dann wird das Formular nach dem Rezepttext auch angezeigt.

Das war jetzt aber auch noch nicht der Bringer?

Schließlich muss man auch das alternative Layout per Hand anwählen, ich geb zu, da ist noch nicht viel gewonnen, genauso schnell hat man ein Modul eingefügt. Das hängt jetzt alles daran, dass ich keinen Weg gefunden habe, ein Modul nur für eine Kategorie anzeigen zu lassen, und ich hab ein paar Stunden lang danach gesucht, bislang ohne Erfolg.

Ich hätte da noch so’ne Idee

Man könnte ja einen Override auf die default.php anlegen und abfragen, welche Kategorie der aktuelle Artikel hat, und abhängig vom Ergebnis das Modul anzeigen lassen oder nicht. Mal sehen, wie weit wir damit kommen.

In unserem Override der default.php für den Artikel suchen wir nach der Stelle:

<div itemprop=“articleBody“>
<?php echo $this->item->text; ?>
</div>

Danach schubsen wir eine Datenbankabfrage rein:

<?php
    $db=JFactory::getDbo();
    $article_id = JFactory::getApplication()->input->get(‚id‚);
    echo „aktuelle Artikelid= „.$article_id;
    
    $db->setQuery(’select catid from #__content where id= ‚.$article_id.“);
    $catid=$db->loadResult();
    echo „aktuelle catid= „.$catid;
    
    if ($catid == 8){
        echo JHtml::_(‚content.prepare‘, ‚{loadposition bewertungsformular}‘);
    }
    else {
        echo „Dies ist kein Rezept, Kategorie: „.$catid;
        }
    ?>

Was hab ich gemacht? Mir die ID des aktuellen Artikels geholt, diese in den Select auf die #__content reingeschubst und mir so die ID der Kategorie geholt. Rezepte sind bei mir Kategorie 8, das frage ich mit dem If ab und zeige das Formular nur an, wenn dies zutrifft. Das wars schon! Die Debug-Ausgaben kann man noch rausschmeissen, aber so funktionierts. Endlich wieder mal ein bisschen Spaß auf der Datenbank!

Was jetzt noch fehlt: die Übermittlung der Rezept-ID oder des Titels

Weil mir die ganze Menage nichts hilft, wenn ich nicht weiss zu welchem Rezept die Bewertung abgeschickt wurde. Da hilft nur Nachforschen beim BreezingForms-Support, aber dazu gibts einen neuen Beitrag.

Benutzerdefinierte Felder – im Beitrag anzeigen

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 ohne eigens programmierte Module. Kann ja wohl nicht so schwer sein!

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 unsere Where-Klausel rein, den Namen des benutzerdefinierten Feldes auch, das 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.

Kleine Spielerei am Schluss: wenn wir schon einen RGB-Farbwert haben, möchten wir die Farbe auch sehen, ich mach mal ein Quadrat von 300 px Kantenlänge. Dann kommt in der foreach-Schleife noch eine Variablenzuweisung mit:

foreach ($results as $zeile) :
$aktuelle_farbe = $zeile->value;
echo $zeile->value.“<br>“;
endforeach;

Die verwenden wir jetzt in einer Div für das Farbquadrat:

echo „<div style=’background-color:“.$aktuelle_farbe.“; width: 300px; height: 300px;‘><h2>Aktuelle Farbe</h2></div>“;

farbquadrat

farbquadrat

Na siehste, haben wir doch noch eine Anwendung für den Feldtyp „Farbe“ gefunden!

Nachtrag

Ich bin gefragt worden, warum ich denn nicht ein alternatives Layout für die Anzeige der Felder angelegt habe und dann einfach dort an der richtigen Stelle mit:

<?php echo $this->item->jcfields[x]->value; ?>

das Feld mit der Nummer x einfüge. Ganz einfach: ich wollte den Feldinhalt innerhalb des Beitragstextes ausgeben, das ist der ganze Witz an der Sache. Das geht im Template nicht, da dort der Beitragstext als Ganzes mit <?php echo $this->item->text; ?> hereingeholt wird, und man keine Chance hat da innerhalb etwas zu positionieren. Ist der Sinn und Zweck der Übung jetzt etwas klarer?

Noch ein paar lose Endchen

Haupteinträge

Das fällt einem im Beitragseditor relativ gross ins Auge, aber was bedeutet eigentlich Haupteintrag ja/nein? Ist eigentlich ganz einfach. Man kann beliebige Artikel als Haupteinträge kennzeichnen, das ist so etwas wie eine übergeordnete Kategorie. Eine Anwendung: wenn man alle Haupteinträge unter einem Menüpunkt sehen will, erstellt man einen neuen Menüeintrag mit dem Menüeintragstyp Beiträge->Haupteinträge. Hier kann man auch einstellen, ob Artikel aus allen Kategorien oder nur aus einer bzw. mehreren ausgewählten Kategorien angezeigt werden sollen. Somit hat man eine Möglichkeit, besonders wichtige oder interessante Artikel auch kategorieübergreifend in einer Blogansicht zusammenzufassen.

Navigationspfad einfügen

Unter Erweiterungen->Module-> Neu -> Navigation – Navigationspfad versteckt sich ein Modul, das einen „Wo bin ich“-Navigationspfad an der gewünschten Layoutposition ausgibt. Nützlich bei verschachtelten Untermenüs!

Blanko-Modul für eigene Inhalte

Man hat unter Module->Neu->Eigenes Modul die Möglichkeit, ein Modul mit selbstdefinierten Inhalten zu erstellen. Ich finde, hier ist eigener PHP-Code, mit Hilfe des Sourcerer eingefügt, gut aufgehoben. Man kann es aber auch für öfter genutzte Texte, z.B. Copyrightvermerke oder dergleichen gut gebrauchen.

Joomla und die Bilder: ein stiefmütterliches Verwirrspiel

Man hat in Joomla prinzipiell drei Möglichkeiten, Bilder in einen Artikel einzufügen. Einmal als Inline-Element im Beitragseditor, wie wir das auch von WordPress her kennen. Dann gibt es noch das Einleitungsbild, entspricht in etwa dem Artikelbild in WordPress und wird in der Blogansicht über dem Artikel dargestellt. Und schliesslich noch das komplette Beitragsbild, das wie der Name schon sagt in der kompletten Ansicht des Artikels zu sehen ist.

Zu beachten ist in allen drei Fällen: Joomla hat keine Hilfsmechanik zum Bilderskalieren, jedes hochgeladene Bild landet in voller Pracht und Grösse im images-Verzeichnis und wird für die Anzeige auch in voller Größe geladen. Da, wo es WordPress ein bisschen übertreibt mit einem halben Dutzend und mehr passend zum Theme skalierter Bildkopien, tut Joomla von selber rein gar nix. Und ich hab lang gegooglet, aber Joomla-Extensions zum komfortablen Bilderskalieren beim Hochladen gibts anscheinend nicht als Public Domain, das sind alles Paid Downloads. Scheint so als wenn einem ohne zusätzliche Software nichts anderes übrig bleibt, als hochzuladende Bilder vorher per Hand auf ein vernünftiges Maß zu skalieren. Keine so richtig benutzerfreundliche Lösung!

Einleitungsbild und komplettes Beitragsbild

Diese legt man im Artikeleditor unter dem Reiter „Bilder und Links“ an, hier kann auch der Alt-Text und eine Bildunterschrift angegeben werden. Eine Option für das title-Tag hab ich nicht gefunden, aber wenigstens der Alternativtext ist vorgesehen… man ist ja schon für Kleinigkeiten dankbar.

Die hier vorgenommenen Einstellungen landen übrigens im Datensatz des Artikels in der #__contents-Tabelle, im Feld images, das sieht dann zum Beispiel so aus:

{„image_intro“:“images\/Appetitbrtchen.jpg“,“float_intro“:““,“image_intro_alt“:“Bernhard i\u00dft ein Appetitbr\u00f6tchen“,“image_intro_caption“:“Bernhard mit Appetitbr\u00f6tchen“,“image_fulltext“:“images\/avocado.jpg“,“float_fulltext“:““,“image_fulltext_alt“:“Maitre Philippe bereitet Avocadoh\u00e4ppchen zu“,“image_fulltext_caption“:“Avocadoh\u00e4ppchen“}

Braucht uns aber eigentlich nicht weiter zu kümmern, man kanns ja im Editor an der Oberfläche einstellen.

Beitragsbilder im Beitragseditor

Hier wirds ein bisschen undurchsichtig, was die Zuordnung der img-Attribute angeht, aber ich versuchs mal der Reihe nach aufzudröseln.

Wenn man ein Bild hochlädt und in den Artikel einfügt ohne irgendwelche zusätzlichen Informationen anzugeben, sieht der img-Tag erstmal so aus:

<img src=“images/Johannisbeeren.jpg“ alt=““ />

Der alt-Tag ist zwar da, aber leer. Wenn man das korrigieren möchte ist Handarbeit angesagt. Rechter Mausklick auf das Bild, Bild anwählen und hier was eintragen:

bild_kontextmenu

Hier kann man auch eine Anzeigegrösse für das Bild einstellen, aber das nur am Rande bemerkt. Wenn man sich jetzt den img-Tag anschaut sieht man Folgendes:

<img title=“Titel der Johannisbeeren“ src=“images/Johannisbeeren.jpg“ alt=“Beschreibung der Johannisbeeren“ width=“829″ height=“1091″ />

Ah so, die Bildbeschreibung mutiert zum Alt-Text, ja guck mal einer an! Und glauben sie aber nicht, dass man die img-Attribute jetzt auch im Mediamanager sehen könnte, da sind sie nämlich nicht drin. Man kann zwar beim Einfügen eines Bildes aus der Mediathek ebenfalls Bildattribute angeben:

mediam

mediam

Aber da kommt – Überraschung! – noch was anderes dabei raus:

<figure><img title=“Mediam Titel“ src=“images/Johannisbeeren.jpg“ alt=“Mediam Beschreibung“ />
<figcaption>Mediam Beschriftung</figcaption></figure>

Ach! Wobei die figcaption dann tatsächlich unter dem eingefügten Bild angezeigt wird:

mediam_beschriftung

Alles klar soweit? Glauben sie aber nicht, dass sie das alles auch im Kontextmenü des Bildes wiederfinden, da sieht natürlich aus wie gehabt, die Beschriftung taucht hier nicht auf:

mediam_kontextmenu

mediam_kontextmenu

Ich glaube, ich habe jetzt für einen Beitrag genug Verwirrung gestiftet, wir lassen das jetzt alles mal ein wenig einwirken. Zusammenfassend sei gesagt, dass das Ratespiel um vernünftige Alt-Texte und Bildattribute in Joomla noch schlechter zu durchblicken ist als in WordPress, und das will schon was heissen!

 

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.

 

Darf ich mal kurz vorstellen: JDatabase

Genau wie WordPress bringt auch Joomla ein eigene Logik für Operationen auf der Datenbank mit, nachlesen kann man das en Detail in der Joomla Dokumentation zum Thema JDatabase. Wir wollen uns für den Anfang mal vornehmen, bestimmte Daten aus einer Joomla-Tabelle in einem Artikel auszugeben. Zum Thema Select schauen sie mal hier in die JDatabase-Dokumentation.

Die Ausgangstabelle: contents

Wir holen uns mal zum Üben ein paar Datensätze aus der (prefix)_contents. Um das Tabellenpräfix nicht fest verdrahten zu müssen, benutzt man die eingebaute Variable #, der Select sieht dann so aus:

SELECT * FROM #__content

Das Datenzugriffsobjekt

Die folgende Syntax erzeugt ein neues Datenzugriffsobjekt in der Variablen $db:

$db = JFactory::getDBO();

Jetzt bauen wir uns eine Variable für den Select:
$query = „SELECT * FROM #__content;“;

Und weisen diese dem Datenzugriffsobjekt als Query zu
$db->setQuery($query);

Ausgeführt wird dieses Statement dann mit der Zuweisung
$result = $db->execute();

Erste Information: wieviele Datensätze wurden selektiert?

Das kommt einem doch sehr bekannt vor:

$anzahl_zeilen = $db->getNumRows();
echo $anzahl_zeilen.“ Zeilen selektiert<br>“;

Zeilenweise Ausgabe bestimmter Spalten des Select-Ergebnisses

Wir wollen ja nicht die ganze Tabelle #__contents ausgeben, sondern nur ausgewählte Spalten, ich nehme mal fürs Beispiel die ID, den Title und den Alias. Dafür holen wir uns die ausgewählten Datensätze als Liste von Objekten, durch die wir nachher einfach iterieren können:

$results = $db->loadObjectList();

In der Object List stecken die einzelnen Datensätze des Select-Ergebnisses, und deren Spalten kann man mit dem Namen ansprechen. Wir packen das Ganze wie schon oft gehabt in eine Foreach-Anweisung, das sieht dann so aus:

foreach ($results as $zeile) :
echo $zeile->id;
echo $zeile->title;
echo $zeile->alias;
echo „<br>“;
endforeach;

Ihre Ausgabe sollte jetzt so etwas in der Art gleichsehen:

liste_content

liste_content

Zugegeben, an der Formatierung ist noch einiges optimierbar, aber wir haben das Ergebnis unseres Select jetzt als Liste in den Artikel eingefügt. Doch schon mal nicht schlecht für den Anfang, darauf kann man aufbauen.

Weitere Datenbankoperationen

Zu den weiteren Operationen wie Insert, Update und Delete gibt es hier tieferschürfende Informationen:

Inserting, Updating and Removing data using JDatabase

Konnektieren zu einer externen Datenbank

Auch das ist genau wie in WordPress  möglich, nähere Informationen findet man hier:

Connecting to an external database

Damit lasse ich es mal gut sein mit den Datenbankoperationen. Jetzt wirds Zeit, mal ein bisschen die Stammdaten von Joomla zu durchforsten, und dazu gibt es einen neuen Beitrag.

 

 

Wie man Joomla eigenen PHP-Code unterjubelt: der Sourcerer

Wenn man in den Support-Foren die Frage recherchiert, wie man denn eigenen PHP-Code in Joomla unterbringt, wird man meistens mit dem Hinweis erschlagen, dass man dafür ein eigenes Modul oder Plugin schreiben sollte. Beides ist in Joomla (im Vergleich zur WordPress-Pluginprogrammierung) recht aufwändig und für meinen Geschmack zu umständlich, wenn es nur um ein paar kleine Code Snippets geht. Wer sich selber an einem Modul versuchen möchte findet hier bei OSTraining oder hier bei joomla.org recht ausführliche Tutorials zum Thema Modulerstellung.

„Kleine“ Lösung mit dem Sourcerer

Wenn ich bloß ein paar PHP-Zeilen z.B. zum Zugriff auf eine eigene Tabelle unterkriegen will, ist mir das mit den Modulen aber wie gesagt wesentlich zu umständlich. Ich suchte nach sowas wie php Code for Posts oder einer Shortcode-Funktionalität, und bin schließlich bei der Erweiterung Sourcerer fündig geworden.  Nach der Installation findet man im Beitragseditor eine neue Funktionalität „Quelltext“, die sich sehr unauffällig gibt:

quelltext

quelltext

Nach Klick auf „Quelltext“ landet man erstmal in einem Editor, der mit den Default-Einstellungen eine kleine Hilfestellung gibt, wo man den Code platzieren kann:

sourcerer_edit

sourcerer_edit

Das wars auch schon! Nach Klick auf „Füge ein“ wird der Text inklusive der {source}-Tags in den Beitrag eingefügt und kann dort auch weiter bearbeitet werden. Leider habe ich keine Option für Code Highlighting gefunden, auch wenn in der Doku steht: „Also it comes with syntax coloring (php, js, css, html)“. Macht jetzt aber erstmal nichts, ich kopiere mir meine paar Zeilen Code aus dem Notepad++ rein. Das sieht im einfachsten Fall so aus, beispielsweise mit einem simplen echo:

php_programmerl

php_programmerl

Der Output sollte ungefähr so aussehen:

screenshot_phpcode

screenshot_phpcode

Und was machen wir jetzt damit?

Wir haben ein bisschen Spaß auf der Datenbank! Es wird höchste Zeit, sich ein wenig mit JDatabase anzufreunden, aber dafür gibt es einen neuen Beitrag.

Jetzt fehlt nur noch : der Inhalt!

Im Original Inselfisch-Kochbuch gibt es über 300 Rezepte, und die will ich eigentlich wirklich nicht händisch nach Joomla  reinkopieren. Also habe ich mich mal auf die Suche nach Import-Tools gemacht, und das Ergebnis war leider äusserst mager. Genauer gesagt, da war aber auch schon gar nix brauchbares dabei, zumindest nicht im Public-Domain-Bereich.

Das einzige Tool, das anscheinend Artikel und Kategorien direkt aus der WordPress-Datenbank importieren kann ist JConverter, und der kostet 25 $, das hab ich jetzt erstmal nicht eingesehen.  Dann gibt es noch J2XML, aber da war die Dokumentation nicht besonders aussagekräftig. Es scheint aber so zu sein, dass J2XML für den Datenimport/Export zwischen verschiedenen Joomla-Sites gedacht ist, das ist jetzt auch nicht das was ich brauche.

Was heisst hier „Bulk create“?

OSContent macht Werbung damit, wieviel Zeit und Aufwand man mit ihrem Tool bei der Erstellung neuer Joomla-Inhalte sparen kann. Ich habe mir die Free-Version installiert, und das präsentiert sich dann so:

mass_content

mass_content

OSContent präsentiert sich als recht spartanisches Formular, in das man Artikeldaten per Copy&Paste einfügen kann, für bis zu 10 neue Artikel auf einmal. Man kann hier den Titel, Alias, Intro-Text und Fulltext eintragen. Für alle 10 Artikel kann man dann noch eine Kategorie, einen Menu Link und ein Access Level angeben, sowie das Erstellungsdatum setzen. Für die Schlagwörter habe ich leider keine Option gefunden. Na ja, so im Prinzip würde das schon reichen um ein paar Rezepte aus WordPress zu übernehmen…

Aber ich werd doch nicht allen Ernstes über 300 mal die Rezeptdaten händisch hier reinkopieren! Im richtigen Leben ist das der Job für den Praktikanten, wenn  man es gar nicht anders hinkriegt. Aber professionell ist das nicht, und auch nicht so wirklich praxistauglich. Das müsste doch auch anders gehen, vielleicht mit einem CSV-Import…

Gibts nicht sowas wie wp_insert-post()?

Erinnern sie sich an den kleinen CSV-Importer für den Turnverein Weiss-Blau? Der basierte auf der sehr komfortablen WordPress-Funktion wp_insert_post(), die man mit ein paar ausgesuchten Parametern füttern kann und die auch in einer sehr minimalistischen Version schon brauchbare Ergebnisse liefert.

So etwas habe ich bei Joomla bisher vergeblich gesucht. Am ehesten in der Richtung geht noch dieser Artikel bei Stack Exchange: Create categories, subcategories and articles using php

Aber da gehts schon heftig ans Eingemachte, die Erzeugung eines neuen Artikels ist bei Joomla offenbar ein absolut nicht-trivialer Prozess, das hab ich mir jetzt erstmal nicht angetan. Damit bleibt die Frage, wie ich denn meine WordPress-Beiträge ins Joomla reinkriege, erstmal offen. Ich recherchiere weiter!

Noch ein nettes kleines Modul: Zufallsbild

Da hatte ich doch glatt den Menüpunkt „Rezeptbilder als Geschenke“ unterschlagen, und weils Spaß macht, legen wir den mit dem Modul für Zufallsbilder an. Voraussetzung ist natürlich, dass man ein paar Bilder zu den vorhandenen Artikeln hochgeladen hat, die stecken dann im Verzeichnis „images“. Man kann sich aber auch ein extra Bilderverzeichnis anlegen, dann den Pfad entsprechend anpassen

Erweiterungen->Module->Neu „Zufallsbild“, bei Bilderverzeichnis images oder das eigene Verzeichnis angeben. Dem Modul einen Namen geben, speichern.

Dann einen Beitrag für das Zufallsbild aussuchen oder neu anlegen, ggf. einem eigenen Menüpunkt zuordnen. Im Beitragseditor die Option „Module“ wählen und das eben erstellte Modul einfügen – fertig!

zufallsbild

zufallsbild

Das Modul könnte man ausser in einem Beitrag natürlich auch an einer Modulposition im Layout anzeigen lassen, aber da kann jeder selber rumprobieren.

Mehr zur Bilderverwaltung in Joomla gibts später in einem eigenen Artikel.

 

Menü mit Untermenüs

Ich habe ja im Original-Inselfischkochbuch ein Untermenü bei den Kochbüchern eingerichtet, da will ich die Umsetzung nach Joomla nicht unterschlagen, damit man das Prinzip mal sieht. Auch hier gilt: viele Wege führen nach Rom, ich hab mal einen relativ simplen genommen. Ich gehe davon aus, dass schon Artikel mit einzelnen Kochbüchern vorhanden sind, falls nicht, kann man sie auch beim Erstellen der Menüstruktur anlegen.

Hauptmenüeintrag erstellen und konfigurieren

Menüs->Main Menü (oder wie es bei ihnen heißt)->Neuer Eintrag, Titel „Meine Lieblingskochbücher“, Menüeintragstyp „Systemlinks“->URL. Jetzt im Feld Link den Hashtag „‚#“ eingeben, speichern und schliessen.

Untermenüeintrag erstellen und zuordnen

Neuer Menüeintrag, Titel z.B. „Das bairische Kochbuch“, Menüeintragstyp Beiträge->Einzelner Beitrag, hier den passenden Beitrag auswählen oder neu erstellen. Rechts bei Übergeordneter Beitrag unseren Hauptmenüeintrag „Meine Lieblingskochbücher“ wählen, speichern.

Wenn man sich jetzt die neuen Menüeinträge im Main Menü anschaut, sollte es ungefähr so aussehen:

untermenu

untermenu

Und das Ergebnis im Frontend sollte etwa so aussehen:

untermenu_screenshot

untermenu_screenshot

Weitere Untermenüeinträge werden nach genau dem selben Muster hinzugefügt, mehr ist nicht dabei. Natürlich kann man den Untermenüeinträgen beliebige Inhalte zuordnen und hier zum Beispiel weitere Kategorieblogs oder dergleichen einrichten, aber das kann jeder selber ausprobieren.

Nach dem selben Muster kann man auch mehrstufige Untermenüs einrichten, also so etwas in der Art:

zweistufiges_untermenu

zweistufiges_untermenu

Mehrstufige Menüs brauche ich aber in der Praxis nicht oft, das wird bei zu tiefer Verschachtelung so unübersichtlich, dass man sich da eine andere Lösung überlegen sollte.