Beiträge von maksimilian

  • Klasse WP_Widget: Abspeichern von Änderungen ?

    @ b3317133 #10

    Ich habe mal weitergetestet, auch im Vergleich mit einem Beispiel-Plugin, und sehe jetzt klarer. Für eine Übergangszeit werde ich einen Kompromiss eingehen, um endlich weiterzukommen. Ich verwende noch WP_Widget, toleriere den Eintrag in Tabelle wp_options und speichere die Daten in einer eigenen Tabelle (wobei es sich um Daten auch anderer im Plugin verwendeter Objekte als dem Widget handelt).

    Meine Bemerkung zur verwendeten DB-Schnittstelle war nicht korrekt. Ich verwende schon wpdb. Zur Einrichtung einer Tabelle wird dabei die Funktion dbDelta aufgerufen.

  • Klasse WP_Widget: Abspeichern von Änderungen ?

    Zitat von strub

    Wenn Du die Daten in eine eigene Tabelle einfügen willst, würde ich nur die Datenbankanbindung von WP benutzen und den Rest wie die create, update, delete Aktionen selber machen. Da ersparst Du dir viel Zeit dich mit den verschleierten Funktionen und Klassen herumzukämpfen.

    Ich mache meistens eine Model, Factory und Action Klasse, somit ist alles schön getrennt und man weis genau wo man was finden kann und ohne grosse Doku versteht fast jeder was die Klasse macht oder wie man diese anwendet. Aber das ist natürlich Geschmacksache.

    Vielleicht hilfst Du mir etwas auf die Sprünge. Sind Model, Factory und Action eingeführte Begriffe ? Kannst Du mir einen Link auf Beispiele geben ?

    Als Datenbankschnittstelle verwende ich dbDelta.

  • Klasse WP_Widget: Abspeichern von Änderungen ?

    Zitat von b3317133

    Was genau hindert Dich daran, widget(), form() und update() zu verwenden, um darin Daten aus einer eigenen Tabelle zu lesen bzw. zu speichern?

    Und was genau hast Du bereits ausprobiert und was daran hat nicht funktioniert?

    Wenn ich es richtig verstehe, werden die Optionswerte in $instance transportiert. Wenn ich den Standard von WP_Widget, die Optionen in der Tabelle wp_options abzuspeichern, nicht verwende, habe ich das Problem, $instance zu versorgen. Die Methode update() erhält die geänderten Optionswerte in $new_instance, bei mir bisher nicht, wenn update() nach Speichern aufgerufen wird (was jetzt der Fall ist). Ich habe den Eindruck, dass die Verwendung des Standardwidgets WP_Widget nicht geeignet ist, wenn man einen eigenen Speicherort für die Optionen einführen will.

  • Klasse WP_Widget: Abspeichern von Änderungen ?

    @ b3317133 #2

    Ich hatte u.a. versucht, in der Funktion update() der Widget-Definition eine eigene Prozedur aufzurufen, was nicht funktionierte (der NetBeans Trace steuert den gesetzten Haltepunkt in dieser Prozedur nicht an). Außerdem hatte ich mir aus den WP_Widget Methoden einige herausgesucht, deren Name nach "Sichern" aussieht wie update_callback(), save_settings(). Gut, dann versuche ich es nochmal mit update(). Ich dachte bisher, dass update() nur den Refresh der im Widget angezeigten Daten vornimmt. Ich habe im Internet bisher immer nur dieses von Dir zitierte Beispiel für update() gefunden. Mich irritiert, dass dort nie ein Abspeichern von Daten demonstriert wird.

    Wird die update-Methode von der Betätigung des Speichern-Buttons ausgelöst ?

  • Klasse WP_Widget: Abspeichern von Änderungen ?

    Hallo Ihr,

    gibt es eine Methode, mit welcher in der Funktion update() des von der Klasse WP_Widget abgeleiteten Widgets geänderte Optionen in einer eigenen Datenbanktabelle gespeichert werden können ? Ich habe diverse Methoden ausprobiert, aber die richtige bisher nicht gefunden.

    Was passiert, wenn im Aufruf des Widgets im Admin-Bereich der Homepage (Design > Widgets) der Speichern-Button betätigt wird. Diesen Button programmiert man ja nicht selbst.

    maksimilian

  • MySQLi-Methodik

    Zitat von danielgoehr

    Klar geht das. Du kannst die Tabelle damit erstellen oder auch in einer selbst erstellten Tabelle lesen/schreiben...

    https://codex.wordpress.org/Creating_Tables_with_Plugins

    https://premium.wpmudev.org/blog/creating-…es-for-plugins/

    Danke für diese Links, danielgoehr. Du hast mir bisher bereits entscheidende Tipps gegeben. Auch jetzt ersparst Du mir den Vorwurf mangelnden Engagements beim Googeln. Ich war bereits auf die Funktion dbDelta gestoßen, hatte aber übersehen, dass sie mit $wpdb verknüpft ist. Und mich dann zu sehr in MySQLi verbissen, obwohl ich auch damit klarzukommen beginne.

  • MySQLi-Methodik

    @ danielgoehr, b3317133

    Danke für Eure schnellen Antworten. Die Bedenken, wpdb nicht zu verwenden, kenne ich. Leider gibt es hiermit keine Möglichkeit, eine neue Tabelle einzurichten.
    Der Wunsch hierzu entsteht bei mir während einer Testphase, während der ich zum Überprüfen von Veränderungen, oft mit phpmyadmin in die DB schaue. Wenn Eintragsänderungen via wpdb und update_options()/delete_option() gemacht werden, muss ich jedesmal die Tabelle wp_options durchkämmen, da nach Löschen/Einrichten die Tabelleneinträge wieder an anderen Stellen stehen. Wenn mein Plugin stabil ist, könnte ich natürlich zu wpdb zurückkehren.

  • MySQLi-Methodik

    Hallo Ihr,

    ich möchte in einem Plugin eine eigene Tabelle in der MySQL-Datenbank verwenden. Die Einrichtung der Tabelle funktioniert, nur mit dem Auslesen von Daten komme ich noch nicht klar. Z.B.

    $sql_instr = "SELECT " . "option1" . " FROM " . "optionen";
    $result = mysqli_query( $db_link, $sql_instr );

    Die Funktion mysqli_query liefert mit $result ein Objekt, über welches der ausgelesene Wert besorgt werden muss. Wie funktioniert das ? Z.B. mysqli_fetch_assoc() habe ich noch nicht erfolgreich anwenden können.

    Bitte gebt mir einen Tipp oder eine Quelle, wo ich nachlesen kann. Die gegoogelten Beispiele bringen mich nicht weiter.

    maksimilian

  • Bei Plugin Aktivierung zusätzliche Option abrufen

    @ danielgoehr #10

    Ich hatte die PM geschickt, weil mein letzter Post erst nach sehr langer Zeit akzeptiert wurde (für einen Neuling ein ungewohntes Verfahren in diesem Forum).
    Dass ein Action Link einem Plugin erst nach dessen Aktivierung hinzugefügt werden kann, ist mir jetzt klar. Ich stelle inzwischen fest, dass die Verwendung von add_menu_page() für mich keine Möglichkeit ist, weil diese Funktion ja einen Eintrag in der Dashboard Menüliste erzeugt. Mit Deinem Vorschlag mit der Verwendung der Variablen $_GET komme ich (noch) nicht klar. Ich verfolge jetzt mal den Ansatz mit einem zusätzlichen PHP-Script. Das lässt sich mit dem hinzugefügten Action Link aufrufen. Es gibt aber ein Problem mit der Ablaufumgebung für dieses Script. Wenn beispielsweise dort der Aufruf der Funktion get_option() vorkommt, wird diese erst gefunden, wenn option.php explizit includiert wird. Das setzt sich dann fort, d.h. alle php-Dateien müssen includiert werden, aus welchen Funktionen aufgerufen werden (z.B. plugin.php für apply_filters(), load.php fpe wp_installing() usw. ). Gibt es eine einfachere Methode im Script die notwendige Ablaufumgebung herzustellen oder mache ich da was falsch ? Ich hoffe, mich genügend deutlich ausgedrückt zu haben.