Archiv der Kategorie: HTML

Tabelleneditor revisited: und jetzt das Ganze nochmal als Shortcode

Ja, ich weiß, ich habs unterschlagen. Wir haben uns einen hübschen kleinen Tabelleneditor im Admin Panel gebastelt, mit Unterseite und allem Pipapo. Aber da kamen schon die ersten Rückfragen. Was, wenn ich meinen Besuchern die Möglichkeit anbieten möchte, Tabellendaten auf meiner Webseite zu editieren? Wie sieht das dann die Verzweigung auf die Unterseite aus? Ein Anwendungsfall wäre es zum Beispiel, wenn ich meinen Nutzern das Editieren der eigenen Adressdaten ermöglichen möchte. Da wird man zwar im Zweifelsfall ein Login vorschalten, denkbar ist z.B. daß sich der Benutzer mit seiner Mitgliedsnummer anmeldet und diese beim Aufruf des Unterformulars abgefragt wird. Das führt mir aber jetzt entschieden zu weit, ich lasse es mal bei dem Formular mit den Edit-Buttons, sonst blickt hier keiner mehr durch. Die Funktionalität wird also die selbe sein wie beim Plugin Adressen Tabelle, nur diesmal auf der Blog-Oberfläche.

Wir basteln uns einen Shortcode

Der erste Teil ist simpel. Wir schnappen uns die Funktion pluginAdressenTabelle() und schieben sie in einen Shortcode. Für den legen wir uns eine neue Seite an und fügen ihn dort ein, ich hab ihn mal [adr_tabelle] genannt. Das müsste eigentlich ohne Änderungen klappen, das Ergebnis sollte etwa so aussehen:

shortcode_adresseneditor

shortcode_adresseneditor

Wenn man jetzt auf einen „Edit“-Button klickt, landet man (logischerweise) noch im Admin Panel, und das soll natürlich nicht sein, da brauchen wir was anderes. Nämlich eine Blogseite, die nicht im Menü erscheinen soll, sondern nur durch Klick auf den Edit-Button aus der aufrufenden Seite auftauchen darf.

Seite ohne Menüeintrag? Mit Menü!

Man legt eine neue Seite an, benennt sie entsprechend, z.B. Adresseneditor Unterseite. Dann legt man unter Design/Menüs ein neues Menü an, in das man alle Seiten ausser der eben erstellten einträgt (alle markieren und dann bei der Einzelseite das Häkchen entfernen). Ist ein bißchen von hinten durch die Brust ins Auge, aber so funktionierts.

Aufzurufende Seite bei Formular-Action hinterlegen

Wir klemmen uns einfach den Permalink der soeben erstellten Unterseite und legen sie auf die Variable für den Action-Tag, das sieht dann z.B. so aus:

$meinplugin_URL = „http://localhost/turnverein/adresseneditor/adresseneditor-unterseite/“;

Das wars schon.

Wie kommt jetzt unsere Editor-Funktionalität in die Unterseite?

Per Shortcode! Mein Freund und Lieblingshelfer, ich sags immer wieder. Wir erstellen einen neuen Shortcode, mit aussagekräftigen Namen, z.B.:

add_shortcode (‚mein_adr_editor‘, ‚meinAdressenEditor‘);

Dann brauchen wir natürlich noch die Funktion zum Shortcode, die heißt jetzt meinAdressenEditor(). In diese kopieren wir uns den ganzen Inhalt der Funktion AdresseEditAusgabe() aus dem Plugin, das wir vorher erstellt haben. Nicht vergessen unten den Link zurück auf die aufrufende Seite zu aktualisieren, der sollte jetzt etwa so ausehen:

echo „<a href = ‚http://localhost/turnverein/adresseneditor/’/><h1>Zurück zur Adressenliste</h1></a>“;

Den soeben erstellten Shortcode [mein_adr_editor] in die Unterseite einfügen, speichern und feddisch, das wars! Die Bildschirmausgabe sollte etwa so aussehen:

adresseneditor_unterseite

adresseneditor_unterseite

Übrigens nicht wundern: wenn man sich die Unterseite „allein“ anschaut, also aus dem Edit-Modus mit „Seite ansehen“, sieht man – nichts. Da fehlt der Parameter mit der ID, also ergibt unser Select eine leere Ausgabe, und dann sieht mal halt nichts, punktum.

So, jetzt hab ich aber alle Aspekte des Tabelleneditors erschöpfend behandelt – hoffe ich zumindest. Wenn jetzt noch Rückfragen kommen – ich bin unbekannt verreist 😉

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Statt Dirty Trick: die saubere Lösung mit Submenu Page

Na bitte, ich wußte doch dass es da eine sauberere Lösung geben muss. Ich lasse die beiden vorigen Artikel mal so stehen (wir lernen daraus) und zeige hier einen anderen Ansatz für das Unterformular, das bislang ja so nackt und weiss als reine PHP-Datei dasteht.

Der erste Vorteil: durchgängige Benutzeroberfläche

Das ist zwar eigentlich nur eine kosmetische Korrektur, funktioniert hats auch vorher, aber schöner ist es ja schon wenn man im AdminScreen-Kontext bleibt.

