Wo werden Plugin-Einstellungsfelder gespeichert?

Ich entwickle gerade ein Plugin und habe eine Frage best practicesund Konventionen.

Was ich brauche ?

Mein Plugin wird ein vordefiniertes Objekt, eine Liste von Objekten (oder nur Arrays / Schlüssel-Wert-Paare) speichern und es wird möglich sein, ein neues Objekt hinzuzufügen und seine Felder zu füllen.
Zum Beispiel wird mein Objekt folgenden Inhalt haben

{
  "id": 123,
  "url": "http://google.com/",
  "enabled" : true,
  "name": "hello_world",
  "api_key" : "api_key"
}

Einfaches JSONObjekt.

Und Plugin Admin configuration pagees wird möglich sein , hinzuzufügen, zu bearbeiten oder solche Objekte zu entfernen.

Was ist meine Frage?

Was ist der beste Weg, um solche Daten zu speichern. Ich habe viele verschiedene Plugins installiert, um zu sehen, wie benutzerdefinierte Daten aus Einstellungen gespeichert werden. Es gibt einige Optionen, die ich gesehen habe

1. Verwendung Settings APIbereitgestellt von Wordpress. Auch UIwenn WordPress dies tut, können Sie die Funktion einfach aufrufen und es wird ein korrektes Eingabefeld erstellt und anschließend alle Einstellungen in der Optionstabelle gespeichert. Alle Überprüfungen und Sicherheitsvorkehrungen werden ebenfalls von WordPress durchgeführt. Aber ist es möglich, eine dynamische Administrationsseite zu erstellen, auf der Sie neue Elemente hinzufügen können?

2. Die Verwendung von old Options APIwird ebenfalls in der Optionstabelle gespeichert, bietet dem Entwickler jedoch mehr Freiheit, die gesamte Validierung durchzuführen.

3. Neue Datenbanktabelle erstellen und Daten darin speichern.

Ich glaube nicht, dass ich die dritte Methode anwenden werde.

Bitte schlagen Sie einen besseren Weg vor, um dies zu tun, oder Sie wissen, dass das Plugin diese Funktionalität bereits richtig implementiert hat. Ich wäre für jede Hilfe dankbar.

Dies hängt davon ab, wie Sie die gespeicherten Daten verwenden.

Wenn Sie komplexe Abfragen für die Werte ausführen möchten, verwenden Sie eine benutzerdefinierte Tabelle mit für diese Abfragen optimierten Indizes.

Wenn Sie immer nur alle Werte für ein bestimmtes Objekt abrufen, erstellen Sie einen nicht öffentlichen benutzerdefinierten Beitragstyp und speichern Sie die Daten als Beitragsmeta.

Speichern Sie die Daten nicht in einer serialisierten Zeichenfolge, wie dies die Options-API tut. Dies ist ein Albtraum, wenn Sie es per Befehlszeilen-SQL ändern möchten, da das serialisierte Format PHP-spezifisch ist.

Die "Einstellungs-API" führt zu einem sehr veralteten Markup, und der Code für die Registrierung und Speicherung ist eher kontraintuitiv. Ich würde es nicht empfehlen.

Wo werden Plugin-Einstellungsfelder gespeichert?

Optionstabelle FTW. Es ist zwischengespeichert und einfach, CRUD zu machen.

Einstellungs-API oder Options-API?

Grundsätzlich können Sie die Options-API ohne die Einstellungs-API verwenden, aber Sie können die Einstellungs-API nicht ohne die Options-API verwenden. Selbst wenn Sie einer vorhandenen WordPress-Seite nur einige Felder hinzufügen müssen, benötigen Sie get_option () , um Daten für Ihre Ansichtsvorlage abzurufen.

Wenn Sie jedoch eine vorhandene WordPress-Seite verwenden, werden Ihre Daten fragmentiert und sind schwer abzurufen / zu pflegen, da sie mit anderen Daten gespeichert werden option_name. Dies könnte auch Endbenutzer verwirren.

Wenn Sie nur die Options-API verwenden, können Sie als Autor des Plugins Nachrichtenabschnitte / -felder hinzufügen, wann immer Sie möchten, andere Personen jedoch nicht. Weil die Ansichtsvorlage ohne Hooks fest codiert ist, die wie do_settings_sections () und do_settings_fields () funktionieren . Natürlich können Sie do_action () verwenden, aber es wird viel komplizierter.

Die Verwendung der Options-API gibt dem Entwickler mehr Freiheit, alle Überprüfungen durchzuführen. Die Einstellungs-API sanitize_callbackermöglicht es Entwicklern auch, mit Eingabedaten zu tun, was sie wollen.

Warum also nicht beide verwenden?

Angenommen, eine Einstellungsseite, die sowohl die Einstellungs-API als auch die Options-API verwendet, option_groupist my_app_groupund option_nameist my_app:

$options = get_option('my_app');

?><div class="wrap">
    <h1><?= __('Plugin Settings', 'textdomain') ?></h1>
    <form class="form-table" method="post" action="options.php">
        <?php settings_fields('my_app_group') ?>
        <table>
            <tr>
                <td>
                    <label for="my_app[name]">
                        <?= __('App Name', 'textdomain') ?>
                    </label>
                </td>
                <td>
                    <input type="text" name="my_app[name]" value="<?= $options['name'] ?>">
                </td>
            </tr>
            <tr>
                <td>
                    <label for="my_app[app_key]">
                        <?= __('App Key', 'textdomain') ?>
                    </label>
                </td>
                <td>
                    <input type="text" name="my_app[app_key]" value="<?= $options['app_key'] ?>">
                </td>
            </tr>
            <?php do_settings_fields('my_app_group', 'default') ?>
        </table>
        <?php do_settings_sections('my_app_group') ?>
        <?php submit_button() ?>
    </form>
</div><?php

Jetzt werden alle Daten in der my_appOptionstabelle unter dem Optionsnamen gespeichert und können dann einfach abgerufen / verwaltet werden. Andere Entwickler können Ihrem Plugin auch neue Abschnitte / Felder hinzufügen.

1. Ja

2. Dies ist eigentlich das gleiche wie Punkt 1, nur ohne die Helfer

3. Dies hängt nun davon ab, wie Sie Ihre Einstellung verwenden möchten. Der Instinkt ist, dass dies in 99% der Fälle Ihrem Code nur unnötige Komplexität verleiht und die Leistung beeinträchtigt.

Solange es sich um Einstellungen handelt und nicht um Inhalte oder Widgets, sollten Sie die Einstellungs-API verwenden. Es dauert einige Zeit, bis Sie sich daran gewöhnt haben, aber es gibt keine Einschränkungen hinsichtlich der Art der Benutzeroberfläche oder der Einstellungsstruktur, die Sie haben können. Was auch immer Sie mit einem HTML-Formular tun können, können Sie auch mit der Einstellungs-API tun.

Aber warten Sie, es gibt eine Alternative, nämlich den Customizer zu verwenden. Wenn Ihre Einstellungen Auswirkungen auf das Front-End haben, sollten Sie die Verwendung in Betracht ziehen