web-dev-qa-db-fra.com

Où stocker les champs de paramètres du plugin

Je développe actuellement un plugin, et j’ai une question à propos de best practices et des conventions.

Ce dont j'ai besoin ?

Mon plugin va stocker un objet prédéfini, une liste d'objets (ou juste des paires de tableaux/valeurs-valeurs) et il sera possible d'ajouter un nouvel objet et de remplir ses champs.
Par exemple, mon objet aura le contenu suivant

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

Objet JSON simple.

Et sur Plugin Admin configuration page, il sera possible d’ajouter, éditer ou supprimer de tels objets.

Quelle est ma question?

Quel est le meilleur moyen de stocker de telles données? J'ai installé de nombreux plugins afin de voir comment les données personnalisées des paramètres sont stockées. Il y a quelques options que j'ai vues

  1. Utilisation de Settings API fourni par Wordpress. Même UI est géré par wordpress, vous pouvez simplement appeler la fonction pour créer le champ de saisie approprié puis enregistrer tous les paramètres dans le tableau des options. Tous les contrôles et la sécurité sont également gérés par wordpress. Mais est-il possible de créer une page d'administration dynamique où vous pouvez ajouter de nouveaux éléments?

  2. L'utilisation de l'ancien Options API est également stockée dans la table d'options, mais donne plus de liberté au développeur pour gérer toutes les validations.

  3. Créer une nouvelle table de base de données et y sauvegarder des données.

Je ne pense pas que je vais utiliser la troisième méthode.

Veuillez suggérer un meilleur moyen de le faire ou peut-être connaissez-vous le plugin qui a déjà implémenté de telles fonctionnalités de manière appropriée. Je serais reconnaissant pour toute aide.

plugin-developmentsettings-apiwp-options
7
CROSP

Cela dépend de la manière dont vous allez utiliser les données stockées.

Si vous souhaitez exécuter des requêtes complexes sur les valeurs, utilisez une table personnalisée avec des index optimisés pour ces requêtes.

Si vous voulez toujours simplement extraire toutes les valeurs d'un objet donné, créez un type de publication personnalisé non public et stockez les données en tant que méta de publication.

Ne stockez pas les données dans une chaîne sérialisée, comme le fait l’API des options. C'est un cauchemar lorsque vous souhaitez le modifier par ligne de commande SQL, car le format sérialisé est spécifique à PHP.

L'API "Paramètres" impose des balises très obsolètes et le code pour l'enregistrement et le stockage est plutôt contre-intuitif. Je ne recommanderais pas de l'utiliser.

8
fuxia

Où stocker les champs de paramètres de plug-in?

Table d'options FTW. C'est caché et facile à faire CRUD.

API de paramètres ou API d'options?

Fondamentalement, vous pouvez utiliser Options API sans API de paramètres mais vous ne peux pas utilise Paramètres API sans Options API. Même lorsque vous devez simplement ajouter des champs à une page WordPress existante, vous avez toujours besoin de get_option () pour récupérer les données de votre modèle de vue.

Mais en utilisant une page WordPress existante, vos données seront fragmentées et difficiles à récupérer/à gérer car elles sont stockées avec un option_name différent. Cela pourrait également dérouter les utilisateurs finaux.

Lorsque vous utilisez uniquement l'API Options, en tant qu'auteur du plug-in, vous pouvez ajouter des sections/champs d'actualités à tout moment, mais les autres personnes ne le peuvent pas. Parce que le modèle de vue est codé en dur sans crochets qui fonctionnent comme do_settings_sections () et do_settings_fields () . Bien sûr, vous pouvez utiliser do_action () mais ce sera beaucoup plus compliqué.

Utiliser Options API donne plus de liberté au développeur pour gérer toutes les validations est incorrect. L'API de paramètres a sanitize_callback qui permet également aux développeurs de faire ce qu'ils veulent avec les données d'entrée.

Alors, pourquoi ne pas utiliser les deux?

Par exemple, supposons qu'une page de paramètres utilisant à la fois les API de paramètres et les options avec option_group soit my_app_group et option_name à 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

Désormais, toutes les données sont stockées dans la table d’options sous le nom de l’option my_app, ce qui facilite leur extraction/maintenance. D'autres développeurs peuvent également ajouter de nouvelles sections/champs à votre plugin.

4
MinhTri
  1. Oui

  2. c'est en fait le même que le point 1, juste sans les aides

  3. Maintenant, cela dépend de la façon dont vous voulez utiliser votre réglage. L’instinct est que, dans 99% des cas, cela ne fera qu’ajouter une complexité inutile à votre code et nuire à la performance.

Tant que nous parlons de paramétrage et non de contenu ou de widgets, l’API de paramétrage est ce que vous devez utiliser. Il faut un certain temps pour s'y habituer, mais cela n'impose aucune limitation quant au type d'interface graphique ou à la structure de paramètres que vous pouvez avoir. Quoi que vous puissiez faire avec un formulaire html, vous pouvez également le faire avec l’API des paramètres.

Mais attendez, il existe une alternative, utiliser le personnaliseur. Si vos paramètres ont des implications initiales, vous devriez envisager de les utiliser.

1
Mark Kaplun