In unserer „nackten“ PHP-Datei steht es n\u00e4mlich erstmal nicht zur Verf\u00fcgung. Um jetzt aber trotzdem ranzukommen – wir wollen ja schlie\u00dflich 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\u00e4ten wieder nutzen. Wo diese Datei liegt, ist abh\u00e4ngig 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:<\/p>\n
require(‚..\/..\/..\/wp-load.php‘);<\/em><\/p>\n Das ist nat\u00fcrlich nicht besonders Foolproof und f\u00e4llt auf die Nase, wenn die Datei woanders liegen sollte.<\/p>\n Eigentlich hasse ich es ja, Code zu verwenden, den ich nicht ganz verstehe. Aber hier mache ich mal eine Ausnahme, es funktioniert n\u00e4mlich einwandfrei. Das Code Snippet stammt von Frankie Jarrets Seite<\/a>, und dort kann man auch nachlesen warum man es so NICHT machen sollte…<\/p>\n Statt dem wie oben codierten absoluten Pfad kann man nach Frankie folgende L\u00f6sung verwenden:<\/p>\n $parse_uri = explode( ‚wp-content‘, $_SERVER[‚SCRIPT_FILENAME‘] );<\/em> Wie dem auch sei, wir holen uns halt unsere wp-load.php, auch wenn die Puristen Zetermordio schreien. F\u00fcr unser kleines Adresseneditor-Plugin tuts diese L\u00f6sung wirklich, da werden wir keine Probleme mit Serverlast Verdopplung etc. zu erwarten haben.<\/p>\n Und deshalb k\u00f6nnen wir den Code aus unserem ersten Adresseneditor-Plugin (fast) unver\u00e4ndert \u00fcbernehmen. Die ID f\u00fcr den aktuellen Datensatz haben wir ja schon, die steckt in:<\/p>\n $akt_id = $_POST[„id“];<\/em><\/p>\n ganz am Anfang der Datei edit-adresse.php und kommt aus unserem aufrufenden Formular.<\/p>\n … ist jetzt wie gehabt:<\/p>\n global $wpdb;<\/em> Wenn wir den Foreach auch unge\u00e4ndert \u00fcbernehmen, kommt es nach dem Editieren des Datensatzes und Dr\u00fccken des „\u00c4nderungen speichern“-Buttons zu einem unerw\u00fcnschten Effekt: die Formularfelder werden auf die urspr\u00fcnglichen Werte zur\u00fcckgesetzt. Das f\u00fchrt nat\u00fcrlich zu heftiger Verwirrung beim Anwender, weil seine \u00c4nderungen pl\u00f6tzlich 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 „\u00c4nderungen speichern“-Button gedr\u00fcckt wurde, dann siehts sauberer und f\u00fcr den Anwender besser logisch verst\u00e4ndlich aus. Dazu binde ich eine IF-Abfrage mit ein, hier unten fett hervorgehoben:<\/p>\n foreach ( $alleposts as $einpost ) { \u00a0\u00a0 \u00a0<\/em> \u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0if (!isset($_POST[’speichern‘])){<\/strong><\/em> Damit verschwindet das Formular, sobald auf den „\u00c4nderungen speichern“-Button geklickt wurde.<\/p>\n An der Update-Logik \u00e4ndert sich auch nicht das Geringste, die \u00fcbernehmen wie 1:1.<\/p>\n Jetzt fehlt noch ein Link zur\u00fcck zur Adressenliste, und auch das mach ich kurz und schmerzlos mit der URL der ersten Seite des Plugins:<\/p>\n echo „<a href = ‚http:\/\/localhost\/turnverein\/wp-admin\/admin.php?page=adressen-tabelle’\/><h1>Zur\u00fcck zur Adressenliste<\/h1><\/a>“;<\/em><\/p>\n Sie m\u00fcssen hier nat\u00fcrlich ihre eigene URL einsetzen, aber das sollte ja nun wirklich kein Problem sein. Funktionierts? Nach dem Klick auf\u00a0 „Zur\u00fcck zur Adressenliste<\/em>“ sollte jetzt nat\u00fcrlich wieder unsere Adressentabelle auftauchen, mit den eben gemachten \u00c4nderungen.<\/p>\n Gemach, gemach, hier ging es um die Funktionalit\u00e4t. Zugegeben, besonders sch\u00f6n ist das nicht mit dem „weissen“ Unterformular ohne die gewohnte WordPress-Umgebung, aber das zu \u00e4ndern ist nicht wirklich einfach, da bin ich noch am Forschen. Die L\u00f6sung k\u00f6nnte evtl. in diesem Artikel <\/a>stecken oder auch hier<\/a>, aber da bin ich noch nicht ganz durch. Ich halte euch auf dem Laufenden, wenn da mal eine L\u00f6sung in Sicht kommt.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Wo ist unser wpdb-Objekt geblieben? In unserer „nackten“ PHP-Datei steht es n\u00e4mlich erstmal nicht zur Verf\u00fcgung. Um jetzt aber trotzdem ranzukommen – wir wollen ja schlie\u00dflich 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[20,21,11,7,4,8,2],"tags":[],"_links":{"self":[{"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/posts\/465"}],"collection":[{"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/comments?post=465"}],"version-history":[{"count":5,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/posts\/465\/revisions"}],"predecessor-version":[{"id":470,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/posts\/465\/revisions\/470"}],"wp:attachment":[{"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/media?parent=465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/categories?post=465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/tags?post=465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Sauberere Methode – wenn auch etwas kryptisch<\/h2>\n
\nrequire_once<\/strong>( $parse_uri[0] . ‚wp-load.php<\/strong>‚ );<\/em><\/p>\nHurra, das wpdb-Objekt ist wieder da!<\/h2>\n
Der Select<\/h2>\n
\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0$alleposts = $wpdb->get_results( „SELECT * from „.MAINTABLE.“ where ID = „.$akt_id<\/strong>.““);<\/em>
\n\u00a0\u00a0 \u00a0\u00a0\u00a0<\/em><\/p>\nKleiner Negertrick in der Foreach-Schleife<\/h2>\n
\n\u00a0\u00a0 \u00a0<\/em>
\n\/\/Begin Formular<\/em>
\necho ‚<form method=“post“>‘;<\/em><\/p>\n
\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0echo „<div style = ‚border: 3px solid blue; padding: 10px; display: inline-block‘>“;<\/em>
\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0echo ‚ID:  ‘.$einpost->id.'<input type=“text“ name=“id“ value = „‚.$einpost->id.'“ hidden\/><\/br>‘;<\/em>
\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0echo ‚Vorname: <input type=“text“ name=“vorname“ value = „‚.$einpost->vorname.'“\/><\/br>‘;<\/em>
\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0echo ‚Nachname: <input type=“text“ name=“nachname“ value = „‚.$einpost->nachname.'“><\/br>‘;<\/em>
\n\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0 <\/em>
\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0echo ‚<input type=“submit“ name = „speichern“ value=“\u00c4nderungen speichern“\/>‘.“<br>“;<\/em>
\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0} \/\/end von nicht isset<\/strong><\/em>
\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0echo „<\/div>“;<\/em>
\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0<\/em>
\necho ‚<\/form>‘;<\/em>
\n\/\/ End Formular<\/em>
\n\u00a0\u00a0 \u00a0<\/em>
\n} \/\/end foreach<\/em><\/p>\nDer Update wie gehabt<\/h2>\n
Zur\u00fcck zur Adressenliste<\/h2>\n
Funktioniert – aber wie sieht denn das aus? Nacktes PHP!<\/h2>\n