Der zweite Vorteil: wir sparen uns den require(wp-load.php)

Das ist schon knackiger. Es ist ja nicht „considered best practice“, wenn man den ganzen WordPress-Funktionsapparat in einem Plugin nochmal lädt. Man kanns machen, aber es ist und bleibt eine Krücke. Das können wir uns jetzt schenken, weil unsere Submenu Page alle Funktionalitäten schon mitbringt.

Submenu – wie wirds gemacht?

Wir arbeiten ab jetzt nur noch mit einer PHP-Datei für unser Plugin, da nehmen wir genau die adressen-tabelle.php aus den vorigen Beiträgen. Die ergänzen wir um einen Eintrag, der eine „elternlose“ Submenu-Seite definiert:

add_action(‚admin_menu‘, ‚Edit‘);

 function Edit(){
add_submenu_page( ‚null‚, ‚Adresse Edit‘, ‚Adresse Edit‘, ‚administrator‘, ‚adresse-edit‘, ‚AdresseEditAusgabe‚ );
 }

Das ‚null‚ im ersten Tag (das ist der für den Parent) ist hier der Knackpunkt. Das bewirkt, dass die Seite zwar aufrufbar ist, aber nicht im Admin Screen Menü auftaucht.

Der letzte Tag AdresseEditAusgabe definiert die Funktion, die bei Aufruf unseres Submenüs ausgeführt wird. Die müssen wir natürlich noch schreiben, aber das wird easy. Da kopieren wir uns einfach den gesamten Inhalt unserer Unterseite edit-adresse.php rein und schmeissen den jetzt überflüssigen WordPress-Load raus. Das wars schon… fast.

Der Aufruf unserer funkelnagelneuen Submenu Page

Der muss natürlich noch ins Action-Tag unserer aufrufenden Seite. Da tauschen wir einfach die Belegung für die Variable aus:

/*Submenu-URL zusammenbauen*/        
        $meinplugin_URL = admin_url();
        $meinplugin_URL = $meinplugin_URL.“admin.php?page=adresse-edit„;

Das admin_url() holt uns die Adresse des Admin Screens, die fett gekennzeichnete Ergänzung enthält den Slug unserer Submenu Seite.

Klappts? Wenn sie jetzt aus der Adressentabelle heraus auf einen „Edit“-Button klicken, sollte sowas ähnliches angezeigt werden:

submenu_adminscreen

submenu_adminscreen

Schon besser, oder?

Und man spart sich wie gesagt den nicht ganz sauberen Trick mit dem wp-load, da werden auch die Puristen zufrieden sein. Man spart sich auch die zweite PHP-Datei, weil jetzt die ganze Funktionalität in unserer einen Plugin-Datei adressen-tabelle.php steckt. Ich finde die Lösung mit der „elternlosen“ Submenu Page sauber, und sowas wird man immer wieder mal gebrauchen können, wenn man in einem Plugin auf eine Unterseite verzweigen möchte. Hier noch die Plugin-Datei adressen-tabelle.php als ZIP, der Vollständigkeit halber. Und jetzt viel Spaß beim Nachbauen!

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Ein Dirty Trick: wir holen uns die wp-load.php

Wo ist unser wpdb-Objekt geblieben?

In unserer „nackten“ PHP-Datei steht es nämlich erstmal nicht zur Verfügung. Um jetzt aber trotzdem ranzukommen – wir wollen ja schließlich wieder mit $wpdb->get_results und all den praktischen Helferlein arbeiten – gibt es eine einfache, wenn auch unter WordPress-Puristen umstrittene Methode. Man holt sich mithilfe einer require()-Anweisung die Datei wp-load.php ins Boot, und schon kann man die WordPress-Funktionalitäten wieder nutzen. Wo diese Datei liegt, ist abhängig von der jeweiligen WordPress-Installation, normalerweise steckt sie im Stammverzeichnis, da wo auch wp-config.php und Konsorten zu finden sind. Falls sie also da zu finden ist, kann man sich so behelfen:

require(‚../../../wp-load.php‘);

Das ist natürlich nicht besonders Foolproof und fällt auf die Nase, wenn die Datei woanders liegen sollte.

Sauberere Methode – wenn auch etwas kryptisch

Eigentlich hasse ich es ja, Code zu verwenden, den ich nicht ganz verstehe. Aber hier mache ich mal eine Ausnahme, es funktioniert nämlich einwandfrei. Das Code Snippet stammt von Frankie Jarrets Seite, und dort kann man auch nachlesen warum man es so NICHT machen sollte…

Statt dem wie oben codierten absoluten Pfad kann man nach Frankie folgende Lösung verwenden:

$parse_uri = explode( ‚wp-content‘, $_SERVER[‚SCRIPT_FILENAME‘] );
require_once( $parse_uri[0] . ‚wp-load.php‚ );

Wie dem auch sei, wir holen uns halt unsere wp-load.php, auch wenn die Puristen Zetermordio schreien. Für unser kleines Adresseneditor-Plugin tuts diese Lösung wirklich, da werden wir keine Probleme mit Serverlast Verdopplung etc. zu erwarten haben.

