Si je veux enregistrer les paramètres de mon plugin, c'est assez simple et direct.
J'aimerais maintenant enregistrer un peu plus dans la base de données.
Un nom de fichier et 3 autres valeurs qui s'appliquent uniquement à ce fichier. Et il existe de nombreux fichiers avec ces valeurs. Est-il possible d'enregistrer des types de sous-réseaux en utilisant des méthodes de base de données intégrées? Comment puis-je les supprimer et les trier, etc.?
Réponses:
Je suis rarement en désaccord avec des utilisateurs par ailleurs bien informés, mais dans ce cas, je ne peux pas m'en empêcher. À mon avis, qualifier de mauvaise pratique l'utilisation de tables de base de données non essentielles est tout simplement faux.
Le choix entre utiliser des tables de base ou ajouter les vôtres dépend de plusieurs facteurs.
Le temps d'exécution d'une requête dépend de la taille de la table. Par conséquent, si vous prévoyez de stocker des quantités importantes de données, une table distincte réservée à ce seul type d'ensemble de données spécifique sera inévitablement la solution la plus efficace.
Si vous stockez un grand nombre de publications régulières ou CPT à côté de ces ensembles de données spécifiques, wp_postsainsi que wp_postmetapeut croître rapidement.
Pour moi, ce choix dépend en fin de compte de la "position" des données. Doit-il prendre en charge un auteur, des commentaires, des révisions, des extraits ou similaires? Si oui, j'irai avec des CPT et / ou des fonctionnalités de base. Sinon, je vais utiliser des tableaux séparés pour des raisons d'utilisation des ressources et d'efficacité.
Si la notion d'Eugène était correcte, aucun des plugins bien écrits existants n'ajouterait leurs propres tables, ce qui n'est heureusement pas le cas.
$wpdbclasse très puissante .wp_options, et en forçant le développeur du plug- in à examiner attentivement le type de données créées / stockées - est-ce un CPT? est-ce une taxonomie? est-ce post meta?Cependant, pour les cas d'utilisation où une table de base de données distincte est nécessaire, veillez à utiliser la méthode fournie par WordPress pour ajouter votre table personnalisée à la base de données WordPress , en particulier pour que vous puissiez profiter de la $wpdbclasse puissante . Notez les informations / mises en garde de cette liste d'entrées Codex:
Informations de configuration - choix de l'utilisateur qui sont entrés lors de la première configuration de votre plug-in par l'utilisateur et qui n'ont pas tendance à s'étendre bien au-delà (par exemple, dans un plug-in lié aux balises, les choix de l'utilisateur concernant le format du nuage de balises dans la barre latérale). Les informations de configuration seront généralement stockées à l'aide du mécanisme d'options WordPress.
Données - informations ajoutées au fur et à mesure que l'utilisateur continue d'utiliser votre plug-in, qui est généralement des informations étendues liées aux publications, catégories, téléchargements et autres composants WordPress (par exemple, dans un plug-in lié aux statistiques, les différentes pages vues, les référents , et d'autres statistiques associées à chaque publication sur votre site). Les données peuvent être stockées dans une table MySQL distincte, qui devra être créée. Avant de vous lancer avec une toute nouvelle table, cependant, demandez-vous si le stockage des données de votre plugin dans Post Meta de WordPress (alias Champs personnalisés) fonctionnerait. Post Meta est la méthode préférée; utilisez-le lorsque cela est possible / pratique.
Ainsi, nous pouvons conclure ce qui suit:
$wpdb(l'utiliser avec des tables non-core était implicite dans ma réponse, je ne voudrais pas manquer cette classe)
Les tables de base de données non essentielles sont indispensables si vos données sont plus complexes que le modèle de publication WordPress, elles vont être énormes et elles contiennent beaucoup de méta-détails qui seront recherchés.
Le format EAV que WordPress utilise pour sa publication meta ne se prête pas bien à la recherche multicritère.
Si vous divisez votre méta en plusieurs entrées, vous aurez de nombreuses entrées par publication dans la table des méta-publications, et la recherche de n'importe quelle publication via les métas sera beaucoup plus lente.
Si vous stockez toutes les métas sérialisées dans un tableau et que vous ne les avez qu'une seule entrée dans la méta post, cette fois, vous serez obligé de faire uniquement des recherches de texte à l'intérieur de cette méta, et vous ne pourrez pas utiliser d'opérateurs de comparaison directement dans votre requête SQL.
Pas un gros problème si votre plugin ne va pas avoir des milliers d'entrées et des méta associées.
Mais un problème majeur si votre plugin va faire quelque chose de grand.
Votre situation, un nom de fichier comme entrée indépendante et 3 entrées de métadonnées attachées à cette entrée ne semblent pas si grandes. Vous pouvez utiliser la table de publication wordpress et la méta-table pour cela.
MAIS, si les gens vont souvent chercher ces 3 métas, PARTICULIÈREMENT en conjonction, alors je vous recommande de mettre en place des tables séparées.
Avec ce format, une seule table avec une seule entrée, qui contient également toutes les métas, serait correcte et interrogerait rapidement.
Par ailleurs, si vous utilisez des tableaux WordPress et que vous utilisez également la mise en cache des requêtes, l'utilisateur recherche vos données serait mis en cache au fil du temps et encourra moins de charge. Mais ce ne serait pas aussi prudent que de faire des tableaux séparés.
Vous pouvez télécharger vos fichiers dans la bibliothèque multimédia. Chaque élément de la bibliothèque multimédia est stocké dans la wp_poststable. Cela signifie que chaque fichier peut avoir des métadonnées. Vous pouvez enregistrer autant d'informations que nécessaire pour chaque fichier du wp_postmetatableau à l'aide de l' API de métadonnées .
Est-ce une mauvaise pratique de créer sa propre table pour un plugin?
Oui, c'est une mauvaise pratique de créer sa propre table, si vous pouvez utiliser à la place les fonctionnalités de base.
class TMM {
public static $options;
public static function register() {
self::$options = get_option(TMM_THEME_PREFIX . 'theme_options');
}
public static function get_option($option) {
return @self::$options[$option];
}
public static function update_option($option, $data) {
self::$options[$option] = $data;
update_option($prefix . 'theme_options', self::$options);
}
//ajax
public static function change_options() {
$action_type = $_REQUEST['type'];
$data = array();
parse_str($_REQUEST['values'], $data);
$data = self::db_quotes_shield($data);
if (!empty($data)) {
foreach ($data as $option => $newvalue) {
if (is_array($newvalue)) {
self::update_option($option, $newvalue);
} else {
$newvalue = stripcslashes($newvalue);
$newvalue = str_replace('\"', '"', $newvalue);
$newvalue = str_replace("\'", "'", $newvalue);
self::update_option($option, $newvalue);
}
}
}
_e('Options have been updated.', TMM_THEME_FOLDER_NAME);
exit;
}
public static function db_quotes_shield($data) {
if (is_array($data)) {
foreach ($data as $key => $value) {
if (is_array($value)) {
$data[$key] = self::db_quotes_shield($value);
} else {
$value = stripslashes($value);
$value = str_replace('\"', '"', $value);
$value = str_replace("\'", "'", $value);
$data[$key] = $value;
}
}
}
return $data;
}
}