Alle WordPress-Optionen als einzelne Option (serialisiertes mehrdimensionales Array) oder mehrere Optionen?

Ich kenne mich mit WordPress aus, aber im Moment entwickle ich ein ziemlich großes und fortschrittliches WordPress-Plugin.

Aus diesem Grund habe ich mir viele Gedanken über meine Datenstruktur gemacht.

Als ich ein Anfänger war, habe ich es immer so gespeichert (get_option(prefix_option_name)). Dann fing ich an, multidimensionale Arrays zu verwenden, registrierte 1 für jeden settings_section und jetzt speichere ich normalerweise alle Plugin-Optionen in einem großen multidimensionalen Array wie diesem: plugin_options[section][option][evt.more subs here][etc]

Das funktioniert gut, und ich mag die Tatsache, dass ich alle Optionen einmal im Init-Hook ($plugin_options = get_option(‘plugin_options)) herausziehen kann, damit ich mit den $options “lokal” im Plugin arbeiten kann , JEDOCH…

In Anbetracht der Tatsache, dass WordPress bereits Transienten verwendet, um den get_option-Aufruf zwischenzuspeichern (WP Cache API), was ist besser für die leistung? Obwohl mein Plugin viele Optionen hat, könnten Sie wohl nie die Grenze des Longtext-Typs (4 GB Daten oder so) erreichen, selbst wenn ich alles in ein einziges serialisierbares multidimensionales Array gepackt habe? Aber ich möchte das tun, was aus Performance-Sicht am besten ist, also kurz gesagt, hier nochmal meine Frage:

Was ist das Beste (für ein ziemlich großes und komplexes WordPress-Plugin)?

1. Speichern Sie alle Ihre Plugin-Optionen als eine einzige Option (serialisiertes multidimensionales Array), wie zB. name=”plugin_options[section][option]”
2. Aufteilen jedes Optionsreiters und jeder Optionsseite in einen eigenen Optionseintrag wie zB: Abschnitt[option][etc]
3. Stellen Sie einfach alle Ihre Plugin-Optionen voran und setzen Sie sie dann als separaten DB-Eintrag wie zB. Pluginname_Option_1, Pluginname_Option_2

Ich mag den Ansatz der “einzelnen Plugin-Option”, aber im Moment bin ich verwirrt, ob das Abrufen / Aktualisieren eines großen Arrays aus der Datenbank wirklich der beste Weg ist, wenn das Array WIRKLICH groß wird – wie in einem sehr großes und fortschrittliches Plugin.

Das Problem mit 3, wie ich es sehe, ist, dass Sie mit 1 nur alle Optionen in einem db-Aufruf abrufen müssten, während Sie in 3 (wo Sie jede Option als einen db-Eintrag für sich selbst speichern) die abfragen müssten db für jede spezifische und individuelle Option.

Aber was ist besser 1 Anruf für alle Optionen, 1 für jeden Abschnitt oder 1 für jede einzelne Option (ich denke, meine Frage könnte am Ende darauf eingegrenzt werden :D). Kann die serialisierbare “Einzeloption”-Plug-in-Option multidimensionales Array realistischerweise zu groß werden? Soll es aufgeteilt werden?

Freuen Sie sich darauf, Ihre Meinung dazu zu hören. Prost. 🙂

Ich neige dazu, getrennte Optionen für nicht zusammenhängende Daten zu bevorzugen. In den meisten Fällen spielt es keine Rolle für die Leistung, aber es gibt erhebliche Vorteile im Vergleich zur Kombination.

Leistung

Wenn die Option ist automatisch geladen – was sie standardmäßig sind – dann führt die Verwendung separater Optionen nicht zu zusätzlichen Datenbankabfragen.

Wenn Sie Memcache verwenden, sind Objekte standardmäßig auf 1 MB begrenzt, und wenn Ihre Option darüber hinausgeht, es umgeht das Caching und trifft jedes Mal die Datenbank.

Andere Überlegungen

Ich denke, Core wurde unter der Annahme entwickelt, dass die Optionen getrennt werden. Wenn Sie sie also kombinieren, müssen Sie zusätzliche Arbeit leisten, um einige der hilfreichen Dinge zu nutzen, die Core Ihnen ansonsten kostenlos zur Verfügung stellt.

All diese gängigen Praktiken sind beispielsweise mit einzelnen Optionen einfach durchzuführen, erfordern jedoch zusätzliche Logik, um die kombinierte Option auf den Zieleintrag zu reduzieren:

• pre_update_option{$option_name}
• Sanierungsrückrufe mit register_setting
• Abrufen von Einstellungen von der REST-API

Es kann auch ein „Alle-Eier-in-einem-Korb“-Problem sein; Wenn ein Fehler oder ein anderer Faktor unerwarteten Datenverlust verursacht, kann der Benutzer alles verlieren, anstatt nur ein einzelnes Datum. Das ist in der Praxis selten, aber ich habe es mit sehr schädlichen Auswirkungen erlebt. Die Leute sollten Backups haben, aber viele haben keine, und ich habe auch gesehen, dass Backups in der Praxis fehlgeschlagen sind.

Ich persönlich entscheide mich normalerweise für die Einzeloption.

Wenn Sie mehrere Optionen beim Laden einer einzelnen Seite verwenden, wäre jede davon ein db-Aufruf (es sei denn, sie werden automatisch geladen). Wenn Sie sowieso alle oder die meisten Ihrer Optionen auf einer Seite verwenden, würden Sie einen DB-Aufruf für jede Option sparen, die Sie verwenden, wenn Sie sie alle in einer einzigen Option zusammenfassen. Die Einsparungen können sich hier schnell summieren.

Dies hängt jedoch immer noch davon ab, wie viele Daten Sie in Ihre einzelne Option eingeben. Wenn es ziemlich groß ist, kann sich das Deserialisieren oder Serialisieren Ihrer Daten auf die Leistung Ihres Servers auswirken. (siehe: Ein großes Array in PHP serialisieren?). Sie müssen eine Art Benchmark durchführen, um zu messen, was schneller ist, wenn Sie viele Daten verarbeiten.

FWIW, WordPress schon lädt alle Optionen automatisch und cachet sie bei jedem Laden der Seite (es sei denn, eine Option ist gespeichert, dies nicht zu tun), also spielt es keine Rolle.