Hurra, das wpdb-Objekt ist wieder da!

Und deshalb können wir den Code aus unserem ersten Adresseneditor-Plugin (fast) unverändert übernehmen. Die ID für den aktuellen Datensatz haben wir ja schon, die steckt in:

$akt_id = $_POST[„id“];

ganz am Anfang der Datei edit-adresse.php und kommt aus unserem aufrufenden Formular.

Der Select

… ist jetzt wie gehabt:

global $wpdb;
        $alleposts = $wpdb->get_results( „SELECT * from „.MAINTABLE.“ where ID = „.$akt_id.““);
      

Kleiner Negertrick in der Foreach-Schleife

Wenn wir den Foreach auch ungeändert übernehmen, kommt es nach dem Editieren des Datensatzes und Drücken des „Änderungen speichern“-Buttons zu einem unerwünschten Effekt: die Formularfelder werden auf die ursprünglichen Werte zurückgesetzt. Das führt natürlich zu heftiger Verwirrung beim Anwender, weil seine Änderungen plötzlich verschwunden sind. Dabei sind sie doch schon in der Datenbank gespeichert! Ich mach da mal kurzen Prozess und unterbinde die Anzeige des Formulars, wenn auf den „Änderungen speichern“-Button gedrückt wurde, dann siehts sauberer und für den Anwender besser logisch verständlich aus. Dazu binde ich eine IF-Abfrage mit ein, hier unten fett hervorgehoben:

foreach ( $alleposts as $einpost ) {     
    
//Begin Formular
echo ‚<form method=“post“>‘;

        if (!isset($_POST[’speichern‘])){
            echo „<div style = ‚border: 3px solid blue; padding: 10px; display: inline-block‘>“;
        echo ‚ID: &nbsp‘.$einpost->id.'<input type=“text“ name=“id“ value = „‚.$einpost->id.'“ hidden/></br>‘;
        echo ‚Vorname: <input type=“text“ name=“vorname“ value = „‚.$einpost->vorname.'“/></br>‘;
        echo ‚Nachname: <input type=“text“ name=“nachname“ value = „‚.$einpost->nachname.'“></br>‘;
       
        echo ‚<input type=“submit“ name = „speichern“ value=“Änderungen speichern“/>‘.“<br>“;
        } //end von nicht isset
        echo „</div>“;
        
echo ‚</form>‘;
// End Formular
    
} //end foreach

Damit verschwindet das Formular, sobald auf den „Änderungen speichern“-Button geklickt wurde.

Der Update wie gehabt

An der Update-Logik ändert sich auch nicht das Geringste, die übernehmen wie 1:1.

Zurück zur Adressenliste

Jetzt fehlt noch ein Link zurück zur Adressenliste, und auch das mach ich kurz und schmerzlos mit der URL der ersten Seite des Plugins:

echo „<a href = ‚http://localhost/turnverein/wp-admin/admin.php?page=adressen-tabelle’/><h1>Zurück zur Adressenliste</h1></a>“;

Sie müssen hier natürlich ihre eigene URL einsetzen, aber das sollte ja nun wirklich kein Problem sein. Funktionierts? Nach dem Klick auf  „Zurück zur Adressenliste“ sollte jetzt natürlich wieder unsere Adressentabelle auftauchen, mit den eben gemachten Änderungen.

Funktioniert – aber wie sieht denn das aus? Nacktes PHP!

Gemach, gemach, hier ging es um die Funktionalität. Zugegeben, besonders schön ist das nicht mit dem „weissen“ Unterformular ohne die gewohnte WordPress-Umgebung, aber das zu ändern ist nicht wirklich einfach, da bin ich noch am Forschen. Die Lösung könnte evtl. in diesem Artikel stecken oder auch hier, aber da bin ich noch nicht ganz durch. Ich halte euch auf dem Laufenden, wenn da mal eine Lösung in Sicht kommt.

 

 

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Tabelleneditor Nachschlag: Adressenliste als Ausgangspunkt

Ihr Wunsch ist mir Befehl: Tabellarische Adressenliste

Ich bin gebeten worden, einmal exemplarisch darzustellen, wie man den Tabelleneditor ausgehend von einer Liste aller Mitglieder aufruft. Das ist jetzt zwar echt wieder reines PHP, aber wenns gewünscht wird, na bitte, dann machen wir das auch noch. Wie soll das ganze aussehen? Also, zuerst zeigen wir mal eine Liste ausgewählter Mitgliederdaten an. In jeder Tabellenzeile soll es einen „Edit“-Button geben, und der soll das Tabelleneditorfenster zum aktuellen Datensatz aufmachen, hier die Funktionalität wie gehabt mit editieren und speichern der einzelnen Felder. Von hier aus solls auch wieder zurückgehen in die tabellarische Übersicht. Soweit OK?

Damit das nicht langweilig wird, arbeiten wir mit einer zweiten PHP-Datei für das Editor-Fenster, da kommen dann noch ein paar kleine Tricks mit dazu, wie man die WordPress-Funktionalität in eigenen PHP-Skripten nutzen kann, aber dazu später mehr, jetzt fangen wir mal ganz langsam an.

Die Ausgangsbasis: Tabellarische Mitgliederliste

Das ist auch nichts Neues, wir lassen einen Select* auf unsere Adressentabelle los und bauen uns erstmal eine tabellarische Ausgabe ausgewählter Felder. Das haben wir schon oft genug gemacht, das stell ich mal kommentarlos hier hin.

/*****Haupttabelle Name als Konstante definieren*******/
        define(„MAINTABLE“,“mitglieder_stamm“);
        echo „<h2>Mitglieder Adressenliste</h2>“;
        echo „Aktuelle Tabelle =&nbsp“.MAINTABLE.“<br>“;
        
        //Originalcode alle Datensätze holen
        global $wpdb;
        $alleposts = $wpdb->get_results( „SELECT * from „.MAINTABLE.““);

echo „<table‘>“;    
    
    // Titelzeile ausgeben
    echo „<thead>“;
    echo „<th>ID</th><th>Vorname</th><th>Nachname</th><th>PLZ</th><th>Ort</th><th>StrasseHausnr</th>“;
    echo „</thead>“;

    echo „<tbody>“;
    //Eine Zeile pro Datensatz ausgeben
    foreach ( $alleposts as $einpost ) {     
        
        echo „<tr><td>“.$einpost->id.“</td>“;
        echo „<td>“.$einpost->vorname.“</td>“;
        echo „<td>“.$einpost->nachname.“</td>“;
        echo „<td>“.$einpost->plz.“</td>“;
        echo „<td>“.$einpost->ort.“</td>“;
        echo „<td>“.$einpost->strassehausnummer.“</td>“;
        echo „</tr>“;
    }
    echo „</tbody>“;
echo „</table>“;
//Ende Originalcode Datensätze holen

Wo kommt jetzt unser „Edit“-Button hin?

In ein Formular natürlich. Das wickeln wir wieder in unsere Foreach-Schleife mit ein, mit einer entscheidenden Änderung: das Formular kriegt einen Action-Tag, in dem wird definiert, welche Datei beim Klicken auf den Submit-Button aufgerufen werden soll. Das sieht so aus:

foreach ( $alleposts as $einpost ) {     
        
        echo ‚<form method=“post“ action = „‚.$meinplugin_URL.'“>‘;
        echo „<tr><td>ID: &nbsp“.$einpost->id.“<input type=’text‘ name=’id‘ value = „.$einpost->id.“ hidden/></td>“;
        echo „<td>“.$einpost->vorname.“</td>“;
        echo „<td>“.$einpost->nachname.“</td>“;
        echo „<td>“.$einpost->plz.“</td>“;
        echo „<td>“.$einpost->ort.“</td>“;
        echo „<td>“.$einpost->strassehausnummer.“</td>“;
        echo ‚<td><input type=“submit“ name = „edit“ value=“Edit“/>‘;
        echo ‚</form></td>‘;
        echo „</tr>“;
        
    } // end foreach

Definition der aufzurufenden PHP-Datei

Hoppala! Was hat das $meinplugin_URL zu bedeuten? Das ist eine Variable, auf die ich vorher die aufzurufende Datei mit dem kompletten Pfad gelegt habe. Die Variablendefinition sieht so aus:

/*Pfad zum plugin-Verzeichnis*/
$meinplugin_URL = plugins_url();
/*Verzeichnis des aktuellen Plugins dranhängen*/
$meinplugin_URL=$meinplugin_URL.‘/adresse-tabelle/edit-adresse.php‚;

Ich hole mir erst mit der Funktion plugins_url() den Pfad zum Plugins-Verzeichnis meiner WordPress-Instanz. Dann hänge ich noch das Verzeichnis meines Plugins und den Namen der aufzurufenden Datei dran. Die Datei muss natürlich existieren, deswegen legen wir sie uns zum Testen jetzt einfach an. Sie muss erstmal gar nix machen ausser:

<?php
echo „Ich bin die Datei edit-adresse.php“;
?>

Soweit alles Roger? Wenn das Plugin aktiviert ist, sollte es jetzt etwa so aussehen:

adressenliste_edit

adressenliste_edit

Und was kommt bei Klick auf einen Edit-Button?

Nicht viel, wir haben ja nicht viel gemacht. Ein grosses weisses Browserfenster, auf dem nur steht:

Ich bin die Datei edit-adresse.php

Wo ist unsere WordPress-Umgebung hinverschwunden? Header und Sidebars und das Titelbild und alles – nix da, aber auch gar nix. Tscha, so einfach ist das nicht mit unserer „nackerten“ PHP-Datei, aber darum kümmern wir uns später, jetzt geht es erstmal um die Funktionalität.

Wir brauchen die ID des aktuellen Datensatzes!

Und die kriegen wir auch, nämlich aus unserem abgeschickten Formular. Wir ergänzen die Datei edit-adresse.php so:

<?php
$akt_id = $_POST[„id“];
echo „Ich bin die Datei edit-adresse.php und die aktuelle ID ist: &nbsp“.$akt_id;
?>

Für das $_POST[„id“] muss natürlich der Feldname aus dem Formular stimmen, sonst klappt das nicht. Aber wenn das alles hinhaut, sollte die Ausgabe jetzt so aussehen:

Ich bin die Datei edit-adresse.php und die aktuelle ID ist:  7

Vorausgesetzt, sie haben den Datensatz mit der ID 7 angeklickt. Also, damit kann man jetzt arbeiten. Wir zeigen den Datensatz zur aktuellen ID an und machens mit dem editieren und speichern ganz genauso wie im vorigen Plugin. Oder doch nicht?

Uns fehlt noch das wpdb-Objekt!

Das steht nämlich in unserer Datei edit-adresse.php so wie sie ist erstmal nicht zur Verfügung. Noch nicht, wir holen uns die Funktionalität schon noch, aber dazu gibts einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Datenbankeditor die Letzte: Source als ZIP und Ausblick

Der Datenbankeditor kann jetzt marschieren

Das war jetzt (fast) reines HTML/PHP, und man kann das Prinzip des Datenbankeditors ja auch auf MySQL-Tabellen ausserhalb von WordPress anwenden, dann gehts halt nicht mit der $wpdb->update Methode, sondern mit einem pdo und einem Prepared Statement. Das hat jetzt aber wirklich gar nichts mehr mit WordPress zu tun, da schenke ich mir jetzt eine längere Erklärung und verweise für den Update in PHP auf diesen Artikel . Lieber gebe ich hier noch einen kleinen Ausblick.

Editor für alle Fälle, für jede eigene Tabelle

Jedenfalls habe ich hoffentlich verständlich dargestellt, wie man in WordPress Datensätze aus beliebigen MYSQL-Tabellen anzeigen, editieren und wieder wegschreiben kann. Diese Funktionalität ist immer wieder mal gefragt, besonders wenn man mit eigenen Tabellen arbeitet, für die hat man ja in WordPress erstmal kein Benutzerinterface. Ich habs jetzt mal als Plugin gezeigt, das nur der Admin bedienen darf. Wenn sie einen Tabelleneditor für die Benutzerseite anlegen wollen, packen sie die Funktionalität in einen Shortdode, geht genauso.

Man könnte jetzt noch ehrgeizig werden und zum Beispiel statt der manuellen Eingabe der ID (in unserem Fall der Mitgliedsnummer) auch die Auswahl aus einer Liste anbieten wollen, oder man könnte eine Liste aller Mitglieder ausgeben und nach jedem Datensatz einen „Ändern“-Button anzeigen, der dann  in den Datenbankeditor springt, oder oder oder… aber da gehts echt verschärft nach PHP, das darf sich jeder selber austüfteln.

Jetzt gibts noch wie versprochen hier das Plugin adressen-editor als ZIP-Datei, und damit lassen wir es gut sein. Viel Spaß beim Anpassen an ihre eigenen Tabellen!

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Datenbankeditor die Vierte: Änderungen speichern

Jetzt haben wir unsere Adressdaten editiert, und nu?

Speichern wollen wir sie natürlich noch, und dafür darf wieder unser wpdb-Objekt herhalten. Welche Daten wir speichern wollen, lesen wir aus dem Unterformular, das sind unsere Werte aus $_POST[‚feldname‘], wobei „feldname“ im Formular festgelegt ist. Ich hab hier einfach die selben Bezeichnungen wie die der Datenbankfelder genommen, das ist am leichtesten zu lesen. Nochmal kurz zur Erinnerung, das Formularfeld für den Vornamen haben wir so definiert:

echo ‚Vorname: <input type=“text“ name=“vorname“ value = „‚.$einpost->vorname.'“/></br>‘;

Den aktuellen Wert (den der Benutzer evtl. editiert hat) legen wir nach dem Klick auf den „Änderungen speichern“- Button der besseren Übersicht halber auf eine Variable:

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

$neu_vorname = $_POST[‚vorname‘];

}

Wichtig ist hier die richtige Positionierung der If-Isset-Abfrage, die muß nach der schließenden Klammer der ersten If-Isset-Abfrage aus dem Hauptformular hin. Wir legen uns alle Feldinhalte des Unterformulars auf Variable, und die verarbeiten wir dann in einem Update auf die Datenbank weiter.

Ein bißchen unhandlich: die wpdb-Update Methode

Ein kurzer Blick in den Codex, und es könnte einem etwas das Gruseln kommen. Da wird mit Arrays hantiert und mit Formaten und was weiß ich noch alles, und dabei wollen wir doch nur einen stinknormalen Update auf einen einzelnen Datensatz fahren. Na ja, ich versuchs mal aufzudröseln. In diesem Artikel (runterscrollen bis UPDATING DATA in Sicht kommt) ist es recht einleuchtend beschrieben, wie man mit der Update-Methode umgeht. Das sieht dann so aus:

global $wpdb;
  
    $wpdb->update(
    “.MAINTABLE.“,
    array(
        ‚vorname‘ => $neu_vorname  // string
        
    ),
    array( ‚id‘ => $ID ),
    array(
        ‚%s‘   // value1
        
    ),
    array( ‚%d‘ )
);

Ich gebe den Tabellennamen wieder mit der Konstanten MAINTABLE mit. Dann gehts los.

  • Wir benutzen die Methode $wpdb->update().
  • Im ersten Array wird definiert, welches Feld (hier ‚vorname‚) mit welchem Wert (hier $neu_vorname) aktualisiert werden soll.
  • Das zweite Array legt die WHERE-Klausel fest, in unserem Fall wird das Feld id mit dem Wert der Variablen $ID verglichen, die habe ich vorher in der Isset-Auswertung mit dem Wert der id aus dem Formular belegt..
  • Das dritte Array legt fest, welches Format das zu updatende Feld hat. Da wir es nur mit Textfeldern zu tun haben, ist das immer ein %s (für String).
  • Im vierten Array wird definiert, welches Format das Feld in der WHERE-Klausel hat. Ich habe hier ein %d (für Dezimal) angegeben, da wir es mit einem ganzzahligen Wert zu tun haben.

Wie ich schon sagte, ein bißchen unhandlich und gewöhnungsbedürftig, aber letztendlich funktionierts, und das ist die Hauptsache. Einige der genannten Parameter sind optional, aber ich habe noch nicht genau herausgetüftelt welche, wir verwenden das jetzt mal so wie es ist.

Wichtig: wir updaten immer alle Felder

Man könnte auf die Idee kommen und erstmal abfragen, in welchen Feldern Änderungen vorgenommen wurden, aber die Update-Methode macht das von selber, also kann man sich den Aufwand schenken. Also packen wir uns bei Klick auf den „Änderungen speichern“ – Button einfach immer alle Felder aus dem Formular und schreiben sie mit dem Update in die Datenbank.

Boing, reingefallen: disabled ist komplett disabled, ätsch!

Und wenn der Update jetzt nicht klappt, liegt es daran, daß ich im Formular das Feld für die ID auf „disabled“ gestellt habe, damit man die ID nicht versehentlich ändern kann. Damit kann ich aber den Wert des Formularfeldes nicht mehr abfragen! Beliebter Fehler, mir wars bloß entfallen. Das müssen wir noch ändern. Ich stelle das Feld auf „hidden“ und gebe die ID nur zur Kontrolle mit aus. Die Zeile im Formular sieht jetzt so aus:

echo ‚ID: &nbsp‘.$einpost->id.'<input type=“text“ name=“id“ value = „‚.$einpost->id.'“ hidden/></br>‘;

Es wäre ohnehin nichts passiert, weil wir in unserem Update das Feld id gar nicht mit drin haben, aber so ist es logischer und für den Benutzer besser verständlich.

Der Update für den kompletten Datensatz

… wird genau nach obigem Muster zusammengebaut. Ich lege mir die Formularinhalte auf Variable, und setze diese in das Array im Update ein. Dabei auf die richtigen Kommas hinter den Argumenten achten!

Ich mach mal nur noch zwei weitere Felder beispielhaft, den Nachnamen und die E-Mail-Adresse, denn Rest können sie nach Belieben selber noch einbauen. Wir geben dann noch eine Meldung aus, daß die Änderungen gespeichert sind, und das wars. Wenn unser Benutzer jetzt auf „Änderungen speichern“  klickt, passiert Folgendes:

if (isset($_POST[’speichern‘])){
       
    $ID = $_POST[‚id‘];
    $neu_vorname = $_POST[‚vorname‘];
    $neu_nachname = $_POST[’nachname‘];
    $neu_your_email = $_POST[‚your_email‘];
    
    global $wpdb;
    
    $wpdb->update(
    “.MAINTABLE.“,
    array(
        ‚vorname‘ => $neu_vorname,  // string
        ’nachname‘ => $neu_nachname, //string
        ‚your_email‘ => $neu_your_email //string
    ),
    array( ‚id‘ => $ID ),
    array(
        ‚%s‘,      // value1
        ‚%s‘,    // value2
        ‚%s‘    // value3
    ),
    array( ‚%d‘ )
);
    
    echo „<h1>Änderungen gespeichert</h1>“;
    
} //ende von if isset post speichern

Das wars! Wenn man jetzt die Änderungen sehen will, ruft man einfach nochmal die selbe ID auf, und da sind sie auch schon – wenn alles geklappt hat. Ich geb nachher das ganze Plugin noch als ZIP-Datei mit, dann können sie’s genau nachvollziehen.

Für Perfektionisten: Abfragen, ob der Update geklappt hat

Die Update-Methode des wpdb-Objekts hat auch Rückgabewerte, ich zitiere mal kurz den Codex:

UPDATE rows

Update a row in the table. Returns false if errors, or the number of rows affected if successful.

Man kann sich jetzt den Update auch auf eine Variable legen, das sieht dann zum Besipiel so aus:

$speichern=$wpdb->update(…Parameterarrays…)

Dann kann man die Variable $speichern entsprechend nach dem Rückgabewert auswerten und ausgeben. Falls sie „false“ zurückgeben sollte, hat man übrigens ein echtes Problem, dann haut die Verbindung zur Datenbank aus irgendeinem Grund nicht hin… ist mir aber noch nie passiert. Ich machs ganz einfach und gebe nur aus, wieviele Zeilen von dem Update betroffen waren:

echo $speichern.“&nbsp Datensätze geändert“;

Hier kommt übrigens 0 (Null) zurück, wenn der Benutzer zwar keine Änderungen gemacht, aber trotzdem auf „Änderungen speichern“ geklickt hat. Das liegt daran, daß der Update nichts tut, wenn die zu speichernden Werte mit den bereits vorhandenen Werten in der Tabelle identisch sind. Aber das sind jetzt echt Feinheiten, da können sich Perfektionisten selber durchrecherchieren, ich mach hier mal nen Punkt, und einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Datenbankeditor die Dritte: Formular im Formular

Editierbare Felder – bloß wie?

Wir waren dabei stehengeblieben, daß wir die Adressdaten zu einer vom Benutzer eingegebenen Mitgliedsnummer angezeigt haben. Jetzt gehts zum nächsten Schritt, wir wollen die Daten ja nicht nur anzeigen, sondern auch ändern. Dafür nehmen wir – ein Formular! Und zwar innerhalb unserer Foreach-Schleife, wir wollen ja genau den Inhalt des einen von unserem Select zurückgegebenen Datensatzes ausgeben.

Das Unterformular in der Foreach-Schleife

Das ist keine Hexerei, sondern ein stinknormales Formular mit einem Submit-Button. Die Konstruktion beginnt so:

foreach ( $alleposts as $einpost ) {     
    
//Begin Formular
echo „<form method=“post“>“;

//Hier kommen die Formularfelder hin       
        
echo ‚<input type=“submit“ name = „speichern“ value=“Änderungen speichern“/>‘.“<br>“;

echo „</form>“;
// End Formular

} //end foreach

Werte (values) der Input-Felder vorbelegen

Wir nehmen ganz normale Text-Inputfelder, und jetzt kommt der Witz an der ganzen Sache: sie werden mit unseren Feldinhalten aus der Datenbank gefüllt. Das geht ganz einfach, wir sind ja innerhalb der Foreach-Schleife und kommen z.B. mit $einpost->vorname an den Wert des Vornamen-Feldes ran. Das editierbare Formularfeld für den Vornamen mit Vorbelegung sieht dann so aus:

echo ‚Vorname: <input type=“text“ name=“vorname“ value = „‚.$einpost->vorname.'“></br>‘;

Hier muss man mit den doppelten und den einfachen Anführungszeichen ein bißchen aufpassen, aber ich pack euch nachher den Code noch in ein ZIP-File, dann habt ihrs ganz genau. Falls die Ausgabe eines Values beim ersten Leerzeichen abgeschnitten wird, stimmt was mit den Anführungszeichen nicht, darüber fällt man am Anfang gerne.

Das Feld für die ID (Mitgliedsnummer) kriegt eine Sonderbehandlung, das soll ja um Himmels Willen nicht geändert werden, auch nicht versehentlich, deswegen setzen wir es gleich auf disabled:

echo ‚ID: <input type=“text“ name=“id“ value = „‚.$einpost->id.'“ disabled></br>‘;

Die anderen Felder (Nachname, Telefon, Ort usw.) werden ganz genau so wie oben beim Vornamen konstruiert, so sieht das fertige Produkt dann aus:

unterformular_screenshot

unterformular_screenshot

Ich hab noch einen <div> mit einem Rahmen um die ganze Sache gelegt und die Felder für E-Mail und Strasse mit size=“50″ grösser gemacht, aber das wars dann schon. Eure Bildschirmanzeige nach Abschicken der Mitgliedsnummer sollte jetzt etwa so aussehen:

 

unterformular_anzeige

unterformular_anzeige

Sieht doch schon mal ganz gut aus, oder? Jetzt müßte nur noch etwas passieren, wenn man auf „Änderungen speichern“ klickt, aber dazu gibts einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Datenbankeditor die Zweite: ID abfragen und Adressdaten anzeigen

Mitgliedsnummer abfragen

Dafür – wie könnte es anders sein – brauchen wir ein kleines Formular. Das können wir eigentlich schon, so sieht das aus:

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

Die eingegebene Mitgliedsnummer holen wir uns wie gehabt nach drücken des „Abschicken“-Buttons in eine Variable, dazu braucht es nicht mehr als das:

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

    $akt_m_nr = $_POST[‚m_nr‘];

}

Ausgabe der Adressdaten zur eingegebenen Mitgliedsnummer

Jetzt gehts auf die Datenbank. Wir arbeiten wie gewohnt mit einem wpdb-Objekt, und setzen in den Select einfach unsere Variable  $akt_m_nr ein, die enthält ja die Mitglieds-ID. (Ich habe weiter oben wieder den Namen der aktuellen Tabelle  auf die Konstante MAINTABLE gelegt)

global $wpdb;
        $alleposts = $wpdb->get_results( „SELECT * from „.MAINTABLE.“ where ID = „.$akt_m_nr.““);

Ergebnis: genau ein Datensatz, nämlich der mit der eingegebenen ID. Ausgabe mit Foreach, auch das wie gehabt. Ich formatiere die ganze Sache als Tabelle, damit es übersichtlicher wird.

adresstabelle

adresstabelle

Die Ausgabe der Titelzeile der Tabelle ist hier im Screenshot leider abgeschnitten, aber die entsprechenden <th>-Tags kann man sich ja leicht dazudenken. Das Ergebnis nach Eingabe einer existierenden Mitgliedsnummer und drücken des „Abschicken“-Buttons sollte jetzt ungefähr so aussehen:

adresstabelle_screenshot

adresstabelle_screenshot

Ist doch schon mal ganz brauchbar. Jetzt müßte man die Adressdaten nur noch editieren können, aber dazu gibts einen neuen Beitrag – morgen.

 

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

Mein Freund, der Shortcode – auch auf Knopfdruck mit Button

Warum ich Shortcodes so nützlich finde

Ganz einfach, weil sie die volle Funktionalität von PHP mit all den vielfältigen Möglichkeiten von WordPress vereinen. Ich glaube, daß Shortcodes eins der meistunterschätzten programmiertechnischen Werkzeuge von WordPress sind. Alle Welt schreit immer nach Plugins, aber die sind nicht immer der Weisheit letzter Schluß. Gerade wenn man Ausgaben und Ereignisse auf der für den Benutzer sichtbaren Oberfläche einer Webseite steuern will, sind Shortcodes ein mächtiges Werkzeug und nahezu universell einsetzbar. Sie erlauben durch das wpdb-Objekt vollen Datenbankzugriff (übrigens auf jede beliebige Datenbank, für die man den Connect hat), sie erlauben einem das Einsetzen von Formularen mit all den ausgefuchsten Feinheiten von PHP, sie erlauben die Abfrage der Eigenschaften und die Manipulation nahezu aller WordPress-Objekte, und vieles mehr. Kurz gesagt, sie sind das geniale Universal-Schweizermesser wenn man WordPress programmiererisch zuleibe rücken möchte. Jetzt aber genug der Lobeshymne, heute Abend hab ich noch ein nettes Zuckerl:

Shortcodes auf Knopfdruck mit Buttons

Manchmal wäre es ganz nett, wenn ein Shortcode auf einer Seite oder in einem Beitrag nicht sofort beim Aufruf loslegen würde, besonders dann nicht, wenn man mehrere Shortcodes im selben Objekt einsetzen möchte, das wird schnell unübersichtlich. Dann wäre es ganz nützlich, wenn man erst einmal auf ein entsprechend beschriftetes Knöpfchen drücken könnte, und der Shortcode erst dann ausgeführt wird. Das ist nicht schwer zu realisieren, und die Lösung ist (wie könnte es anders sein) selbst ein Shortcode.

Formular für den Button

Um einen klickbaren Button zu erhalten, lege ich ein kleines Formular an, das nichts ausser einem submit-Button enthält, das sieht so aus:

echo ‚<form method=“post“>‘;
echo ‚<input type=“submit“ name = „senden“ value=“Shortcode abrufen“/>‘;
echo „</form>“;

Was passieren soll, wenn auf den Button geklickt wird, wird wie üblich mit ISSET bestimmt, und hier kommt auch gleich der Witz an der ganzen Sache:

if (isset($_POST[’senden‘]))
{
    //Hier Shortcode einsetzen, wichtig: einfache Hochkommas
    $inhalt = „[form id=’26‘ title=’Anmeldung‘]“;
    echo do_shortcode($inhalt);
}

Die Variable $inhalt wird einfach mit dem String des aufzurufenden Shortcodes belegt, und das kann wirklich ein x-beliebiger Shortcode sein, ob selbst definiert, oder der Shortcode eines Contact-Form-7-Formulars, oder ein MetaSlider-Shortcode oder was einem sonst gerade einfällt. Wichtig ist nur, dass man die doppelten Anführungszeichen in den Shortcode-Parametern durch einfache Hochkommas ersetzt. Mehr ist nicht dran, so sieht das Ganze am Stück aus:
function button_shortcode(){
   
//Begin Formular
echo ‚<form method=“post“>‘;
echo ‚<input type=“submit“ name = „senden“ value=“Shortcode abrufen“/>‘.“<br>“;
echo „</form>“;
// End Formular

if (isset($_POST[’senden‘]))
{
    //Hier Shortcode einsetzen, wichtig: einfache Hochkommas
    $inhalt = „[form id=’26‘ title=’Anmeldung‘]“;
    echo do_shortcode($inhalt);
}
   
}
add_shortcode(‚button‘, ‚button_shortcode‘);

An der gewünschten Stelle im Beitrag oder auf einer Seite den Shortcode [button] einsetzen, und voila, sie haben ihren Shortcode auf Knopfdruck!

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend