Archiv der Kategorie: Allgemein

Erstellen wir jetzt endlich mal ein eigenes Theme?

Nein.

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

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

Ich editiere Page Templates nur im äußersten Notfall

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

Aber was ist, wenn man ein Child Theme verwendet?

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

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

Ausnahmen bestätigen die Regel

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

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

Änderungen in der style.css nur mikrochirurgisch

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

Theme-unabhängig programmieren, das geht!

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

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

WordPress möchte doch so gern ein CMS sein

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

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

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Unser erstes Plugin: SetzeCode 2, die Funktionalität

Was wollten wir also tun? Den Wert einer Option per Plugin setzen. Dafür brauchen wir zuerstmal:

Ein kleines Formular für die Eingabe

//Begin Formular
echo ‚<form method=“post“>‘;
echo ‚Mein Code: <input type=“text“ name=“code“ /></br>‘;
echo ‚<input type=“submit“ name = „senden“ value=“Abschicken“/>‘.“<br>“;
echo „</form>“;
// End Formular

Keine Hexerei, nur ein ganz normales PHP-Formulärchen mit einem Texteingabefeld und einem submit-Button.

Was soll passieren, wenn auf „Abschicken“ gedrückt wurde?

Auch nicht weiter schwer, die Option soll mit dem Inhalt der Benutzereingabe gesetzt werden.

if (isset($_POST[’senden‘]))
{
    $akt_code = $_POST[‚code‘];
    update_option (‚mein_code‘, $akt_code);   
}

Und schon landet der vom Benutzer eingegebene Code als Options-Wertepaar (Name und Wert) in der Tabelle wp_options!

Man kann noch eine kleine Debug-Ausgabe mit dranhängen, dann sieht man auch gleich mal wie das mit dem get_option() funktioniert:

$akt_option = get_option (‚mein_code‘);
        echo „Wert aus der Datenbank &nbsp:“.$akt_option;

Alles klar? Bitteschön, unser erstes Plugin kann marschieren! Nochmal zur Kontrolle die gesamte Funktion:

function pluginAdminScreen() {
    echo „<h1>Setze Meinen Code</h1>“;
            
//Begin Formular
echo ‚<form method=“post“>‘;
echo ‚Mein Code: <input type=“text“ name=“code“ /></br>‘;
echo ‚<input type=“submit“ name = „senden“ value=“Abschicken“/>‘.“<br>“;
echo „</form>“;
// End Formular

if (isset($_POST[’senden‘]))
{

    $akt_code = $_POST[‚code‘];
    update_option (‚mein_code‘, $akt_code);
    
}
$akt_option = get_option (‚mein_code‘);
        echo „Wert aus der Datenbank &nbsp:“.$akt_option;      
}

Hochladen und Aktivieren unseres Plugins

Man verschiebt jetzt die fertige setze_code.php in unser vorher angelegtes Plugin-Unterverzeichnis. Wenn alles geklappt hat, taucht unser neues Plugin jetzt im Plugins-Menü auf und kann dort aktiviert werden. Dann erscheint am Ende des Admin-Menüs der neue Eintrag „SetzeCode“, und den rufen wir jetzt auf und probierens mal aus. Aussehen sollte das Ganze etwa so:

screenshot_setze_code

screenshot_setze_code

Der Wert aus der Datenbank wird beim ersten Aufruf leer sein, weil die Option noch nicht gesetzt wurde, aber nach dem ersten Abschicken sollte er treu und brav den zuletzt eingegebenen Code wiedergeben. Das wars!

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Options: benutzerdefinierte globale Variable

Wozu globale Variable?

Manchmal braucht man Werte, die global in WordPress zur Verfügung stehen sollen. Man kann natürlich Shortcodes definieren, die nur einen bestimmten Wert zurückgeben (return „ABCD“;), aber mit dem Shortcode ist man logischerweise abhängig vom Theme, wenn man das Theme wechselt ist auch der Shortcode und der Wert futsch. WordPress bietet da alternativ eine hübsch simple Möglichkeit, eigene Werte in der Datenbank abzulegen und auch wieder herauszuholen.

Die WordPress Options

Kurzer Blick in den Codex: add_option() legt ein Wertepaar (Option Name und Wert) in der WordPress-Tabelle wp_options ab. Mit get_option(‚optionsname‘) holt man sich den Wert bei Bedarf wieder heraus. Ich zitiere nochmal kurz den Codex:

If you are trying to ensure that a given option is created, use update_option() instead, which bypasses the option name check and updates the option with the desired value whether or not it exists.

Wir nehmen also lieber die Funktion update_option(), die uns auf jeden Fall den Datenbankeintrag anlegt, falls er noch nicht existiert. Das sieht dann etwa so aus:

update_option (‚mein_code‘, ‚Evis neuer Code‘);

Das ‚mein_code‚ ist der Name der Option, diese wird durch das update_option() neu angelegt, falls sie noch nicht existiert. Der zweite Parameter setzt den Wert (value) der neuen Option, hier habe ich einfach einen String eingesetzt. Das Feld option_value ist übrigens ein longtext, da können sie bis zu 2^32 Bytes speichern, also nur keine Hemmungen!

Wie sieht das in der Datenbank aus?

Braucht uns eigentlich nicht zu kümmern, da wir ja den Wert der Option nachher mit get_option() herausholen, aber ich zeigs mal der Vollständigkeit halber:

options

options

Die neue Option kriegt eine AutoIncrement-ID, in option_name landet der angegebene Name, in option_value der gewünschte Wert der Option, und das autoload wird defaultmäßig auf yes gesetzt und braucht uns nicht weiter zu kümmern.

Wie man den Wert der Option wieder herauskriegt

Ganz simpel. Mit get_option($option_name). Der Code für die Ausgabe sieht zum Beispiel so aus:

$akt_option = get_option (‚mein_code‘);
echo „Wert von akt_option :&nbsp“.$akt_option;

Das erzeugt die Ausgabe:

Wert von akt_option :  Evis neuer Code

Eigentlich selbsterklärend.

Und wohin jetzt mit den update- und get- Anweisungen? Dafür (täterätää!) schreiben wir unser erstes Plugin, und dazu gibts natürlich einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Noch’n Nachschlag: Formular mit Gedächtnis (reines PHP)

Formular soll sich Eingaben merken

Kennen sie das auch: man hat ein Online-Formular ausgefüllt und auf den „Abschicken“-Button geklickt, und alle Benutzereingaben verschwinden, man hat wieder ein leeres Formular vor sich. Passiert heutzutage gottseidank nicht mehr so oft, aber wenn dann ist es oft verdammt ärgerlich, wenn man nicht das gewünschte Ergebnis erzielt hat und das Formular nochmal von vorn ausfüllen muß. Unser Freizeitsportpartner-Suchformular vom Turnverein Weiß-Blau leidet noch unter dieser Kinderkrankheit, und die wollen wir ihm abgewöhnen. Kurz zur Erinnerung, das Formular sieht so aus:

suchformular

suchformular

Selektive Vorbelegung

Jetzt möchte ich gerne, daß nach dem Klick auf „Abschicken“ die vom Benutzer gesetzten Häkchen in den Checkboxen erhalten bleiben. Bislang sah der Code für eine Checkbox so aus:

echo „<input type=’checkbox‘ name=’turnen‘ value=’ja‘>Turnen<br>“;

Den brechen wir jetzt ein bißchen auf, und wir fragen ab ob denn der Wert für die Checkbox nicht schon mal gesetzt wurde, das sieht dann so aus:

echo „<input type=’checkbox‘ name=’turnen‘ value=’ja'“;
            if ($_POST[‚turnen‘] == ‚ja‘){
            echo „checked=’checked'“;
            }
        echo „>Turnen<br>“;

Das $_POST[‚turnen‘] enthält den aktuellen Wert des Feldes, der ist leer, wenn die Checkbox vor dem Drücken des Abschicken-Buttons leer war, und er enthält ein „ja“, wenn die Checkbox angekreuzt war. Das checken wir mit dem IF ab, und mit dem „checked=’checked'“ setzen wir im ja-Fall das Häckchen.

That’s it! Das machen wir für alle anderen Checkboxen analog, und schon haben wir ein Formular mit Gedächtnis.

Dropdownfeld mit Gedächtnis

Für die, die’s ganz perfekt haben wollen, hier noch die Vorbelegung für das Dropdown-Feld:

/*Begin select*/
echo „Auswahl Fitneß: &nbsp“;
echo „<select name=’meine_auswahl‘>“;

echo „<option“;
if ($_POST[‚meine_auswahl‘] == ‚egal‘){
    echo “ selected“;
}
echo „>egal</option>“;

echo „<option“;
if ($_POST[‚meine_auswahl‘] == ‚Anfänger‘){
    echo “ selected“;
}
echo „>Anfänger</option>“;

echo „<option“;
if ($_POST[‚meine_auswahl‘] == ‚Freizeitsportler‘){
    echo “ selected“;
}
echo „>Freizeitsportler</option>“;

echo „<option“;
if ($_POST[‚meine_auswahl‘] == ‚Profi‘){
    echo “ selected“;
}
echo „>Profi</option></select><br>“;
/*End Select*/

Das können sie sich jetzt aber selber zusammenreimen, der Mechanismus ist genau so wie bei der Checkbox, nur halt für jede Option extra. Zugegeben, es ist ein bißchen Aufwand, aber in Sachen Benutzerfreundlichkeit der Mühe wert.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Nachschlag: Kategorien schöner ausgeben leicht gemacht

Kategorienliste

Erinnern sie sich, bei der Rezeptausgabe hatte ich das Problem, daß ich hinter jeder Kategorie in der Liste ein Komma hatte, auch hinter der letzten, und das war nicht so schön.

alleposts_mit_kategorien

alleposts_mit_kategorien

Jetzt bin ich gerdae über eine WordPress-Funktion gestolpert, die das wesentlich hübscher macht, und einen gleich mit den Links zu den Kategorien mit versorgt. Kurzer Blick in den Codex: get_the_category_list

Die Funktion gibt die Kategorienliste zu einer beliebigen Beitrags-ID aus, das sieht z.B. so aus:

$ausgabe =  get_the_category_list( ‚,‘,“,1270);
echo „Kategorien: &nbsp“.$ausgabe;

Ergebnis (mit funktionalen Links):

Kategorien:  Echt Bairisch,Plauderei,Single-Küche

Man kann als Seperator übrigens beliebige Strings setzen, ich nehm mal ein “ + „:

Kategorien:  Echt Bairisch + Plauderei + Single-Küche

Das sieht doch gleich viel besser aus!

Schlagwortliste

Eine ähnliche Funktion gibt es auch für die Schlagworte, die nennt sich get_the_tag_list, hier lohnt ebenfalls ein Blick in den Codex:

https://codex.wordpress.org/Function_Reference/get_the_tag_list

Diese kleinen Nützlinge kann man immer wieder mal brauchen.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Mitgliederverzeichnis mit Adressdaten

Wir basteln uns ein Mitgliederverzeichnis

Damit wir von unserer tabellarischen Ausgabe zu einem vernünftigen Mitgliederverzeichnis komplett mit Fotos kommen, ist ein wenig Handarbeit angesagt, wie immer, wenn man es in WordPress mit einzelnen Beiträgen zu tun hat. Aber keine Bange, wir machen nur das absolute Minimum. Jetzt knüpfen wir uns die neuen Mitglieder der Reihe nach vor und legen uns zu jedem Mitglieds-Datensatz einen eigenen Beitrag an.

Dazu folgende Vorüberlegungen:

  1. Wenn wir den Beitrag einfach mit Vorname und Name des Mitglieds betiteln, kann es zu Konflikten kommen, schließlich können wir mehr als einen „Peter Müller“ oder „Stefan Huber“ in unserer Mitgliederliste haben. Also stellen wir dem Namen einfach die automatisch vergebene id aus der Tabelle mitglieder_stamm voran, dann haben wir Eindeutigkeit. Und weil unsere Mitglieder untereinander per Du sind, verzichten wir auf den Nachnamen und sparen uns Tipparbeit. Unser erster Beitrag erhält also den Titel „1 Ferdinand“, der zweite wird „2 Marius“ heißen, der dritte „3 Ivonne“ usw., einfach der Reihe nach durch.
  2. Das Paßfoto laden wir als Beitragsbild hoch (rechts unten im Beitragseditor bei „Beitragsbild festlegen“), dann haben wir für spätere Ausgaben Zugriff über darauf. Auch das haben wir schon mal gemacht, mit wp_get_attachment_url(get_post_thumbnail_id(post_ID))
  3. Wir legen 1 benutzerdefiniertes Feld an, das heißt „mitglied_id“ und erhält als Inhalt (na was wohl?) unsere eindeutige id.
mitglied_id

mitglied_id

4. Wenn wir den Beitrag für ein neues Mitglied vollständig angelegt haben, könnten wir das Feld „status“ in der Tabelle mitglieder_stamm von „neuzugang“ auf „aktiv“ stellen – jaja ich hörs schon, das sollte man programmgesteuert mit einem Update machen, aber wir operieren hier gerade mal auf einer Handvoll Testdaten, da reicht der manuelle Eintrag. Soll ja auch nur beispielhaft zeigen, daß der Bearbeitungsstand eines Mitgliederdatensatzes durch den Status mitprotokolliert werden kann.

Das wars schon! Den Rest holen wir uns aus der Datenbank, aber ich hol mir mal einen frischen Kaffee während sie die Beiträge anlegen 🙂

Vorüberlegung: was wollen wir im Mitgliederverzeichnis alles ausgeben?

Na, alles! Die kompletten Adressdaten, die sportlichen Präferenzen, das Paßfoto, den ganzen Summs möchten wir im Mitgliederverzeichnis sehen, ohne auch nur ein einziges weiteres Datenfeld manuell eingeben zu müssen. Uns reicht das benutzerdefinierte Feld mitglied_id, darüber verknüpfen wir uns die ganze Tabelle mitglieder_stamm und basteln uns die gewünschte Ausgabe.

Wie sieht es jetzt aus?

Das ist leider sehr abhängig vom Theme und läßt sich nicht so global sagen. Aber wenn sie jetzt auf ihre Beitragsseite gehen, müßten eigentlich die Beitragsbilder(Paßfotos) und die eingegebenen Beitragstitel (1 Ferdinand, 2 Marius…) aufgelistet werden. Manche Themes geben allerdings die Thumbnails (Beitragsbilder) in der Übersicht gar nicht mit aus. Wenn wir jetzt auf einen Beitragstitel klicken, sehen wir – nichts. Völlig korrekt, wir haben ja auch keinerlei Beitragstext eingegeben. Und unser benutzerdefiniertes Feld mitglied_id sehen wir auch nicht, weil es noch nicht in das Template mit eingebunden ist. Also, an die Arbeit. Wenn sie genau nachvollziehen wollen, an welcher Stelle welche Anpassungen wie greifen, wäre es sinnvoll, wenn sie das selbe Theme wie ich verwenden, es ist ein Child-Theme von Twentyfourteen.

Unsere Anpassungen an der single.php

Für die Darstellung der einzelnen Beiträge wird die single.php verwendet, und die nehmen wir uns jetzt vor. Machen sie eine Kopie der Originaldatei, legen sie sie in ihrem Child-Theme-Ordner ab und öffnen sie sie in einem Editor. Unsere Anpassungen erfolgen innerhalb des Loops, unmittelbar vor der Previous/next post navigation, hier im Screenshot wirds deutlich:

innerhalb_des_loops

innerhalb_des_loops

Geben sie hier mal zum Testen nur die einzige Echo-Zeile ein und schauen sie sich einen Beitrag an, da darf nichts stehen ausser dem Text des echo.

Wie kriegen wir jetzt unsere Stammdaten hier rein?

Über eine Verknüpfung mit der Tabelle mitglieder_stamm über das benutzerdefinierte  Feld mitglied_id. Wir geben als allererstes mal nur die mitglied_id aus, das machen wir so:

echo "<h2>Mitgliederdaten</h2>";
                    $akt_mitglied_id = get_post_meta($post->ID, 'mitglied_id', true);
                    echo "Aktuelle Mitglied ID:&nbsp".$akt_mitglied_id."<br>";

Der Witz steckt natürlich in der Funktion get_post_meta, die holt uns zur aktuellen WordPress-ID des Beitrags den Wert des benutzerdefinierten Feldes mit dem Namen „mitglied_id“. Das „true“ bewirkt, daß ein einzelner String ausgegeben wird, mehr brauchen wir nicht.

Jetzt müssen wir noch angeben, aus welcher Tabelle wir die Daten holen wollen, dazu lege ich den Tabellennamen wieder auf eine Konstante, damit man ihn später leicht auswechseln kann, und gönne mir noch eine Debug-Ausgabe.

/*****Haupttabelle Name als Konstante definieren*******/
                    define("MAINTABLE","mitglieder_stamm");                    
                    echo "Aktuelle Tabelle =&nbsp".MAINTABLE."<br>";

Und jetzt haben wir schon alles, was wir für unseren Select brauchen! Der sieht so aus:

$alleposts = $wpdb->get_results( "SELECT * from ".MAINTABLE."
 WHERE id = '".$akt_mitglied_id."'");

Und schon haben wir den richtigen Datensatz anhand der Mitglieds-id herausgefischt! Die Ausgabe der einzelnen Felder erfolgt dann wie gehabt wieder mit einer Foreach-Schleife, ich gebe hier mal beispielhaft nur ein paar Felder aus:

foreach ( $alleposts as $einpost ) {             
                            
                            echo $einpost->vorname."<br>";
                            echo $einpost->nachname."<br>";
                            echo $einpost->ort."<br>";
                            echo $einpost->strassehausnummer."<br>";
                    }

Das Ergebnis

…ist noch nicht besonders hübsch formatiert, aber es zeigt das Prinzip:

maja_daten

maja_daten

Am schönsten sähe es natürlich aus, wenn man die Stammdaten tabellarisch ausgibt, aber das kann sich jeder selber einrichten wie er es möchte. Jedenfalls haben wir übere unsere Verknüpfung mit der mitglied_id Zugriff auf alle Datenfelder der Tabelle mitglieder_stamm, und das war ja genau das, um was es ging. So simpel ist die Lösung mit einer eigenen Tabelle für die Mitgliederdaten!

Klarer Vorteil gegenüber den benutzerdefinierten Feldern

Ausser der mitglied_id muß im Beitrag nichts per Hand eingegeben werden, das erspart einem einen Haufen (fehlerträchtiger) Handarbeit. Stellen sie sich nur mal vor, sie müßten jetzt zu allen Mitgliedern die vollständigen Adressdaten händisch in Custom Fields erfassen – also nee, echt nicht. Das haben wir eleganter gelöst. Und wenn es mal Änderungen an den Benutzerdaten geben sollte, auch die können wir in unser eigenen Tabelle mitglieder_stamm einpflegen, wir müssen dazu nicht den entsprechenden Beitrag bearbeiten. Auch das ist ein weiterer Vorteil, der nicht zu unterschätzen ist. Man kann sich auch mit PHP einen kleinen Mitgliederdaten-Editor basteln, vielleicht mach ich das später mal, das führt jetzt wirklich zu weit. Und jetzt viel Vergnügen beim individuellen Einbinden und Formatieren ihrer Felder!

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Turnverein: die Mitglieder-Stammdaten

Woher kommen die Daten?

Wie im vorigen Artikel bereits angesprochen, gibt es ein in Contact Form 7 erstelltes Anmeldeformular, das wird für die Erfassung aller Mitgliederdaten genutzt. Hacken sie einfach ein paar Testmitglieder mit unterschiedlichen Sportarten und Freizeitoptionen ein, so fünf bis zehn Stück reichen für den Anfang. Contact Form 7 schickt ihnen zu jedem erfaßten Formular ein E-Mail mit den zugehörigen Daten. Wir brauchen hier aber nur das Paßfoto, das als Attachment mitgeschickt wird, die anderen Daten werden in einer MySQL-Tabelle automatisch gespeichert.

Speichern der Formulardaten in einer Tabelle

Das zusätzliche Plugin Save Contact Form 7 sorgt dafür, daß die Formulardaten in einer Tabelle landen, mit der wir später weiterarbeiten können. Diese Tabelle heißt default-mässig savecontactform7_X, wobei X eine laufende Nummer ist. Da wir nur ein Kontaktformular haben, ist das die Nummer 1, folglich heißt unsere Tabelle savecontactform7_1. Von der machen wir uns zunächst einmal eine Kopie: das geht im phpmyadmin unter „Operationen“, wir kopieren Struktur und Daten und geben der Tabelle einen aussagekräftigen Namen, die heißt jetzt mitglieder_stamm. Das wird unsere Arbeitstabelle. Warum eine Kopie? Weil wir noch am Testen sind. Im Real-Betrieb arbeitet man mit der „echten“ Tabelle, damit man neu angemeldete Mitglieder auch in Echtzeit mitkriegt. Wir nutzen jetzt erstmal die Kopie unserer Mitglieder-Stammdaten und haben ein bißchen Spaß auf der Datenbank!

Struktur der Tabelle mitglieder_stamm

In der Tabellenstruktur spiegelt sich 1:1 unser Formular wieder:

mitglieder_stamm_struktur

mitglieder_stamm_struktur

Ich geh mal von oben nach unten:

  1. id wird von contact form 7 automatisch fortlaufend vergeben, das wird unser Schlüssel, die Mitglieds-Nummer
  2. created_on Timestamp, wird von CF7 automatisch vergeben, brauchen wir eigentlich nicht
  3. status das hab ich glatt unterschlagen: ich nutze das Plugin CF7 Dynamic Text Extension um ein „hidden“-Feld mitzugeben, das erhält defaultmäßig den Wert „neuzugang“. Wir werden später noch sehen, wozu wir das brauchen.
  4. die restlichen Felder: sind 1:1 die selben wie in unserem Formular, das ist keine Hexerei.
  5. Das Feld zustimmung brauchen wir nur für die Datenschutzerklärung, das sieht in CF7 so aus:
datenschutzerklaerung

datenschutzerklaerung

Die muß mit rein, schließlich erheben wir personenbezogene Daten!

So, das wars schon. Ready to go, Testdaten drin? Dann gehts zur ersten Ausgabe im nächsten Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Eigene Tabellen – schließlich heißt es „MeinSQL“

MySQL läßt sich so schön übersetzen

Mir gefällt auch die Semantik: das ist „Mein SQL“, hier kann ich schalten und walten wie ich will, kann Tabellen und Abfragen anlegen und verknüpfen, kann sortieren und inserten und updaten nach Lust und Laune, und Open Source und kostenlos ist es obendrein. MySQL bietet wirklich unbegrenzte Möglichkeiten und ist flexibel ohne Ende. Über den genialen phpMyAdmin steht auch eine professionelle Verwaltungsoberfläche zur Verfügung, die keine Wünsche offenläßt. Also, warum nutzen wir dann dieses Potential nicht zur Erweiterung von WordPress?

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Beitragsausgabe: Wie werd ich bloß den Text „Einleitung“ los?

Also, das ist jetzt quasi mein Privatvergnügen, ich möchte aus der Beitragsausgabe die wiederholte Zwischenüberschrift „Einleitung“ heraus haben. Nochmal zur Erinnerung wie das aussieht:

alle_posts_mit_links

alle_posts_mit_links

Sie sehen hier, daß nicht alle Posts mit „Einleitung“ anfangen, ich darf also nicht alle „behandeln“.

Wie ist hier die Logik?

Also, mal sehen ob ich das irgendwie logisch gebacken kriege. Vor fast jedem Rezept steht der Text „Einleitung“, als h2-Überschrift formatiert. Das Dumme daran ist, daß es bei einigen wenigen Rezepten keine Einleitung gibt, sonst könnte ich einfach die Anzahl der Zeichen abzählen und den post_content um soundsoviele Zeichen abschnippeln.Geht nicht, ich muß eine Fallunterscheidung machen.

Ich muß auch genaugenommen nicht nur den Text „Einleitung“ loswerden, sondern auch die <h2>-Tags. Das macht abgezählt die ersten 19 Zeichen, die abzuschneiden sind. Mal sehen, ob ich das in PHP gebacken kriege.

Kurzer Blick ins PHP-Manual

Mit einem strcmp müßte es eigentlich gehen.

$akt_text = $einpost->post_content;
                $such_text = "<h2>Einleitung</h2>%";
                $vergleich = strcmp ($such_text, $akt_text);

strcmp Gibt 1 zurück, wenn die Strings gleich sind, und kleiner Null (-1) wenn nicht gleich. Na bitte, geht doch! Jetzt noch eine IF-Abfrage, und mit substr() die ersten 19 Zeichen abschneiden, dann hab ichs.

if ($vergleich == 1){
                            
                            $akt_text = substr($akt_text, 19);
                        
                    }

Jetzt gebe ich noch anstelle des post_content den abgeschnittenen $akt_text aus, und feddisch, die Zwischenüberschrift mit dem Text „Einleitung“ ist draussen!

ohne_einleitung_alle_posts_mit_links

ohne_einleitung_alle_posts_mit_links

Ich lieeebe die String-Funktionen von PHP!
Hier kommt nochmal die ganze neue Foreach-Schleife:

foreach_ohne_einleitung

foreach_ohne_einleitung

Jetzt müßte man nur noch den Beitragstext irgendwie vernünftig kürzen, aber dafür gibts einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Was wir mit Bildern können, können wir mit Posts schon lange!

Alle veröffentlichten Beiträge

Es wird wieder Zeit für ein bißchen Spaß auf der Datenbank! Wir gehen wieder zurück zu unserer zentralen Tabelle wp_posts und picken uns diesmal alle veröffentlichten Beiträge heraus. Das haben wir schonmal gemacht, bei der Ausgabe der Beitragsbilder ganz am Anfang, wissen sie noch? Der Select ist supersimpel:

SELECT * from wp_posts where post_status = ‚publish‘ and post_type = ‚post‘

Die könnten wir jetzt einfach mal alle ausgeben so wie sie daherkommen, nämlich einfach nacheinander aufsteigend Datum. Das sähe dann aber der Beitragsseite (nur mit umgekehrter Sortierung) verdammt ähnlich und hätte weiter keinen Närwert, deshalb geben wir die Beiträge jetzt erst mal gekürzt und in Divs gepackt als Übersicht aus. Unser foreach für diesen Zweck ist auch denkbar einfach, ich gebe fürs erste nur den Titel und den Inhalt aus:

foreach ( $alleposts as $einpost ) 
            { 
            echo "<div class = 'post_ausgabe'>";
                echo "<h1>".$einpost->post_title."</h1>";
                echo $einpost->post_content."</br>";
            echo "</div>";    
            }

Ich habe mir eine neue Klasse von Div, die post_ausgabe definiert, weil ich die Formatierung etwas anders als bei der Bilderausgabe gestalten möchte. Der CSS-Eintrag sieht so aus:

.post_ausgabe{
    
    float:left;
    height: 300px;
    width: 30%;
    overflow: hidden;
    border: 1px solid blue;
    margin: 2px;
    padding:2px;    
    
}

Wichtig ist der overflow: hidden; damit die Sache leserlich bleibt. Und die Ausgabe? Ich nehme mal wieder das Inselfisch-Kochbuch, da sind richtig schön viele Beiträge drin, und das sieht jetzt erstmal so aus:

post_ausgabe

post_ausgabe

Zugegeben, das könnte hübscher sein, aber darum kümmern wir uns später. Falls sie sich wundern, daß hier überrall „Einleitung“ als Untertitel steht: das ist völlig korrekt so, weil bei mir (fast) jedes Rezept mit einer Einleitung beginnt. Erinnern sie sich? Da war was mit der Textstrukturierung wegen der Barrierefreiheit. Deswegen kommt als erster Text im post_content das Wörtchen „Einleitung“, als h2-Überschrift formatiert. Die Ausgabe ist also völlig richtig.

Link auf den Beitrag

Jetzt fehlt natürlich der Link auf den Beitrag, den holen wir uns wieder mal mit get_permalink(ID) und machen einen a href auf die Überschrift daraus. Der foreach folgt sogleich:

foreach ( $alleposts as $einpost ) 
            { 
            $akt_link = get_permalink($einpost->ID);
            
            echo "<div class = 'post_ausgabe'>";
                echo "<a href = '".$akt_link."'><h1>".$einpost->post_title."</h1></a>";
                echo $einpost->post_content."</br>";
            echo "</div>";    
            
            }

Jetzt sitzen die Links auf den Überschriften, wo sie hingehören.

alle_posts_mit_links

alle_posts_mit_links

Wieder das Spiel mit dem Limit und der Zufallszahl

Man kann natürlich auch hier die Anzahl der auszugebenden Beiträge limitieren, und mit Rand() eine zufällige Auswahl der Beiträge erzeugen, und man kann den ganzen Shortcode natürlich auch wieder ins Text-Widget packen und z.B. in die Seitenleiste verschieben, da kann jeder selber damit spielen.

Was noch nicht schön ist

Der abgeschnittene Text stört mich, und der -zigfache Text Einleitung. Da letzteres aber sozusagen mein Privatvergnügen ist, gibts dafür einen neuen Beitrag.

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend